Skip to content

Instantly share code, notes, and snippets.

@paragonie-scott
Last active May 8, 2020 03:49
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save paragonie-scott/20baf60c4980120cd764954119f290fb to your computer and use it in GitHub Desktop.
Save paragonie-scott/20baf60c4980120cd764954119f290fb to your computer and use it in GitHub Desktop.
image/svg+xml considered harmful: an open letter to member-svg-media-type@w3.org

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.

@joepie91
Copy link

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.

@paragonie-scott
Copy link
Author

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. :)

@koto
Copy link

koto commented Sep 19, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment