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

Issue 726738 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 703750
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment

Security: URL bar spoofing with (ħ)

Reported by chromium...@gmail.com, May 26 2017

Issue description


Chrome Version: 61.0.3113.0 (Developer Build)
Operating System: All

REPRODUCTION CASE

Visit https://manħattan.edu

And this is the real domain https://manhattan.edu
 

Comment 1 by kenrb@chromium.org, May 26 2017

Cc: tapted@chromium.org mgiuca@chromium.org lgar...@chromium.org
Components: UI>Browser>Omnibox UI>Security>UrlFormatting
Labels: Team-Security-UX Security_Severity-Low Security_Impact-Stable OS-All Pri-2
Owner: js...@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for the report.

jshin@: Is this something that we should be blocking with your recent change? https://chromium.googlesource.com/chromium/src/+/a8add0308ba6067eb3de5a8fe82f9c2f2460ad91

Also, I don't know if there has been any discussion on whether this should be considered a security vulnerability. Spoofing detection seems like it is always going to be on a best effort basis, similar to the XSS auditor.

Comment 2 by kenrb@chromium.org, May 26 2017

Labels: -Pri-2 -Security_Severity-Low Security_Severity-Medium Pri-1
Changing to Sev-Medium for consistency with other bugs, pending further discussion.

Comment 3 by js...@chromium.org, May 26 2017

Cc: markda...@google.com
No, it'd not catch this because of two reasons:

1) manhattan.edu is not in the top domain list which is used as a reference list to compare incoming domains with. 

2) 

a. ħ (http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:toNFD=%C4%A7:] ; U+0127) is not regarded as  h + a diacritic mark. So, diacritic-removal would not touch U+0127. 

However, as is the case of "ł > l; ø > o; đ > d", the primary-strength comparison (collation) may treat ħ and h identically. If that's the case (maybe even if it's not the case), I'll add "ħ -> h" to our manual diacritic removal list. (I have a mixed feeling about this list, though). 

b. U+0127 is not regarded as confusable with 'h' (none of base LGC + diacritics combination is regarded as confusable with base LGC letters. I understand why not). 


So, my algorithm of removing diacritic marks and calculating confusability skeleton of diacritic-free input wouldn't work even if manhattan.edu is in the top domain list. 

As I wrote in 2a above, I can add "ħ -> h" to the manual diacritic-removal list. 

Even if I do, manħattan.edu wouldn't be caught because 'manhattan.edu' is not in the top domain list. However, other cases with 'h' replaced by 'ħ ' can be caught if they happen to be a spoofing attempt against one of top domains. 

If we use the browsing history of a user and a user visited manhattan.edu before (and perhaps multiple times), we may flag this as well. 


Mergedinto: 703750
Status: Duplicate (was: Assigned)
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 2 2017

Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment