Add telemetry to determine how often script is used in SVG
Categories
(Core :: SVG, task)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
Details
(Keywords: sec-want)
After triaging bug 1745643 (RE user-uploaded-SVG being an XSS vector if SVG file is viewed directly), I chatted with dveditz and freddyb about existing & possible-future mitigations.
The current mitigation seems to be using CSP to turn off script by default.
One strawman security-improving option which was brought up (which is maybe-infeasible but worth entertaining): perhaps we could lock down SVG documents by default to some extent -- disabling scripting at a minimum -- and offer some sort of opt-in mechanism (standardized HTTP header, for example) for sites that really want to allow scripts in SVG content. (Sites could also use inline-SVG-in-HTML as another quick-and-easy workaround, e.g. data:text/html,<!DOCTYPE html><svg><script>...)
To determine whether this strawman "lockdown SVG by default" proposal (or something in that direction) is feasible, it would be useful to know:
(a) how often a SVG document is loaded in a document context (at a top-level or in iframe/embed/object)
(b) how often JS is actually used in such a document.
(c) perhaps also: how often external resources are used in such a document (which would be blocked in an SVG-as-an-image context)
This would give us an idea of whether it might be feasible to standardize some sort of default-on mitigation (with sites able to opt in to the existing permissive behavior).
Filing this bug on adding telemetry to inform these points, if it feels worth pursuing.
|
||
Comment 1•3 years ago
|
||
(a) how often a SVG document is loaded in a document context (at a top-level or in iframe/embed/object)
compared against how often used in an <IMG> context.
|
Reporter | |
Comment 2•3 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #1)
compared against how often used in an <IMG> context.
Right, yeah (which includes css backgrounds and <video> poster images -- Document::IsBeingUsedAsImage would be the relevant API to check, to count those cases).
(We would want to separately-count or throw out cases where SVG is used inline in an HTML document - that's a case where scripting is allowed, and we wouldn't be proposing to change that.)
The theory behind any hypothetical change that we might make here would be:
- There's presumably (pending data) a relatively-small space of sites that actually have "SVG Applications", i.e. that take advantage of the fact that you can have scripts in SVG.
- There's presumably a relatively-much-larger space of sites that might want to serve SVG files as images (whether user-provided, or obtained as e.g. icons from a third party, or something else)
- For the sites in this second category: the developers are (or should be) concerned/very-careful about serving any not-fully-trusted SVG files because of the potential for trivial XSS attacks. They need to know & apply the appropriate CSPs or be at risk of getting hosed. So: the status quo kind of sucks for this group.
- Depending on the relative magnitude of the sizes of these two groups, it might conceivably be worth it to change default behavior such that SVGs are more locked-down and image-like by default. This hypothetical change would come at a cost to the first group (they'd need to apply whatever the opt-in mechanism is, to prevent breakage), in the interests of benefiting the second group (letting them be less concerned about using SVG images), and potentially in the interests of broadening the use of SVG in general as an image-format.
|
|
Reporter | |
Comment 3•3 years ago
|
||
(of course, any hypothetical change would need to be standardized & coordinated with other browser vendors, too.)
|
|
||
Comment 4•3 years ago
|
||
The "safe" default is to treat them all as images unless given some other signal, which handily lines up with the standard Content-type image/svg+xml. If in practice "SVG Applications" are a relatively small percentage it seems appropriate to make them declare that use through a "Document" Content-type. The existing text/xml ought to work, but if it's important to signify SVG specifically we could invent text/svg+xml or something similar. Opt-in, and clearly marked as similarly powerful to the text formats XML and HTML and not a self-contained "image".
Wouldn't work for .svg applications hosted as a local resource (files, or browser resource) because there's no similar metadata, but that's going to be a problem with any scheme we come up with. If the opt-in is in the document itself then we're back to "untrustworthy". Might need a new file extension, too. I'll throw out .svgdoc as an ugly starter and see if someone comes up with better.
Agreed on the long road ahead: measurement and standardization take time.
|
||
Comment 5•3 years ago
|
||
Some further discussion on this here: https://github.com/w3c/svgwg/issues/837 and https://github.com/w3c/svgwg/issues/266
Description
•