1208339 - Cross-Origin restriction bypass with fetch using 302 redirection

Status: RESOLVED DUPLICATE of bug 1212669

(Core :: DOM: Core & HTML, defect)

Description

[Abdulrahman Alqabandi]

Attachment: PoC-FF.html

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.

Comment 1

[Abdulrahman Alqabandi]

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

Comment 2

[Abdulrahman Alqabandi]

Attachment: PoC using the same bug to extract value of hidden input elements

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.

Comment 3

[Josh Matthews [:jdm]]

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?

Comment 4

[Al Billings [:abillings - ex-MoCo]]

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

Comment 5

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

(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.

Comment 6

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

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

Comment 7

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

uploading my test case in case i did something wrong.

Comment 8

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Attachment: 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.

Comment 9

[Josh Matthews [:jdm]]

Can you reproduce this in FF 43 or 44?

Comment 10

[Abdulrahman Alqabandi]

(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

Comment 11

[Abdulrahman Alqabandi]

Attachment: Environment screenshot

Comment 12

[Abdulrahman Alqabandi]

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

Not yet, checking now.

Comment 13

[Josh Matthews [:jdm]]

You can get 44 from nightly.mozilla.org.

Comment 14

[Abdulrahman Alqabandi]

(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.

Comment 15

[Daniel Veditz [:dveditz]]

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?

Comment 16

[Abdulrahman Alqabandi]

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

Comment 17

[Josh Matthews [:jdm]]

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.

Comment 18

[Josh Matthews [:jdm]]

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.

Comment 19

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 20

[(no longer active)]

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

Comment 21

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 23

[Daniel Veditz [:dveditz]]

This vulnerability will be identified as CVE-2015-7184