New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 832835 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug
Team-Security-UX



Sign in to add a comment

Homograph Attack

Reported by rockmegn...@gmail.com, Apr 13 2018

Issue description

Chrome Version       : 65.0.3325.181
Other browsers tested:
  Yes, this issue was with chrome on windows and android too.
I have tested this issue:
       Edge:Has passes the test. The homograph text was decoded on pasting into URL bar.

What steps will reproduce the problem?
(1)Going to this URL " http://www.xn--bgrock-p9a.com/ " is producing a homograph URL resulting which looks like " http://www.bigrock.com/ "

The expected result is when the 'i' in the bigrock.com(As there is an "i" in that domain) should be decoded that is, the non ASCII character should change to ASCII.

What happens instead?
The URL "http://www.xn--bgrock-p9a.com/" looks like "http://bigrock.com/" eccept there is a small difference in "i" where user can be tricked and that may lead to social engineering attack on user.

This decoding of non ASCII works perfectly fine on Edge browser only on Windows version and Android Version of chrome, i had observer this issue. This may lead to serious social engineering tricks like making phishing pages will be more easy. This may lead to many problems for the users further as attackers using social engineering as much as they can because it's said, "WHEN MACHINES ARE NOT VULNERABLE, HUMANS ARE."


 
Components: UI>Browser>Omnibox
Labels: Needs-Triage-M65
Cc: sindhu.chelamcherla@chromium.org
Labels: -Pri-3 M-68 Triaged-ET FoundIn-68 Target-68 Pri-2
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on reported version 65.0.3325.181, on latest canary 68.0.3397.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04.

This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.

This issue is seen in Firefox and Safari as well. Issue is not seen in Edge.

Thanks!
Status: Available (was: Untriaged)
Cc: dschuyler@chromium.org
Components: UI>Security>UrlFormatting Security
Owner: js...@chromium.org
Status: Assigned (was: Available)
jshin@, is this handled by the various IDN changes you've made recently?

Comment 5 by js...@chromium.org, Apr 21 2018

Cc: js...@chromium.org est...@chromium.org
Labels: -Pri-2 -M-68 -Needs-Triage-M65 -Target-68 Pri-3
Owner: ----
Status: Untriaged (was: Assigned)
bigrock.com is not a high-value domain. If the same character (dotless I) is used in gmail.com or any other top domains instead of ASCII 'i', it'd be blocked. 

There is NO way to know which of the two is legitimate or whether both (bigrock.com with regular 'I', bigrokc.com with U+0131 ) are legitimate. 

So, this is WAI in a sense. 




Status: WontFix (was: Untriaged)
I'm closing this as WAI given jshin's point that this attack would be blocked in the case of high-value domains. If anyone disagrees, feel free to reopen it.

As a side note, I tested this on Android 8.1.0, Chrome Beta 66.3359.106 and I observed the same behavior as desktop Chrome and Firefox . From my testing, Edge is the only browser that *doesn't* decode the text.

Sign in to add a comment