User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20150921151815 Steps to reproduce: 1. Create a 302 redirect on owned server (http://evil.guy/redir) which contains a 'Location:' header pointing to the victims website (ex: Location: https://twitter.com/) 2. Create page (http://evil.guy/PoC.html) that contains the exploit code as well as two iframes, one empty and one pointing to '//twitter.com/' directly. (please see attached PoC-FF.html) 3. Modify 'PoC-FF.html' replacing 'http://localhost/redir.php' with your own 302 redirector. 4. Visit 'http://evil.guy/PoC-FF.html' Actual results: - The iframe with href='//twitter.com/' is immediately blocked (as expected) - The second iframe, however, contains the full contents of twitter.com If the victim was logged into twitter then the iframe will display him as logged in, successfully bypassing firefox's Cross-Origin security, as you can probably imagine, this is extremely unsafe for FireFox users. Expected results: Both iframes should have been blocked. More precisely, the Fetch() function should not blindly follow 302 redirects but rather detect if a 302 is present then recheck origins.

P.S. Tested on Firefox 41.0 and it works.

This PoC is designed to extract twitters 'authenticity_token' value through the iframe despite the input being type=hidden. Proof this can be used to leak sensitive user data from external website. This effects almost any website.

Nikhil, I'm having trouble figuring out what the spec expects us to do for a no-cors fetch that receives a redirect status to a cross-origin URL. I guess the idea is that the redirection is allowed, but the result should be an opaque filtered response?

Reporter, please do not assign security keywords. That is a job for Mozilla staff.

(In reply to Josh Matthews [:jdm] from comment #3) > Nikhil, I'm having trouble figuring out what the spec expects us to do for a > no-cors fetch that receives a redirect status to a cross-origin URL. I guess > the idea is that the redirection is allowed, but the result should be an > opaque filtered response? That is correct.

I can't reproduce the steps outlined. Neither of the iframes load and the fetch() call clearly returns an opaque response. The blob is logged as size 0 and empty and creating a URL from that should lead to an empty blob. both frames remain empty for me. Using Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 ID:20150923030230 CSet: 19b4265d0d568d232fb3a34705f947b6db7496dc

uploading my test case in case i did something wrong.

the poc-ff.html should be saved in the same folder as the server. modify the redir path to be localhost:8080/redir.

Can you reproduce this in FF 43 or 44?

(In reply to Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?) from comment #8) > Created attachment 8666149 [details] > node server that serves file and redirect. > > the poc-ff.html should be saved in the same folder as the server. modify the > redir path to be localhost:8080/redir. I used a simple php file with the following: <?header('Location: https://twitter.com/');?> Also, I tested these on FF41 and FF42 beta, I see that you are using v44 which I have not tested on. (nor am I sure I can get v44) I will upload a screenshot (using v41) and displaying the exact response retrieved among other things. Also in case it matters, Im using Windows 8.1 64bit

(In reply to Josh Matthews [:jdm] from comment #9) > Can you reproduce this in FF 43 or 44? Not yet, checking now.

You can get 44 from nightly.mozilla.org.

(In reply to Josh Matthews [:jdm] from comment #13) > You can get 44 from nightly.mozilla.org. Yes I can confirm the bug does not seem to work on v43 or v44. Fetch is indeed returning an opaque response in both.

This is somewhat similar to bug 1111834 fixed in Firefox 37, for regular CORS though, not using fetch(). May have been fixed by bug 1199049? (see also bug 1199693) Bug 1194384 was duped to that one and seems particularly on point here ("Fetch event interception and CORS preflight requests are backwards"). If that was the fix it looks way too involved to backport to 42. Josh: does this look like a dupe of your bug 1194384?

I don't know if this matters by now, but this only works with {mode: 'no-cors'} passed to the fetch() function.

I just tried a mozilla-central build for 9/12 and can't reproduce the problem, so bug 1199049 does not seem to be the fix.

It's present in http://ftp.mozilla.org/pub/firefox/nightly/2015/09/2015-09-01-mozilla-central-debug/ and not present in http://ftp.mozilla.org/pub/firefox/nightly/2015/09/2015-09-02-mozilla-central-debug/, so http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2015-08-31&enddate=2015-09-02 suggests that it's bug 1184607.

I already have patches for this up in bug 1212669. Do I need to move them over here?

Sure, but it doesn't matter much either way.

I'm just going to land the patches in bug 1212669.

This vulnerability will be identified as CVE-2015-7184