9

Currently assessing an application, I found out that it is possible to submit an SVG file containing JavaScript (the app is also vulnerable to XXE). I wondered if there was a method to prevent those vulnerabilities and secure the SVG submission form? How to be sure that all obfuscation methods are caught?

In first place, I developed a blacklist approach but from a security point of view, it is a very very bad approach. What do you advice me?

  • what about converting the SVG to a JPG/GIF/etc ? – Purefan Jan 16 '17 at 11:07
  • Unfortunately SVG is needed because the application is based on the features of svgs (xml structure). It displays and hides dynamically layers of the SVG according to the needs. However, SVGs are very rarely added and are restricted to only a few people but I can't leave this door opened. I discovered that there are tons of obfuscation methods which make the prevention complicated – Nokosi Pow Jan 16 '17 at 12:22
  • as far as I've seen the exploit requires a <script... tag, dont know if its enough to just remove this block but have you looked into that? – Purefan Jan 16 '17 at 12:23
  • As I said, i have already tried a blacklist approach containing the script tag and all the JS event handlers but there are other means possible. It is possible to place in a legitimate tag an base64 encoded payload. It will pass filters without any problem and will execute the payload. – Nokosi Pow Jan 16 '17 at 12:25
  • If you know what elements you consider acceptable, a whitelist approach might work. There are a limited number of common tags, and each of those has a limited number of required attributes, so while there might the odd edge case, in combination with the limited access to the upload function, it might be acceptable. Alternatively, there are various sanitizer projects around, which might be a good starting point. – Matthew Jan 16 '17 at 13:06
4

Take a look at this fantastic blog post that was recently published by security researcher Robin (@digininja) about this exact topic:

  • Direct view with content-disposition: attachment - not vulnerable - Headers are sent to force the file to be downloaded.

  • Direct view with CSP - not vulnerable - The Content Security Policy is set to disallow inline JavaScript.

  • Image Tags - not vulnerable - The SVG is referenced through image tags which prevent scripts.

  • Tags With CSP - not vulnerable - Image tags and the same CSP as above for double protection.

0

While @ThorTL67 points out some completely vaild solutions, I don't feel comfortable with any of them, and they seem kinda irresponsible to me.

This is because any malicious JS within the SVG is still sent to the viewer. This means that if they happen to save the SVG file and then view it, any malicious JavaScript will still be executed on their device, since on most devices the only software that can view SVGs are browsers.

This is especially true for the first point in @ThosTL67's answer.

Here are some alternate recommendations:

  1. You can convert the SVG to another format server-side (such as PNG) and then display the new image.

  2. You can sanitize SVGs using libraries such as this one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.