XSS when loading untrusted SVG using img tag

Question

Does the threat of XSS exists when loading an untrusted SVG file using the img tag?

As in: <img src="untrusted.svg"/>

I've read that most browsers disable scripts in svg files loaded via the img tag.

Thurmond

All browsers disable scripts for img tags AFAIK, let me know if you find one that doesn't. – Respite

Answer 1

This used to work in some browsers, but not anymore. However there is a related issue. If I as a unknowing user, right click and download the image, and then open it locally, it will likely open in the browser and the script will run. Which is a bit weird considering it's an image. I suppose if you right click and select "view image" that could also cause the script to run, because you open it diretly.

Emersonemery

You're right about the script being able to run if you open the file locally, but it can't really do much in that environment. JavaScript's same origin policy prevents it from accessing any cookies or other sensitive information once it's loaded locally. – Irvinirvine

More importantly than running it locally is doing Right Click -> "View image" or "Open image in new tab". That will execute the scripts in the context of the origin on which it is hosted. If you had your user upload that file to your site, it's safe while in the img tag, but if someone either clicks a direct link to the image or uses the "view image" functionality (which many people use to view it at original size), it will execute the XSS on your domain. The CSP option mentioned here might be a solution: security.stackexchange.com/questions/212894/… – Crackerbarrel

Answer 2

Yes, XSS threats do exists when using SVG, most browsers will not allow the script to run, but if it is sent via email then it could potentially run.

Some links to issues:

Scalable Vector Graphics and XSS

Why does this XSS vector work in svg but not in HTML?

SVG Fun Time - Firefox SVG Vector + Bypassing Chrome XSS Auditor

PDF About Dangerous SVG

Grafting

Answer 3

No, there is no risk of XSS in an <img> tag.

But if the image can be loaded in an <img> tag, then the person can also load the image directly. In that case, scripts are executed.

For example, <img src='/uploads/4bafa902.svg'> will not execute scripts, but if someone clicks a link leading to https://example.com/uploads/4bafa902.svg then any scripts inside the SVG will execute in the context of https://example.com/ (called an origin). Even with an HttpOnly session ID cookie, the script can perform any calls into your application (at that origin) and either perform unwanted actions or exfiltrate obtained data to the attacker.

If you host SVGs on an origin where an application runs that uses any sort of cookies, or where a request can perform actions without user interaction (like CSRF, except it's originating from your own origin), or an origin which anyone put into their CORS allow header (leading to the same CSRF-like risk), then you need to either:

• Have a Content-Security-Policy (CSP) response header set on SVG images which denies running those scripts. This is the one I use:

  Content-Security-Policy: script-src 'none'; object-src 'none'; report-uri /cspreport
  

• Remove/sanitize the executable contents from an untrusted SVG, either before hosting it or before serving the contents to users.

Both options have caveats:

The CSP header is often configured globally on the web server. If you set a custom one for SVG content responses, that might be overridden by the web server (either replaced, or two might be set in a random order and lead to unexpected results).

The cleaning/sanitizing is prone to oversights, and you also need to keep up with new (and perhaps obscure) browser features, similar to how ontouchstart was defined for touchscreen devices only in 2013, nearly twenty years after onclick was defined (maybe VR/AR headsets will get their own events for looking at an element, or something else we do not have yet today). Thus, I would not try to build my own, but rather trust to a project that focuses on cleaning SVGs against XSS such as DOMPurifier.

Having both defences probably gets you the best of both worlds: if the filter is circumvented, the CSP should still kick in, and vice versa.

Crackerbarrel