31

I have a site, where people can upload graphics, you might think of it like an image hoster or a forum for pictures.

Now, I allow upload of raster graphics to a certain size, but no vector graphics as of yet. I'd like to allow SVG upload as well, but there are two concerns circling my head:

  1. Could an SVG be constructed in such way, that when reading meta data it makes the server unresponsive. and could be used as DoS attack on the server?
  2. Could an SVG be constructed in such way, that when rendering the SVG on the client, the client becomes unresponsive and potentially makes every users browser on my site crash?

Also, would it be good practice to generate a small (200x200px) PNG for a thumbnail, or is it better to just manipulate the SVG itself with a zoom factor or something?

In case those SVG exploits are possible, how can I protect myself against them?

polemon
  • 413
  • 1
  • 4
  • 6
  • Although old, this may be of interest: [owasp - The image that called me](https://owasp.org/www-chapter-norway/assets/files/The_image_that_called_me.pdf) – djvg Apr 06 '21 at 11:54

2 Answers2

20

Could an SVG be constructed in such way, that when reading meta data it makes the server unresponsive. and could be used as DoS attack on the server?

What do you mean by metadata? If you are after width and height, you would have to parse the SVG files at least partially to get it; there's no shortcut of reading a few bytes from the header like there is with many bitmap formats. That brings in the usual risks of XML parsing, such as:

  • external entity/DTD-subset inclusion attacks against remote files, local-network sensitive resources, local-machine sensitive files and device-files
  • nested entity expansion bombs
  • pathologically-nested tag structures might hit recursion resource limits

as a standard precaution you would disable all DTD processing, XInclude, XSL, XSI and entity resolution.

Could an SVG be constructed in such way, that when rendering the SVG on the client, the client becomes unresponsive and potentially makes every users browser on my site crash?

Possibly, but it's just as possible that could happen with a bitmap format. See eg the corrupt PNG file vulnerabilities of a while back.

More of a concern for SVG files is that they can include JavaScript, which will operate in the security context of the hosting site, so you have cross-site-scripting to worry about.

Actually all types of uploaded file are vulnerable to this, albeit not in such a direct, easy-to-exploit way. In some cases browsers (particularly IE) will content-sniff them, and if they see things that look like tags they may potentially reinterpret them as HTML, including JavaScript. Also there are some side-issues with treating uploaded files as Java applets and Flash policy files.

The standard mitigation for all of these problems is to serve your untrusted resources, whether bitmap, SVG or anything else, from a different domain to your main site: a domain that has no sensitive session (cookie/auth) information in it and no ability to script into your main site's domain.

Also, would it be good practice to generate a small (200x200px) PNG for a thumbnail, or is it better to just manipulate the SVG itself with a zoom factor or something?

That would be a nice touch, but you'd have to drag in some dependencies to render to bitmap, for example Batik if you are using Java. Naturally bringing in a new complex library increases attack surface; it might be a good idea to run the thumbnailer as a separate low-privilege-account low-priority daemon task.

bobince
  • 12,494
  • 1
  • 26
  • 42
  • 2
    According to the [W3C Wiki](https://www.w3.org/wiki/SVG_Security), SVG file embedded as an image should not be allowed to execute scripts. Do you have any experience if this is followed by the browsers? – cdauth Mar 22 '17 at 14:02
  • 1
    Yes, SVG-in-img is unscriptable in all supporting browsers I'm aware of. (Of course an attacker could still cause the browser to go directly to the SVG image.) – bobince Mar 23 '17 at 16:29
  • I attempted to pwn myself with Google Drive and direct links to SVG. I suspect this (and HTML) is one the many reasons that googleusercontent.com exists (as opposed to drive.google.com): I wasn't able to access my Google cookie or really *anything* because, obviously, it is on a different domain. Having a separate domain for user content (or simply using a CDN) may likely eliminate this risk. – Jonathan Dickinson Mar 02 '19 at 00:50
10

Any action your web application performs is potentially dangerous. File upload is one of the more dangerous features because it can lead to remote code execution.

The problem with uploading any file to the server is that it might not actually be the file you want. I don't know what platform or methodology you are using, but I have fooled file upload systems many times to upload a .php or .asp file and execute it. It doesn't sound like you are rendering the SVG on the server side (that would be kind of strange anyway), so the raw XML within the SVG doesn't really matter to your server.

In terms of #2, yes svg memory corruption vulnerabilities are common and I am confident that more exist. But again this is going to be true for just about any file you upload. SVG images are a little newer and the bulk of the vulnerabilities in SVG images where found in 2011.

SVG Masking is used to obscure iframes in a clickjacking attack. But I don't think this attack vector applies to your svg upload system.

rook
  • 46,916
  • 10
  • 92
  • 181
  • I want to inspect the uploaded SVG for certain meta data. I'm concerned, this could exploit my website. – polemon Feb 04 '12 at 18:00
  • 2
    @polemon yes of course it can. Any feature even printing a message to the user is dangerous. File upload is one of the more dangerous features. That being said this can be done in a secure way. You haven't said anything about the language or platform, so no one can help you. Maybe you should ask stackoverflow.com with a security tag. – rook Feb 04 '12 at 19:28