-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SVG MIME Type (image/svg+xml) is misleading to developers #266
Comments
What practical effect does deprecation of Given the underlying XSS problems are caused by how browsers' implementation of SVG, and merely changing the spec to say |
I thought the intent would be more clear from the forking suggestion, but the goal is to make As the standard exists today, it's a security foot-cannon for developers. |
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. |
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:
1 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. |
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 |
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. |
SVG with JavaScript is a subset of XSS vulnerabilities. |
If anyone is interested in seeing one of these SVG files, someone posted 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:
|
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. @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. |
That's an additional layer that we use and recommend. The only other reasonable alternative is a massive developer education initiative. Something like:
...on every place a developer may learn about them. |
I agree that that a CSP would be the better option. Non breaking changes are better. |
I raised this concern in a less breaking view (sandboxing JS within SVG unless opted in) here - https://bugs.chromium.org/p/chromium/issues/detail?id=701523 But if we want to keep it same origin, Changing name to Scriptable Vector Graphics? |
I have been trying to enable gzip on the .htaccess file. This is what I located: https://www.w3.org/services/svg-server/ |
On http://www.iana.org/assignments/media-types/media-types.xhtml#text can be seen that text/javascript and text/ecmascript have been marked as obsolete with respect to their replacements application/javascript and application/ecmascript. |
Another question is if it's advisable to overload the file-extension further than anyway already or if it's not better advisable just to introduce svgs (static svg) as file-extension to express just static content without any javascript. Could be the other way around too by introducing svgd (dynamic svg). |
The latter proposition would eventually require notation of the mime-type in the svg-element if the code is embedded directly in the html as file-extensions never exist to separate the mime-type. There could be automatic recognition in browsers to omit this requirement but this would show that the new file-extensions are constructions only to satisfy outer (server-, security-)needs and not related to inner functionality. A clear concept here would be nice as the multimedia-files show already that it can be a big mess and a file-extension like avi is just a container and never allows to see any details about the used codex or required software. So even your player / editor can handle those files it doesn't mean that it can handle each of those files, |
Just seeing that using svg in plural is "svgs", that's the same like I proposed for "static SVG". So the proposition is bad as it can be misinterpreted. If the approach with two file-extensions should be realized another file-extension is advisable, i.e. ssvg (static SVG) and dsvg (dynamic SVG) even that's not sorting nice in alphabetical sorted lists of file-extensions (that was the reason why I placed the characters for the adjectives in the end at beginning). |
@DavidBruchmann You are right that "ssvg" sorts worse than "svgs" but it simply looks way better and more descriptive as well. If this would be to become a thing I would certainly vote for "ssvg". |
@PSSGCSim like I said there are reasons to decide against this two-file-extension-solution but if it should be chosen and enough supported then there are still other options like i.e. scgx and svgy where x stands just for executable. Naming is a considerable problem but unimportant if the images are directly embedded in HTML (NOT with the embed-tag!!! but all as one file). |
One interesting combination would be to inherit several svgs where some are dynamic but others not. |
With the same line of reasoning we must have |
Closing this based on #266 (comment) suggestion of raising in WICG instead. |
If anyone else want to open this issue elsewhere (e.g. WICG), feel free. I'm done. |
|
Notes on paper. You know, that’s actually not a bad idea. Hold on while I type that into my Excel Spreadsheet on this corporate Windows workstation that is just moments away from any number of yet more MS security flaws. That’s one hella strange infosec dept at your workplace... |
|
I am here reading this after seeing why our ORG decided to block and stop using all svg's across products. Nobody can trust SVG and thus nobody is allowed to use it unless it's their own file served on their own website. It's a great image format and we can't use it because nobody will take a suggestion like this seriously. There are plenty of use cases where you might want to allow an SVG from an external source to be served to users but the risk of them containing javascript is too great to allow it and the default stance by more and more companies to outright block all svg's from these use cases. |
@b-hayes have you blocked HTML too? |
yes |
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:image/*
MIME type to mean data, not code.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?)The text was updated successfully, but these errors were encountered: