2 Answers
2

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:

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.

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.

@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.
–
rookFeb 4 '12 at 19:28