Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 664983 (CVE-2011-2990)

Content Security Policy, violation reports, leak web proxy credentials

RESOLVED FIXED in Firefox 6

Status

()

Core
DOM: Core & HTML
--
major
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: Mike Cardwell, Assigned: bsterne)

Tracking

8 Branch
mozilla7
Points:
---
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox5- affected, firefox6+ fixed, firefox7+ fixed, status2.0 wanted, status1.9.2 unaffected, status1.9.1 unaffected)

Details

(Whiteboard: [sg:high][qa-])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

When Firefox 4 sends a Content Security Policy report due to a violation, it sends the full set of HTTP request headers that would have been used in the request. Including the Proxy-Authorization HTTP request header. This request header normally contains the base64 encoded username/password that the browser is using to authenticate against a web proxy. Web proxies typically strip this header before forwarding on the request.

Because the CSP report contains this header stuffed in some JSON in the POST data, it is not stripped. All a website owner has to do is purposefully violate their own CSP policy so that every visitor generates a CSP violation report, and then scan those reports for Proxy-Authorization data.

I have prepared a blog post describing this vulnerability and will be publishing it early next week.

I don't believe it is necessary to send *any* of the HTTP headers in the CSP violation report. It is certainly dangerous to send Proxy-Authorization and Cookie headers.

Reproducible: Always
Would you please consider giving us time to fix this vulnerability before you publish details? Responsible disclosure would help our users.
Component: Security → Security
Product: Firefox → Core
QA Contact: firefox → toolkit
Whiteboard: [sg:high]
(Reporter)

Comment 2

6 years ago
Yes. I wasn't sure if you'd consider it important enough to worry about disclosure. I made this bug private just in case. Seeing as you've asked me to hold off, I will hold off publishing until a fix is produced.

Out of interest, does this issue qualify for your bug bounty program? Whilst it only affects a small proportion of users, it does affect them pretty badly...
Yes.
It does qualify for the bounty. Please mail contact details to security@mozilla.org--don't post them to the bug since it will eventually become public. If the mail address in this bug works we can use that (some people use a junk address for bugzilla to avoid spam, and since yours is "mozilla@" we think it could be one of those). You can encrypt with our PGP key if you want to
https://www.mozilla.org/security/#pgpkey
Status: UNCONFIRMED → NEW
status1.9.1: --- → unaffected
status1.9.2: --- → unaffected
status2.0: --- → wanted
status-firefox5: --- → affected
status-firefox6: --- → affected
status-firefox7: --- → affected
tracking-firefox5: --- → -
tracking-firefox6: --- → +
tracking-firefox7: --- → +
Ever confirmed: true
(Assignee)

Updated

6 years ago
Assignee: nobody → bsterne

Comment 6

6 years ago
Dveditz, we're about 3 weeks from the end of Firefox 6 (remember we need about 10 days lead since we ship on the migration date) Is this something that's going to get attention in the 6 cycle or do we bump it to 7?
(Assignee)

Comment 7

