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….
March 9th, 2007 at 6:28 pm
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…
March 9th, 2007 at 8:22 pm
Did you turn off meta refreshes in WebDeveloper? That would stop this from working.
March 10th, 2007 at 12:18 am
Also works in latest Safari, in case anybody is interested.
March 10th, 2007 at 5:25 am
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.
March 10th, 2007 at 6:07 am
works for me with firebug, webdeveloper etc. installed, so i guess comcor got meta refresh turned off
March 10th, 2007 at 6:10 am
Works for me in Safari 2.0.4!
March 10th, 2007 at 9:52 am
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.
March 10th, 2007 at 1:23 pm
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?
March 10th, 2007 at 8:33 pm
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
March 11th, 2007 at 7:01 am
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.
January 18th, 2008 at 2:54 am
Nice.
am I able to change someone’s HTTP header using Flash object?
July 3rd, 2008 at 4:40 pm
not really a big deal because i dont think there is a wide range of malicious javascript you can fire through the redirect
July 4th, 2009 at 8:15 am
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).
July 4th, 2009 at 8:19 am
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.
July 4th, 2009 at 9:02 am
@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.
July 6th, 2009 at 11:33 am
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.
July 6th, 2009 at 11:49 am
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.
July 6th, 2009 at 12:02 pm
@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.
July 11th, 2009 at 11:23 am
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.