| Issue 313737: | Disclose domain of redirect destination taking adventadge of CSP | |
| 13 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Steps to reproduce the problem:
So, the CSP report-uri sends us similar data structure:
{"csp-report":{"document-uri":"http://lh:4567/test","referrer":"","violated-directive":"script-src 'unsafe-inline' https://*.facebook.com","original-policy":"default-src *;script-src 'unsafe-inline' https://*.facebook.com; report-uri http://lh:4567/csp-report.php;","blocked-uri":"https://pinterest.com","status-code":200}
blocked-uri contains domain of blocked URL. I use following CSP header:
default-src *;script-src 'unsafe-inline' https://*.facebook.com; report-uri http://lh:4567/csp;
so all non facebook domains will be reported. It discloses information *does* certain URL redirect to other domain, and even gives us full domain name (where subdomain can be sort of secret). Similar to http://homakov.blogspot.com/2013/03/pwning-your-privacy-in-all-browsers.html issue which Chrome Team left as WontFix.
But this one works much faster. When I load
<img src=FB.com/?client_id=1>
<img src=FB.com/?client_id=2>
<img src=FB.com/?client_id=3>
I can leak all OAuth clients user authorized just looking through reports - all violation will contain successful redirects.
So I can load top 100-500 clients in images and see which of them current user installed on his FB account. This is clearly a privacy issue (and not only use case of this bug)
What is the expected behavior?
What went wrong?
As a solution I recommend to not send any domain name. Oh, wait, it is not a solution either. It's quite difficult to fix because *any* detection of violation also reveals info about redirect.
Did this work before? N/A
Chrome version: 30.0.1599.101 Channel: stable
OS Version: OS X 10.9.0
Flash Version: Shockwave Flash 11.9 r900
Oct 31, 2013
It only gets worse in 1.1, as currently specced: http://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html I'd appreciate opinions on whether this is worth trying to mitigate, and suggestions around how we'd do that if so. As noted in the report, the only real solution is to not send a report in cross-origin cases, which would make the entire reporting feature fairly useless.
Oct 31, 2013
It is *already* worse and working. We don't even need onsecuritypolicy even for this.
I just checked with
<meta http-equiv="Content-Security-Policy" content="frame-src https://github.com/notifications;report-uri /asdf">
and detection of login is super fast. Thankfully CSP doesn't look at query part, or there would be a way to leak authentication params.
Nov 1, 2013
Harumph. Thinking about this more, this is pretty bad, and I feel like we ought to try and solve it, although I, too, don't see anything near an obvious solution. Is it worth having a meeting to discuss whether this is a fundamental limitation/problem with CSP?
Nov 3, 2013
Also we can bruteforce /id123123 with
def btw(from, to)
clue = ' http://host/id'
clue + (from..to).to_a.join(clue)
end
get '/between' do
from, to = params[:from].to_i, params[:to].to_i
allowed = btw(from, to)
return r=<<HTML
<meta http-equiv="Content-Security-Policy" content="img-src http://host/id #{allowed};report-uri /report?from=#{from}&to=#{to}">
<img src="http://host/id
HTML
end
get '/test' do
return r=<<HTML
<iframe src="/between?from=1&to=10000"></iframe>
<iframe src="/between?from=10000&to=20000"></iframe>
<iframe src="/between?from=20000&to=30000"></iframe>
...
HTML
end
Nov 11, 2013
Issue 317583 has been merged into this issue.
Nov 12, 2013
(No comment was entered for this change.)
Labels:
M-32 Cr-Blink
Nov 18, 2013
Bulk unrestriction of Severity-none bugs.
Labels:
-Restrict-View-SecurityTeam -Type-Bug-Security Type-Bug
Nov 22, 2013
(No comment was entered for this change.)
Labels:
-Security_Impact-Stable
Feb 11, 2014
Issue 342737 has been merged into this issue.
Feb 11, 2014
still not fixed. report-uri is not necessary http://homakov.blogspot.com/2014/01/using-content-security-policy-for-evil.html
Feb 11, 2014
I disagree with Security-Severity-None. This allows an attacker to trivially detect logged in websites, which opens a host of opportunities for phishing, spoofing, XSRF, XSS against logged-in pages, fingerprinting, targetted MiTM, server DoS, etc. At the very least, the privacy implications are major. Leaking visited history through the :visited pseudo-class is child's play compared to this.
Feb 12, 2014
I've been thinking about this a bit over the last few weeks while reviewing the spec before pushing for last call. I don't think there's a mitigation mechanism that's effective, short of removing path support from CSP 1.1 entirely. I think paths are valuable, but not valuable enough to leave this vector open. I've proposed removal at http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html. Please feel free to weigh in with suggestions.
Feb 12, 2014
Mike, report-uri is not useful in the wild, why not just leave console message, and fire "onload" event?
Feb 12, 2014
Firing the onload event for cross-origin image loads is probably a good idea in general, and I've already started poking at that to align the behavior with iframes. I guess I disagree that report-uri isn't useful in the wild. It's more work, and slower, certainly, but effective.
Feb 12, 2014
I meant to add that firing the onload event for images doesn't actually solve the problem at all, as you can easily read the width/height to detect whether the image actually loaded. It's worth doing, as it makes the task marginally less trivial, but it's not a real mitigation to any extent.
Feb 12, 2014
I just don't see a way to keep report-uri and to get rid of this vuln at the same time. Well, looking forward what will be implemented.
Feb 12, 2014
Ha, good job finding another bypass. So you can also set height/width to the real ones... And show some white square instead. I don't recall any other cross origin properties you can read.
Feb 12, 2014
I'd invite you to hop into the public-webappsec thread to make that case. I think dropping paths mitigates the risk to the point where it's acceptable (only cross-origin redirects would be detectable, rather than the ability to brute-force intra-origin paths).
Feb 12, 2014
Paths will mitigate this bug most of the time, but it will harm CSP goal too - what if I find a way to upload HOST/my/avatar.png and only HOST/widget.js is supposed to be used on victim's site? This is something to also consider..
Feb 12, 2014
Absolutely. It's a balance between strengthening CSP's expressive power, and the ability of that expressive power to be used against the user. In any event; this is a spec discussion that isn't at all specific to Chrome, and we should really bring it over to the thread I started on public-webappsec: http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html I'll certainly implement whatever the WG agrees upon as a reasonable mitigation.
Aug 15, 2014
I am a bit confused here. The result of this seems to be http://www.w3.org/TR/CSP11/#source-list-paths-and-redirects but this actually doesn't solve the original issue highlighted by Egor doesn't it ?
Aug 15, 2014
Yes my issue was only partially solved. Domain of destination is still disclosed.
Aug 15, 2014
hi Egor, thanks for your answer. Indeed AFAIU as I wrote to the we lists "in [0] I see a section that has been written in order to address the issue spotted by Egor Homakov in [1]. Now I might have well misunderstood the all story but IMHO this doesn’t seem to solve the original issue. E.g. if we have img-src example.com rahter than img-src example.com not-example.com/path what is going to happen? AFAIU the redirect to not-example.com will still happens hence the leaking." [0] http://www.w3.org/TR/CSP11/#source-list-paths-and-redirects [1] http://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html |
||||||||
| ► Sign in to add a comment | |||||||||
Owner: mkwst@chromium.org
Cc: jww@chromium.org abarth@chromium.org
Labels: Security_Impact-Stable Security_Severity-None