Closed Bug 664983 (CVE-2011-2990) Opened 9 years ago Closed 9 years ago
Content Security Policy, violation reports, leak web proxy credentials
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.
Product: Firefox → Core
QA Contact: firefox → toolkit
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...
It does qualify for the bounty. Please mail contact details to firstname.lastname@example.org'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
Ever confirmed: true
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?
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.
(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.
WebKit doesn't send any headers in violation reports because I was worried it was too risky.
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.
(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...
I verified locally that this patch passes all the CSP tests, but I'm pushing to Try for a sanity check.
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.
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
Status: NEW → RESOLVED
Closed: 9 years ago
Component: Security → Security: CAPS
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Version: unspecified → 8 Branch
Comment on attachment 546647 [details] [diff] [review] don't send request headers please land on beta and aurora ASAP.
Component: Security: CAPS → DOM: Core & HTML
QA Contact: toolkit → general
qa- as no QA fix verification needed
Whiteboard: [sg:high] → [sg:high][qa-]
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.