Description
https://www.w3.org/TR/SVGTiny12/mimereg.html
I'd like to propose the deprecation of image/svg+xml
as the MIME type to describe SVG files. My reasoning is as follows:
- SVG files can contain executable code (JavaScript).
- Developers expect an
image/*
MIME type to mean data, not code. - A failure to separate data from code is a fundamental problem to software security. It turns up in:
- Buffer overflows
- SQL injection
- Cross-site scripting
- XML External Entities
- Xpath injection
- LDAP injection
The end result is that, due to the misleading MIME type for SVG files, most developers who don't know this nuance will accidentally handle them in such a way that makes Stored XSS vulnerabilities possible. It happened to us, and it's been a known problem for years.
The simplest solution is: move to application/svg+xml
.
This signals to developers that "this can contain executable code" and also makes naive MIME whitelists (that force a download rather than display/execute directly when a MIME type is absent) based on the image/
prefix less vulnerable.
Alternatively, we could fork into two MIME types:
image/svg+xml
which is not allowed to contain JavaScript, and if it does, is never executedapplication/svg+xml
which is allowed to contain JavaScript (maybe reserve thesvgx
file extension for these?)
Activity
gsnedders commentedon Oct 22, 2016
What practical effect does deprecation of
image/svg+xml
have, and how does it address concerns about scriptability of the format?Given the underlying XSS problems are caused by how browsers' implementation of SVG, and merely changing the spec to say
image/svg+xml
is deprecated does nothing to change their implementation. Realistically,image/svg+xml
is unlikely to ever go away. Now, the question is any change can ever be made to the scriptability of that Content-Type, and similarly I suspect that it won't be plausible, which would make any deprecation or reduction in scope unlikely to ever be implemented.paragonie-scott commentedon Oct 22, 2016
I thought the intent would be more clear from the forking suggestion, but the goal is to make
image/svg+xml
NEVER allow code execution. If you need this "feature", make it available under a separate format (demarcated as "application/foo" rather than "image/foo", possibly as a svgx file rather than svg).As the standard exists today, it's a security foot-cannon for developers.
thomassmailus commentedon Oct 27, 2016
My concern, knowing that there is a valid security concern, is that the security zealots in corporations wanting to clamp everything down... will allow different treatments of different types of the 2-3 types of diagrams that are all SVG graphics, such that the ones with code are marginalized and strangled off by security paranoia.. which would kill the ability to use SVG in many diagram contexts.
paragonie-scott commentedon Oct 27, 2016
It's difficult to have a level discussion when participants are classified as zealots and ascribed with a mental health disorder right out of the gate.
Partitioning into two types still allows SVG (as most people use it) to endure such paranoia.
As it stands now, the best solution to prevent SVG-assisted stored XSS payloads is to:
text/plain
withno-sniff
, force a download, etc.), or1 is the easiest for the backend, but the worst for the frontend. 3 is the easiest for the frontend (you can still use SVG, just not with embedded JS). 2 is what I'm currently doing in my projects, as a stop-gap measure. But eliminating the risk for myself doesn't help address the danger embedded in the standards. Hence, this Github issue.
Most security folks will prefer to just outright forbid all SVG files today when they hear of this risk. Changing the standard doesn't make SVG less acceptable to them. My proposal allows non-ECMAScript-burdened SVG files to still be tolerable by information security professionals.
gsnedders commentedon Oct 27, 2016
My intent was to get at how you intend on getting browser vendors to ship that (breaking) change? Browser vendors are unlikely to ship such a breaking change just because the spec has changed (over concern about how many SVGs will be broken as a result), and the security issue exists as long as browsers support script execution on
image/svg+xml
. Browser vendors are incredibly adverse to breaking content, and changing browsers is going to be far harder than changing the spec here.thomassmailus commentedon Oct 27, 2016
Implying things not stated by pulling content out of context doesn't help either. Nor does it change the reality experienced on the ground in the corporate world, where we would be passing notes on paper for maximum intellectual property security if they had their way.
If SVG is just to be a web graphic arts format and has no desire to become a full vector graphics file format, by all means, fragment away. We can always go WebCGM.
Seems like XSS is a problem with XSS and not SVG with JavaScript. Throwing out the baby with the bathwater is the wrong approach.
paragonie-scott commentedon Oct 28, 2016
SVG with JavaScript is a subset of XSS vulnerabilities.
paragonie-scott commentedon Nov 21, 2016
In the news: http://securityaffairs.co/wordpress/53650/malware/svg-images-locky.html
BigBadaboom commentedon Nov 21, 2016
If anyone is interested in seeing one of these SVG files, someone posted
one to StackOverflow today
http://stackoverflow.com/questions/40710399/malicious-javascript-embeded-in-svg-what-it-does
On 22 November 2016 at 04:42, Scott notifications@github.com wrote:
nikosandronikos commentedon Nov 22, 2016
We chatted about this in our telcon on 27th October 2016.
The justification for the suggestion is totally valid. But we think that suggesting a mime type change is unlikely to be accepted. Content Security Policy is the preferred way to tackle these kind of issues.
This work is not in scope of the SVG working group for the next year. Therefore, we suggest raising a thread on the Web Incubator Community Group (WICG), in the SVG category. The WICG is intended as a place to develop ideas prior to standardisation, and it's frequented by most of the spec editors and browser developers. You're likely to get a better discussion on WICG since this topic crosses many technical areas.
@paragonie-scott Are you happy to create a thread on WICG? I would suggest stating the problem (with no implied solution), then if you want to suggest a change to mime types, do that in a follow up post on the thread.
30 remaining items