914724 - JSONP HTTPS requests accept and execute a redirected HTTP response

Status: UNCONFIRMED

(Core :: Security, defect)

Description

[Kenneth Rahn Jr]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11

Steps to reproduce:

Using Firefox 23.0.1 on Windows:
1)  In HTML source, make a script block with a Javascript function.
2)  In the same HTML source, put a script tag that uses HTTPS to load a remote Javascript file.
3)  In the remote Javascript file, put a JSONP call to the function you wrote in step #1.
3)  On the remote server, make any HTTPS call to your Javascript file issue a 302 redirect to another location that will serve the file from step #3 file using HTTP.
4)  Then load the initial web page using HTTPS.


Actual results:

The HTTPS page will accept the 302 redirect, ignore the protocol change, and execute the HTTP-delivered JSONP call in the HTTPS environment.

In my test case:
  1)I am using Firefox 23.0.1 on Windows7
  2) The "302 redirected location" (that served the HTTP content) was in the same domain as the original script tag's "src" attribute (but another location in that domain).


Expected results:

The protocol change and redirect, from HTTPS to HTTP should have prevented the insecurely-delivered JSONP call from being run.

As it stands now, you don't know where the redirect will get its content. it could very well be malicious .. and Firefox blindly executes it in a secure, trusted, HTTPS context.

Comment 1

[Benjamin Smedberg]

This is something that mixed-content blocking should prevent, right? Otherwise, there's no limitation on HTTPS redirecting to HTTP, it's just a bad security practice in general. I don't see any reason for this to remain a private bug.

Comment 2

[Kenneth Rahn Jr]

Yes.  Imho, this is something mixed content should block.

If you change the <script> src to load with HTTP on a HTTPS page, it is properly blocked.

But if the <script> src loads with HTTPS, and is 302 redirected to a HTTP resource, on the same HTTPS page, it is not blocked.

I also tested on Nightly 26.0.a1 (2013-09-10) and the issue still exists.  I updated the platform and version number above.

I set "private" because it could be an exploit, and I wasn't sure which to select, so I defaulted to being paranoid.  If requested, I can set it as public (I think I can -- first time reporting a FF bug).

Please let me know anything else you require.

Comment 3

[Tanvi Vyas[:tanvi]]

Our content policies (all of them) don't handle redirects properly.  Here are 3 bugs that talk about this:

https://bugzilla.mozilla.org/show_bug.cgi?id=418354 (nsIContentPolicy cannot examine redirects)
https://bugzilla.mozilla.org/show_bug.cgi?id=456957 (specific to mixed content blocker)
https://bugzilla.mozilla.org/show_bug.cgi?id=878890 (extensions that don't work as intended because MCB doesn't handle redirects)

I agree with Ben, we can open this bug up.  It is a known issue and the other bugs we have open for it are public.