Guidance on save vs dangerous SVG tags/attributes

[Jonas Wagner]

Hello,

I arrived at this group when looking at Chrome's SVG code. My goal is to build a sanitizer for SVG files that strips away all content which could potentially execute scripts and allow XSS attacks. Do you have any information about which tags/attributes in SVG can potentially carry active content?

I currently know about typical ways to include scripts in SVG files, such as <script> tags, event handlers like onload, and xlink links with a "javascript:" URL. I can also tell from the SVG specification that basic shapes like <path> are safe. However, there are many ambiguous cases, and I'd like to have an authoritative way to decide which subset of SVG is safe.

Do you have any information about this, or a way to determine which elements are active? Any help or pointers would be appreciated.

Best regards,

Jonas

[Philip Rogers]

Is it an option to use an existing HTML sanitizing library? I presume these already handle SVG since SVG can be embedded inline in html. In addition, because of the <foreignObject> element, an SVG sanitizer would have to contain an HTML sanitizer.

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAFLutvQGDNZ9toiUBm%3DnVF_3Ug5GB4V5PWaZVH0q3U0xLXc75Q%40mail.gmail.com.

[Jonas Wagner]

We do use HTML sanitizers. However, those sanitizers remove embedded SVGs altogether, deleting the <svg> tag and the entire DOM tree.

Conversely, the SVG sanitizer that I'd love to have would probably strip <foreignObject> from the SVG file. It's probably safer to remove it, rather than try to prove such content safe.

There is some prior work, e.g., [1] and [2]. These files contain lists of probably safe tags, without justification or guarantee that the result is indeed safe. Do you know more about the safety of various SVG constructs, or whether this could be inferred from Chromium's code base?

[1]: https://github.com/html5lib/html5lib-python/blob/master/html5lib/filters/sanitizer.py

[2]: https://github.com/cure53/DOMPurify/blob/master/src/tags.js#L126

[Philip Rogers]

This seems like a tough task because SVG is quite large. When SVG is loaded as the top document, we use the XML parser which is more general than the html parser and seems even more difficult to guard against (e.g., ENTITY references).

I wonder if you could take advantage of the browser's built-in sandboxing of svg images. When svg is loaded as a document, script can run and subresources can load. When svg is loaded as an image, these are prevented. This is specified in https://svgwg.org/svg2-draft/single-page.html#conform-referencing-modes.

For example, this is an unsafe svg file:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100" height="100">
  <rect x="10%" y="10%" width="80%" height="80%" fill="green" />
  <script>alert('danger!');</script>
</svg>

We can base64 encode this as an image, then put that image back into svg and it will be sandboxed:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100" height="100">
  <image width="100%" height="100%" xlink:href="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjEwMCI+CiAgPHJlY3QgeD0iMTAlIiB5PSIxMCUiIHdpZHRoPSI4MCUiIGhlaWdodD0iODAlIiBmaWxsPSJncmVlbiIgLz4KICA8c2NyaXB0PmFsZXJ0KCdkYW5nZXIhJyk7PC9zY3JpcHQ+Cjwvc3ZnPg=="></image>
</svg>

[Philip Rogers]

Unfortunately there is no easy way. For example, the SVG image code can disable script by just changing a setting[1] but you'll have to determine all places script can be run from, and remove them.

If supporting links is an important usecase, the only option I see is a whitelist-based approach like HTML sanitizers use. I'd reiterate that this is a very difficult problem due to the complexities of XML (e.g., ENTITY references).

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/graphics/svg_image.cc?rcl=3915bb6d5937163f3f27decd4a9f1ff3b10e07bc&l=765

On Fri, Jun 21, 2019 at 11:22 AM Jonas Wagner <j...@google.com> wrote:

Thanks for the response!

I wonder if you could take advantage of the browser's built-in sandboxing of svg images. When svg is loaded as a document, script can run and subresources can load. When svg is loaded as an image, these are prevented. This is specified in https://svgwg.org/svg2-draft/single-page.html#conform-referencing-modes.

We've considered this. Indeed, we can load SVG files using <img> tags in some cases. Your example also works. However, I believe these approaches make the image completely static, so that users can no longer click on links in the SVG.

I reckon there is no easy way to see how the browser decide which feature corresponds to which SVG conformance mode?

Cheers,

Jonas

[Jonas Wagner]

Thanks for the response!

I wonder if you could take advantage of the browser's built-in sandboxing of svg images. When svg is loaded as a document, script can run and subresources can load. When svg is loaded as an image, these are prevented. This is specified in https://svgwg.org/svg2-draft/single-page.html#conform-referencing-modes.

We've considered this. Indeed, we can load SVG files using <img> tags in some cases. Your example also works. However, I believe these approaches make the image completely static, so that users can no longer click on links in the SVG.

I reckon there is no easy way to see how the browser decide which feature corresponds to which SVG conformance mode?

Cheers,

Jonas

[Jonas Wagner]

Thanks a lot for all the advice!