Issue metadata
Sign in to add a comment
|
Security: Open redirection issue
Reported by
shailesh...@gmail.com,
Mar 30 2016
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS There is a possible open redirection issue due to improper URL design. As you know, In Chrome, https://anything@google.com will redirect us on google.com. But i found that if we open https://evil.com\@google.com then we will be redirected on https://evil.com. Bug is that "\" is treated as "/". While website developers consider that just "/" and "@" are sensitive characters for URL to extract domain from that URL. so they allows "/" before @. While if we open https://evil.com\@google.com in Mozilla firefox then we will be on google.com instead of evil.com and that's absolutely fine. But in google chrome, behavior seems wrong. VERSION Chrome Version: 49.0.2623.110 + stable Operating System: Windows 8.1 REPRODUCTION CASE 1. Open https://anything@google.com 2. You will be redirected on https://google.com 3. Open https://evil.com\@google.com 4. You will be redirected SUGGESTED FIX (If it's a valid issue) Don't treat "\" as "/" for mentioned scenario
,
Mar 31 2016
Hello Chris, Charlie, I'm hoping one of you can help to assign this to an appropriate person for triage? Feel free to add more labels as well - I'm not actually sure how to label/prioritize this one. Thank you very much!
,
Mar 31 2016
I'm not sure I see the security implications here. Is it just that a website might try to limit its outgoing links to [.*]@foo.com and consider it a security problem if evil.com\@foo.com went to evil.com instead? So far, this seems like more of a browser compatibility bug than anything else. I'll note that Safari puts up a Phishing warning on these URLs (whether the backslash is present or not), and it goes to about:blank if you click through the warning for the version with the backslash. Thus, I'm not sure whether Firefox's behavior can be considered the standard in this case. Anyway, this seems like it's in some of the same general URL escaping logic as issue 533361 , so I'm CC'ing pkasting and brettw for their opinion.
,
Mar 31 2016
The only thing we can guarantee is that the state of the Omnibox is correct at the end of navigation — after all parsing, requesting, and redirection is complete, does Chrome correctly represent the URL and its origin in the Omnibox? In this case (see screenshot), I think the answer is Yes. So, I don't think there is a bug here. Normalizing \ to / is necessary because people have a hard time typing URLs, so we help them out. I updated the Chrome Security FAQ to mention this. https://www.chromium.org/Home/chromium-security/security-faq#TOC-Where-are-the-security-indicators-located-in-the-browser-window-
,
Mar 31 2016
Chrome agrees with IE11. I don't think this is a bug.
,
Apr 21 2016
Issue 605452 has been merged into this issue.
,
Apr 21 2016
Lifting view restrictions, since this is marked WontFix.
,
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
,
Dec 9 2016
Security>UX component is deprecated in favor of the Team-Security-UX label |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by f...@chromium.org
, Mar 31 2016