863464 - http-equiv="refresh" corresponding content parameter mishandled

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[andrewcmckenna]

Attachment: http-equiv-test.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Steps to reproduce:

I created a page with a http-equiv="refresh" meta tag that had an improperly formatted content parameter and it was processed and acted upon by the browser. An example page is attached but the relevant piece is:

<meta name="bad" content="url=,http://www.w3.org/TR/html-markup/meta.http-equiv.refresh.html" http-equiv="refresh">

As you can see the content="url=,http:..." is improperly formatted. As per specification there should be a non-negative integer followed by a ; then the url= portion. Note: the comma between the url= and the actual url is required for this to work.




Actual results:

The page is immediately re-directed to the website specified in the url= portion.


Expected results:

The browser should not allow the redirection and should ignore the tag and simply render the page. This could be a security issue because a filter of the ; character is insufficient to stop possible injection and redirection. In the case where I discovered this content was being taken from a cookie and placed into a meta tag. Being able use the http-equiv="refresh" meta tag without needing the ; (as per specification) meant I could re-direct the Firefox browser to an arbitrary page, whereas I couldn't with other browsers.

w3 reference - 
http://www.w3.org/TR/html-markup/meta.http-equiv.refresh.html

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

assigning to dchan for verification per https://wiki.mozilla.org/Security/Web_Bug_Rotation#Web_Bug_Verification

Comment 2

[David Chan [:dchan]]

Test case redirects immediately as described. The bug appears to be in SetupRefreshURIFromHeader [1]

The delay defaults to 0, then the code tries to parse a number which fails. We could die early on a missing non-negative integer. The current code allows +/- and decimal numbers which are each handled slightly different.

[1] - http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#5866

Comment 3

[Boris Zbarsky [:bzbarsky]]

What exactly is the security issue?  The fact that the redirect happens in Firefox but not other browsers?  It's not clear to me why that's a security problem....

In any case, I would bet our handling of <meta refresh> looks nothing like http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv-refresh and we should just consider adopting that algorithm.

Comment 4

[andrewcmckenna]

The reason I thought it may be a security issue to begin with was because of project I was working on. Basically there was user controlled content being placed into a meta tag and the site owners stripped the ; tag (as well as <>) in order to stop someone from injecting http-equiv="refresh" into the tag. This effectively prevented the attack in other browsers that require a non negative number followed by a semi-colon. In Firefox however this isn't required so the attack was successful. It's not a very severe security issue, but I believe it is one nonetheless.

Comment 5

[andrewcmckenna]

To distill it down a bit more - the expectation across browsers (as per standards) is that without a non-negative number and a ; (followed by url=...) in the content parameter then the http-equiv="refresh" should not function. If there are security measures that rely on removing the semi colon or matching agains the number followed by ;url= as a form of sanitization (albiet there are better ways of preventing these types of attacks) then in the Firefox browser those sanitization techniques can be bypassed.

In one line - Firefox doesn't follow standards and security measures that assume standards can be bypassed because of it.

Comment 6

[andrewcmckenna]

Also I see your email is @mit.edu. Stay you're safe over there!!

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to andrewcmckenna from comment #4)
> The reason I thought it may be a security issue to begin with was because of
> project I was working on. Basically there was user controlled content being
> placed into a meta tag and the site owners stripped the ; tag (as well as
> <>) in order to stop someone from injecting http-equiv="refresh" into the
> tag. This effectively prevented the attack in other browsers that require a
> non negative number followed by a semi-colon. In Firefox however this isn't
> required so the attack was successful. It's not a very severe security
> issue, but I believe it is one nonetheless.

OK, sounds like not something we need to keep hidden to protect users, so I'm opening up the bug.