Issue metadata
Sign in to add a comment
|
Security: address bar displaying requested url rather than actual loaded URL
Reported by
tacki...@reed.edu,
Jun 16 2016
|
||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Name collisions in chrome result in the URL bar displaying the requested URL rather than the loaded URL. A malicious site could use this to trick users. This appears to only occur in chrome for mac. It does not happen in chrome on windows. It does not happen in other browsers. VERSION Chrome Version: 51.0.2704.84 (64-bit) stable Operating System: OS X 10.11.4 REPRODUCTION CASE For example, a local DNS server uses the TLD ".tv". A user visits a non-existent .edu URL. We'll call it "cal.reed.edu" but really anything that fits "x.y.edu" works. Instead of an error page they are shown the page "cal.reed.edu.tv". In other words, rather than displaying the actual URL that has been loaded (x.y.edu.tv) it still displays the requested URL (x.y.edu) in the address bar.
,
Jun 22 2016
Please let me know if screenshots or any other info would be helpful. I'm happy to assist if possible.
,
Jun 24 2016
,
Jun 24 2016
@tackittj: screenshots of each step and the error you get as well as any other information would definitely be helpful. juliatuttle: any chance that you could have a look or recommend someone to have a look?
,
Jun 24 2016
I don't think this is a vulnerability. Ultimately the origin is what the user typed in to the URL bar (or clicked on) - i.e. the origin could be http://cal.reed.edu:80 DNS simply steers domain to the host. In this case it appears to be adding a suffix, but it could simply steer to any IP address. Regardless, Chrome would still treat the origin as cal.reed.edu, send the host header with that, use it as the origin for SOP, etc. If the origin was HTTPS then the cert would need to have a sAN which matched the intended origin, not what DNS resolved to.
,
Jul 6 2016
This is expected behavior from DNS. If you have .tv in your suffix search list (or, for some reason, your upstream resolver is adding it for you), then "cal.reed.edu" should behave effectively like a CNAME to "cal.reed.edu.tv". If we don't rewrite the URL bar for CNAMEs, I don't see why we'd rewrite it for suffix search. (If people think it's enough of a UX issue to warrant changing it even if it's not a security issue, I can see if it's possible to pass that information back up the stack. It may not be, if the OS just hands us a list of IP addresses and doesn't tell us it did suffix search.)
,
Jul 8 2016
Thank you for that explanation. I understand and agree that this is expected behavior from DNS. It is worth noting that this behavior is unique to Chrome on the Mac. Chrome for Windows displays the rewritten URL. Safari rewrites the URL. Firefox on both Mac and Windows also rewrites the URL.
,
Sep 30 2016
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
,
Oct 1 2016
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
,
Oct 2 2016
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
,
Oct 2 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by est...@chromium.org
, Jun 20 2016Components: Internals>Network>DNS