Created attachment 739293 [details] 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
assigning to dchan for verification per https://wiki.mozilla.org/Security/Web_Bug_Rotation#Web_Bug_Verification
Assignee: nobody → dchan+bugzilla
Test case redirects immediately as described. The bug appears to be in SetupRefreshURIFromHeader  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.  - http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#5866
Assignee: dchan+bugzilla → nobody
Status: UNCONFIRMED → NEW
Component: Untriaged → Document Navigation
Ever confirmed: true
Product: Firefox → Core
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.
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.
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.
Also I see your email is @mit.edu. Stay you're safe over there!!
(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.
You need to log in before you can comment on or make changes to this bug.