Cenzic 232 Patent
Paid Advertising
web application security lab

Firefox Header Redirection JavaScript Execution

This sounds a lot sexier than it actually is, although it was interesting to find that only Firefox was vulnerable to this (tried IE and Opera with no results). However, if you perform a timed redirection from within the HTTP headers and instead of redirecting to a URL you redirect to a JavaScript function you can execute JavaScript. The only upside to this technique is if you must do response splitting and you are limited in what you can do, or if you want to obfuscate where and how the JavaScript is firing that performs the malicious activity.

Click here for an example (only works in Firefox). Like I said, this isn’t that particularly interesting, but it could be somewhat useful in some obscure circumstances. Nothing to see here, move along….

19 Responses to “Firefox Header Redirection JavaScript Execution”

  1. comcor Says:

    Interesting note.. this seems to work fine on a clean (no extensions) version of Firefox for me, but not on instances of firefox with a bunch of testing tools like WebDeveloper, TamperData, Firebug, Greasemonkey, etc…

  2. RSnake Says:

    Did you turn off meta refreshes in WebDeveloper? That would stop this from working.

  3. Torsten Says:

    Also works in latest Safari, in case anybody is interested.

  4. kuza55 Says:

    Mmmm, I found this a while ago as well: http://kuza55.blogspot.com/2006/11/not-all-redirection-scripts-are-created.html

    And as I said in that post, it has other implications too because some link anonymisers use the refresh header to redirect people (and lose the referer header), so you can attack them. I of course forgot to test what browsers this worked in.

  5. dusoft Says:

    works for me with firebug, webdeveloper etc. installed, so i guess comcor got meta refresh turned off

  6. Andrew Says:

    Works for me in Safari 2.0.4!

  7. RSnake Says:

    Kuza55, I should probably read your site closer, I think I remember seeing that post, but I didn’t see the JavaScript part of it. Thanks for pointing it out.

  8. Spider Says:

    Forgive me, if I this has been discussed elsewhere, but why can’t all web vulnerabilities be cataloged in a single place. So when you think you’ve found a new one you can check to see if anyone has encountered it before. OWASP is supposed to be that place. Is there a reason why it isn’t used much?

  9. digi7al64 Says:

    Stupidly, I spent 10 minutes working with WhiteAcid’s header spoofer before realizing the header was supposed to be returned via the response not the request :(

  10. Sid Says:

    HAHA. I had the exact same idea, then I remembered that I could only ever get it working in IE and even there it’s getting fixed now.

  11. someone Says:

    Nice.
    am I able to change someone’s HTTP header using Flash object?

  12. anonymous Says:

    not really a big deal because i dont think there is a wide range of malicious javascript you can fire through the redirect

  13. MustLive Says:

    RSnake!

    Recenlty (this monday) I wrote at my site about vulnerabilities in all browsers (which I had) which I found at 28.06.2009.

    Cross-Site Scripting vulnerabilities in Mozilla, Internet Explorer, Opera and Chrome
    http://websecurity.com.ua/3275/

    I wrote about it on English into Bugtraq.

    My research is also about refresh header redirector. But unlike you, I wrote about not Firefox only hole, but I wrote about holes in all browsers (which I had), from which only in Firefox 3.0.9 this vulnerability was fixed.

    And Iím talking about 0-timed (non-timed) redirect (which works in all browsers, including Firefox <= 3.0.8 for XSS attacks). It’s very interesting XSS vector. And I tested it in XSS hole which I found in one webapp which is very widespread (and so this XSS hole is also very widespread).

  14. MustLive Says:

    not really a big deal because i dont think there is a wide range of malicious javascript you can fire through the redirect

    anonymous

    When it works in all browsers (like in my research), it becomes a big deal. Because you can make XSS attacks, including cookie stealing, and infect users with malware and do many others things ;-).

    So it’s a big deal, because it’s XSS attack vector.

  15. RSnake Says:

    @Mustlive - I’m not sure you were the first person to find the refresh issue. I’ve had it on the cheat sheet for many years now: http://ha.ckers.org/xss.html#XSS_META But I’m glad you’re thinking about it as a problem.

  16. MustLive Says:

    Robert, I know that I’m not the first :-) - after I posted this information at my site, I spook with 3APA3A about it, and he told me, that some years ago there was a discussion about this subject on Bugtraq.

    In my research I draw attention that only Mozilla fixed this hole, but not other browser developers. And note that they fixed it only in Firefox, but not in SeaMonkey (which is not serious and it’s strange position of Mozilla)

    And my main idea is that both location and refresh redirectors (to javascript URIs) must be blocked in all browsers. If location-header redirectors not allow such JS code execution, then refresh-header redirectors must do the same. They both must have the same behaviour.

  17. MustLive Says:

    Iíve had it on the cheat sheet for many years now

    RSnake, I read that info (about meta-refresh) in your XSS Cheat Sheet in the first days of September 2006, when I first come to your site ;-). And I felt that you’d mention about it.

    Man, these are different things. You wrote in Cheat Sheet about using meta-refresh, which can be done via injecting html code into a page of web site. And I’m talking about using refresh header (via using refresh-header redirectors). It’s different attack vector. There are less refresh-header redirectors, than location-header redirectors, but there are still many of them in Internet.

    Besides, when you are redirecting via meta-refresh, there is not refresh header which appears in browser (as it can be seen with Live HTTP headers plugin). So these are different refresh redirectors, but they a handled similarly in browser. For this reason, when Mozilla fixed this hole in Firefox 3.0.9, they fixed both attack vectors - as refresh header, and as meta-refresh.

    The interesing thing with this, that I felt that it’s possible to bypass this Firefox’s protection. And today I made research and found a way to bypass it :-) (for both refresh header and meta-refresh vectors). I’ll write about it soon.

  18. RSnake Says:

    @Mustlive - http-equiv means “HTTP equivalent” They fixed both because both are the same thing - they mean the identical thing. One is in HTTP headers and the other is the HTML equivalent, but they are in no way substantively different. I know it seems different, but it’s not in the context that you’re talking about.

  19. MustLive Says:

    RSnake, I understand that these are two ways of the same redirect (with time delay). But like I said Live HTTP headers plugin doesn’t show any Refresh header if you are using html meta-refresh tag, so it’s looks like there is different outer behavior with these redirects, even if inner behavior in browsers is the same (which is the reason why Mozilla fixed both ways of refresh redirect with single patch).

    Besides, as I said, in case of meta-refresh tag you need to injecting html code into web site (via XSS or HTML Injection vulnerability). And in case of refresh header you need to use refresh-header redirectors (which you will use not for redirecting to web site, but for JS code execution, e.g for XSS attack). These are different attack vectors.

    Do you remember your article (from 2006) about HTTP Response Splitting in redirectors (which can be used particularly for XSS attacks). With these holes in all browsers via refresh header I’m introducing new way to conduct XSS attacks via redirectors (this time without HTTP Response Splitting)

    P.S.

    Today I’m planning to release above-mentioned method of bypassing this restriction made by Mozilla in Firefox >= 3.0.9.