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

Issue 346083 link

Starred by 1 user

Issue metadata

Status: WontFix
Closed: May 2015
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Feature

Sign in to add a comment

Security Feature: Do not treat backslash and slash as equvalent in http:\\ URLs.

Reported by, Feb 23 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36

Steps to reproduce the problem:
Steps to reproduce the problem:
1. Save:
<script src=http:\></script> into an html file (only works when the origin is null, aka from data uri)
<script src=\/></script> which works regardless of the referer/origin.
2. Open it and the script executes.

What is the expected behavior?
What is the expected behavior?
Nothing should happen as http:\ and \/ are not valid protocols as shown with other browsers like IE and firefox.

What went wrong?
What went wrong?
When you open the .html file the script will load. That should not happen as http:\ and \/ are both invalid protocols.

Did this work before? N/A 

Chrome version: 33.0.1750.117  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 11.7 r700

This can in certain circumstances be used to bypass filters of sites that were thought to be 'bullet-proof' to link to sources outside of the website. As shown here: Where he says:
I was not able to find a filter bypass for http:// [:// ] . This could have been an option [http& # 58 ; & # 4 7 ; & # 4 7 ] but since “ ;” is filtered this does not work. But in older browsers something like this should work <script src="" >.
This bug in chrome could be used to bypass that filter.
universal protocol.html
74 bytes View Download
null origin poc.html
78 bytes View Download

Comment 1 by, Feb 23 2014

 Issue 346015  has been merged into this issue.

Comment 2 by, Feb 23 2014

Thanks for your report.  It does seem curious that src=\/ works.  jww@ or tsepez@ do you know who would be best to look into this?

Comment 3 by, Feb 24 2014

tsepez@ himself might be a good owner for this one, but I'll let him make that call himself.

Comment 4 by, Feb 24 2014

Labels: -Restrict-View-SecurityTeam -Type-Bug-Security Type-Feature
We're fairly generous in what we accept -- the backslash was intended to provide compatibility for a Windows world, and we'll take a more-or-less arbitrary number of initial slashes following the colon in some cases.

I don't think this is a security issue per-se, in that the flaw would actually be in the site's HTML sanitizer letting an "invalid" URL through and trusting the browser not to do anything with it.

It may be time to revisit what we accept.

Comment 5 by, Feb 24 2014

Summary: Security Feature: Do not treat backslash and slash as equvalent in http:\\ URLs. (was: Invalid protocol accepted when linking to external site)

Comment 6 by, Feb 24 2014

FWIW, I agree with Tom's assessment of this not being a security bug. Sounds like a broken blacklist filter to me.
Ok then, so i'll get nothing for this?

Comment 8 by, Feb 24 2014

Sorry, this doesn't meet the bar for the Vulnerability Rewards Program.

Comment 9 Deleted

I have another bug where i can bypass chrome's xss auditor in the latest version and i can also bypass a restriction put in place where 'javascript:' is stripped off when being entered in the url bar. Would that qualify?
We don't treat XSSAuditor bypasses as security issues either, so "No" on that one.  Nonetheless, feel free to report it if you'd like as a functional bug.

The javascript: stripping is trivial to bypass and is not eligible either.
Ok then, i'd like this report to be deleted.
Status: WontFix

Sign in to add a comment