6 years ago
I'll have a patch soon (day or two).  I'll check with Adam (CC'd) who implemented CSP in WebKit on how they handle this. I'm wondering if we should blacklist certain headers, or whitelist a few headers that will be useful for servers when tracing the source of the violations.
(Assignee)

Comment 8

6 years ago
(In reply to comment #0)
> I don't believe it is necessary to send *any* of the HTTP headers in the CSP
> violation report. It is certainly dangerous to send Proxy-Authorization and
> Cookie headers.

I don't see the danger of sending Cookie headers. The reports must be sent to the same origin that the violation occurred on, so that server will already have the cookies.  Am I missing some part of this threat?

I do agree that third-party authorization tokens, like proxy-auth, shouldn't be sent.  I am in the process of working out which ones specifically we should strip or, as I said in comment 7, if we should just whitelist a few useful headers.  The goal of this feature, by the way, is to enable backtracing and debugging of the content violations by server operators.

Comment 9

6 years ago
WebKit doesn't send any headers in violation reports because I was worried it was too risky.

Comment 10

6 years ago
I don't really think the same-origin restriction on the report-uri buys us that much.  For it to matter, we have to assume the attacker controls the report-uri, right?  What makes us think there isn't a URL on the origin that doesn't publish the contents of POST requests publicly.  For example, a RESTful blog site might have a URL like the following:

http://blog.example.com/bsterne/entry/394792492984/comment

If you POST to that URL, the site might add a comment to one of bstrene's blog entries (e.g., containing the user's cookie header).  The attacker can just pick that on-origin URL as the report-uri.
(Reporter)

Comment 11

6 years ago
(In reply to comment #8)

> I don't see the danger of sending Cookie headers. The reports must be sent
> to the same origin that the violation occurred on, so that server will
> already have the cookies.  Am I missing some part of this threat?

I may just be being overly cautious with that one, I'm not sure. There are potential scenarios where web proxies might use cookies for authentication with the browser. I did actually come across one situation where a cookie that my website didn't set, appeared in the Content Security Policy report.

It had the name "BCSI-CS-SOME_16_CHAR_HEX_STRING" which looks like it has something to do with the following proxy hardware: https://www.bluecoat.com/

I don't know if the contents of that cookie were sensitive.

> I do agree that third-party authorization tokens, like proxy-auth, shouldn't
> be sent.  I am in the process of working out which ones specifically we
> should strip or, as I said in comment 7, if we should just whitelist a few
> useful headers.  The goal of this feature, by the way, is to enable
> backtracing and debugging of the content violations by server operators.

Can you describe a situation where a server operator would find some value in being able to see the Cookie header in a CSP violation report?
(Reporter)

Comment 12

6 years ago
(In reply to comment #11)

> Can you describe a situation where a server operator would find some value
> in being able to see the Cookie header in a CSP violation report?

By this, I mean. Even without any request headers being sent, the server operator already knows the IP address the request came from, the URL of the page they were looking at, the URL that was blocked on that page, what type of request it was eg img/object etc, and also they have their standard server side logs which usually contain the referer and user-agent etc.

Do they really gain that much from also being able to see the request headers of the blocked request? It's my opinion that the CSP report even without any of the request headers provides all the information a server operator would need to understand why a CSP violation was triggered...
(Assignee)

Comment 13

6 years ago
(In reply to comment #11)
> I may just be being overly cautious with that one, I'm not sure. There are
> potential scenarios where web proxies might use cookies for authentication
> with the browser. I did actually come across one situation where a cookie
> that my website didn't set, appeared in the Content Security Policy report.
> 
> It had the name "BCSI-CS-SOME_16_CHAR_HEX_STRING" which looks like it has
> something to do with the following proxy hardware: https://www.bluecoat.com/
> 
> I don't know if the contents of that cookie were sensitive.

> Can you describe a situation where a server operator would find some value
> in being able to see the Cookie header in a CSP violation report?

I could imagine a stored XSS payload that only shows up in a webpage if the user is authenticated.

I've been doing some reading this morning, and it looks like one sensible approach might be to strip hop-by-hop headers, which, per the spec [1]:

> are meaningful only for a single transport-level connection, and are not
> stored by caches or forwarded by proxies.

This would include Proxy-Authenticate, and Proxy-Authorization.  I worry, though, that this adds significant complexity relative to Adam's approach (comment 9) and who knows if there are other headers lurking out there that the violation reports might expose down the road.  I'm really leaning toward the conservative approach and removing the request headers from the report altogether.  The people who are likely to object to this change are not copied on this bug, so this might be a "forgiveness-rather-than-permission" situation.

dveditz, what do you think?

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-7.1.3.1
(Assignee)

Comment 14

6 years ago
Created attachment 546647 [details] [diff] [review]
don't send request headers

I verified locally that this patch passes all the CSP tests, but I'm pushing to Try for a sanity check.
Attachment #546647 - Flags: review?(dveditz)
Theoretically any one of several different headers could result in different content being served (cookies and auth, of course, but also Accept headers and even user-agent) which is why we wanted to echo them back. But that was always dicey with the report-uri restricted to same-origin, and the current spec ended up with the looser "same public-suffic plus one" (base domain).

We could play games and echo back only headers that are identified in a Vary: response. Is that a reasonable use of Vary: or pure crazy talk? We could bring it up in the standards group if we cared to, for now let's not echo any headers.

Comment 16

6 years ago
I'm not sure Vary is that widely used because it causes caching problems in older versions of IE and in some proxies.  In this attack scenario, the attacker would include "Vary: Cookie", which means we'd need to filter the list of headers in Vary anyway.
Comment on attachment 546647 [details] [diff] [review]
don't send request headers

r=dveditz
Attachment #546647 - Flags: review?(dveditz)
Attachment #546647 - Flags: review+
Attachment #546647 - Flags: approval-mozilla-beta?
Attachment #546647 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 18

6 years ago
http://hg.mozilla.org/mozilla-central/rev/d31ac54ee182
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Component: Security → Security: CAPS
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Version: unspecified → 8 Branch

Comment 19

6 years ago
Comment on attachment 546647 [details] [diff] [review]
don't send request headers

please land on beta and aurora ASAP.
Attachment #546647 - Flags: approval-mozilla-beta?
Attachment #546647 - Flags: approval-mozilla-beta+
Attachment #546647 - Flags: approval-mozilla-aurora?
Attachment #546647 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 20

6 years ago
Aurora merge:
http://hg.mozilla.org/releases/mozilla-aurora/rev/e3b5c473098e

Beta merge:
http://hg.mozilla.org/releases/mozilla-beta/rev/5f5fb2bc9fc9
Component: Security: CAPS → DOM: Core & HTML
QA Contact: toolkit → general

Updated

6 years ago
status-firefox6: affected → fixed
status-firefox7: affected → fixed
Alias: CVE-2011-2990
qa- as no QA fix verification needed
Whiteboard: [sg:high] → [sg:high][qa-]
Group: core-security
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+

Comment 23

4 years ago
Without cookies in the violation report it is not feasible to identify logged-in user without too may false positives coming mostly from corporate proxies. In practice those reports comes not from XSS attacks but rather from problematic browser extensions or even a malware infection that inject own scripts into each page the user visits. It is very desirable to notify the user about that ASAP especially if foreign scripts or CSS are detected during sensitive operations.

An alternative of including cookie-like information into the report URL is not attractive. First using dynamic non-cookie headers may not be a supported configuration on the web server software. Second, when the time of a session cookie is much shorter than the desired cache-time, then for the report URL to be valid the cache-time must decreased leading to traffic increase. 

It would be nice if CSP would allow to specify a cookie or a cookie list that should be sent together with the report. It would simply deployment a lot when the user identification is important. Should this be raised with CSP 1.1 draft?
You need to log in before you can comment on or make changes to this bug.