JSONP HTTPS requests accept and execute a redirected HTTP response




5 years ago
7 months ago


(Reporter: Kenneth Rahn Jr, Unassigned)


(Depends on: 2 bugs, Blocks: 1 bug)

26 Branch
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




5 years ago
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

5 years ago
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.
Flags: needinfo?(tanvi)

Comment 2

5 years ago
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.
Flags: needinfo?(tanvi)
OS: Linux → Windows 7
Version: 23 Branch → 26 Branch

Comment 3

5 years ago
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.


5 years ago
Group: core-security


5 years ago
Blocks: 815321
Depends on: 456957, 418354, 878890
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Component: Networking: HTTP → Security
You need to log in before you can comment on or make changes to this bug.