664983 - (CVE-2011-2990) Content Security Policy, violation reports, leak web proxy credentials

Status: RESOLVED FIXED

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

Description

[Mike Cardwell]

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

Comment 1

[Benjamin Smedberg]

Would you please consider giving us time to fix this vulnerability before you publish details? Responsible disclosure would help our users.

Comment 2

[Mike Cardwell]

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

Comment 3

[Benjamin Smedberg]

Yes.

Comment 4

[Daniel Veditz [:dveditz]]

It does qualify for the bounty. Please mail contact details to [e-mail]--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

Comment 6

[Asa Dotzler [:asa]]

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?

Comment 7

[Brandon Sterne (:bsterne)]

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.

Comment 8

[Brandon Sterne (:bsterne)]

(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

[Adam Barth]

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

Comment 10

[Adam Barth]

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.

Comment 11

[Mike Cardwell]

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

Comment 12

[Mike Cardwell]

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

Comment 13

[Brandon Sterne (:bsterne)]

(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

Comment 14

[Brandon Sterne (:bsterne)]

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

Comment 15

[Daniel Veditz [: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

[Adam Barth]

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 17

[Daniel Veditz [:dveditz]]

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

r=dveditz

Comment 18

[Brandon Sterne (:bsterne)]

http://hg.mozilla.org/mozilla-central/rev/d31ac54ee182

Comment 19

[Asa Dotzler [:asa]]

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

please land on beta and aurora ASAP.

Comment 20

[Brandon Sterne (:bsterne)]

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

Beta merge:
http://hg.mozilla.org/releases/mozilla-beta/rev/5f5fb2bc9fc9

Comment 21

[u279076]

qa- as no QA fix verification needed

Comment 22

[Raymond Forbes[:rforbes]]

rforbes-bugspam-for-setting-that-bounty-flag-20130719

Comment 23

[Igor Bukanov]

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?