SVG elements

SVG stands for Scalable Vector Graphics.

SVG defines vector-based graphics in XML format.  See HTML5 SVG

<text> element
I love SVG!

<svg height=”30″ width=”200″>
<text x=”0″ y=”15″ fill=”red”>I love SVG!</text>

<svg width=”100″ height=”100″>
<circle cx=”50″ cy=”50″ r=”40″ stroke=”green” stroke-width=”4″ fill=”yellow” />

*TekP says be aware of attack vulnerabilities in SVG markup though before uploading directly to your web server.

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.

Thanks! You've already liked this