Issue metadata
Sign in to add a comment
|
Security: Cross-origin information leak via getSVGDocument() |
||||||||||||||||||||||
Issue description
<object>, <embed> and <iframe> have a method called getSVGDocument(), which returns a Document if the element embeds a SVG document, null otherwise. An error is thrown if the SVG document is cross-origin. But if the document is not a SVG document, then the return value is always null. This leads to a single bit of information leak (e.g. if a SVG document is behind a login, then attackers can determine whether the user was logged in).
Logically, this happens:
1. If not SVG, return null.
2. If cross origin, throw an error.
3. Return document.
Step 2 should happen before 1 to prevent an cross-origin information leak from occurring.
Here is a self-contained PoC that randomly selects a SVG or non-SVG document. You can type "data:text/html," in the omnibox and paste the following code. Refresh the page multiple times and you'll see that the parent page is always able to see whether the cross-origin frame contains a SVG document (data:-URLs have a unique origin).
<iframe id="frame"></iframe>
<output id="output">
<script>
var frame = document.getElementById('frame');
frame.onload = function() {
var output = document.getElementById('output');
try {
frame.getSVGDocument(); /* null iff (cross-origin) document is not SVG */
output.value = 'Cross-origin frame: NOT SVG';
} catch (e) {
output.value = 'Cross-origin frame: SVG';
}
};
/* Randomly select SVG or non-SVG document for demo. */
var svg = 'data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><text y="20">SVG</text></svg>';
var notsvg = 'data:,Not svg';
frame.src = Math.random() < 0.5 ? svg : notsvg;
</script>
The security check is auto-generated via the following IDL files:
HTMLObjectElement.idl, HTMLEmbedElement.idl, HTMLFrameElement.idl
[CheckSecurity=ReturnValue, RaisesException] Document? getSVGDocument();
,
Mar 15 2016
This is not a security vulnerability, not enough of a leak to be useful for any kind of vulnerability.
,
Mar 15 2016
I disagree, this is something that should be fixed. The same origin policy prevents information leakage from one origin to another origin. The fact that this bug allows websites to get one bit of information from other websites is a direct violation of this guarantee. Even one deterministic bit of information leakage can have undesirable consequences, because a query can be repeated multiple times to get more bits of information. For instance, consider the following scenario: 1. Some website uses predictable URLs, e.g. http://example.com/year_report_graph_2015_up.svg or http://example.com/year_report_graph_2015_down.svg FOR AUTHENTICATED USERS ONLY. 2. Someone who wants to take advantage of this (file name "up" = shares will likely become more valuable, "down" = shares will likely go down in value) can trick the user into opening a page that does the following: - Load year_report_graph_2015_up.svg and year_report_graph_2015_down.svg in a frame. - Use this reported bug to tell whether the files exist. - If they do, report back to some backend. - Sell / buy shares based on this confidential information. SVG images are part of the web, and they are also actively used, so I find it plausible that there exist sites where this scenario is realistic.
,
Mar 15 2016
(moving back from WontFix to Untriaged for a second look, because I don't know if comments on closed issues get read).
,
Mar 15 2016
> because I don't know if comments on closed issues get read). My guess is most people still read comments on WontFixed bugs (I certainly do). There is no need to undo a WontFix to call attention to a comment. > The same origin policy prevents information leakage from one origin to another origin. The fact that this bug allows websites to get one bit of information from other websites is a direct violation of this guarantee. This kind of attack is well known with img tags and onerror events. The page at https://www.chromium.org/Home/chromium-security/client-identification-mechanisms has a comprehensive list of known mechanisms. Searching for "onerror" should highlight the relevant paragraph. Another page mentions how a single bit of information leak isn't likely to impact passive fingerprinting: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-isn-t-passive-browser-fingerprinting-including-passive-cookies-in-Chrome-s-threat-model- I was going to WontFix this again given the information in above links, but it looks like bug 21338 fixed this issue way back in 2009. Maybe it regressed since then? Adding more labels and CC'ing some OWP people who might still be interested in looking at this.
,
Mar 15 2016
Good point about <IMG> events. The bug you're linking to is more severe, because it leaks the document, while the bug that I reported only tells whether a given resource is a SVG document.
,
Mar 15 2016
Didn't notice that, thanks for closing.
,
Jun 22 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rob@robwu.nl
, Mar 14 2016