image/svg+xml considered harmful: an open letter to member-svg-media-type@w3.org

SVG Fails.md

Update

Filed an issue to address this particular concern.

Thanks joepie91 for finding the folks responsible and getting the conversation started.

---

Currently, SVG is a security foot-cannon that allows attackers to upload a Stored XSS payload when a user views the image directly. Example.

Specifically, you can include JavaScript in an SVG document, and it will execute in all browsers if accessed directly.

This is contrary to what developers expect from a MIME type that begins with image/.

I'd like to propose:

• That the current use of SVG be moved to application/svg+xml
• If we are to have an image/svg+xml MIME type, then clients MUST not allow JavaScript (or any other code execution)

Thank you for your time.

This is posted publicly because when I tried to email them as indicated on this page, I got this:

Delivery to the following recipient failed permanently:

     member-svg-media-type@w3.org

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain w3.org by maggie.w3.org. [128.30.52.39].

The error that the other server returned was:
550-Sorry, this mailing list is no longer active. Please see
550 http://www.w3.org/Mail/

Yeah, no.

As you say, the problem only occurs when a user views the image directly..
The same is true for other images though. Remember when IE happily accepted script tags in GIF files? The X-Content-Type-Options: nosniff header was invented for this.

But the generally accepted best practice is to just not allow image uploads as is. I suggest re-rendering the images in a preferred format. Do this by "taking the pixels" and moving them to a new file. There's no way to comprehensively remove all unnecessary strings, comments and other potential danger (whitelist versus blacklist approach).

I suggest re-rendering the images in a preferred format. Do this by "taking the pixels" and moving them to a new file.

There are, to my knowledge, no readily available tools that can do this without severe quality loss and/or filesize increases for compressed formats.

But the generally accepted best practice is to just not allow image uploads as is. I suggest re-rendering the images in a preferred format.

I'd like you to meet my good friend, ImageTragick. Or a whole host of PHP ext/gd issues over the years.

Like hell I'm taking untrusted user input and passing it to the image manipulation libraries available to PHP developers. :)

If you allow serving unsanitized user-uploaded content off a sensitive domain (e.g. the one with interesting cookies or the main application origin), you're going to have a problem nonetheless. You can mitigate some of the vectors with e.g. response headers (Content-Type or the nosniff header), but not all of them can be addressed that way because of browser plugins. This has been demonstrated e.g. by Rosetta Flash or Comma Chameleon.

If you choose not to sanitize (e.g. because you're scared of image processing libs memory corruption bugs), move the uploads off your origin. - you're not going to win a lot with just enforcing a Content-type header change.