Abusing services using SVG files: Part 1. Anatomy of an svg
This is a 4 part series based on a vulnerability I wrote a detailed, step-by-step exploitation instructions in an internal comms channel. I wanted to show how easy a reflected XSS attack is to turn in to an exploit that can overtake the whole session of the targeted use. Of course the exploit could achieve a lot of different goals as well, such as stealing payment or otherwise sensitive data.
I asked ChatGPT to describe SVG to me like I’m 5 years old. Here’s what I got:
SVG is like a special kind of picture that can do lots of cool things. You know how when you draw a picture on paper, you use lines and shapes? Well, SVG is like that, but on the computer. Instead of using lots of tiny dots, it uses special math to describe the lines and shapes. The cool thing about SVG is that you can make the picture bigger or smaller, and it will still look really clear. It’s like having a magic picture that can change size without getting blurry!
Well, magical pictures as they are, besides vectors used in graphics they can include pretty much anything else too. For example javascript.
Yes, javascript.
Javascript can be included in the file and by default it will be executed in the browser. A simple example:
Save that to a file and open it in your browser. Or if you trust me, click this link.
You can see that the SVG file contains a rectangle with width of 300px and height of 100px. It’s style attribute sets some styles such as blue fill to it, but most importantly, it contains a regular script tag that is executed when the image is loaded.
Now, include the svg file in a web page:
Open the page in a browser, what do you see? No alert popup? Yes, the browser (most likely, if you’re not using an ancient version) protects you from executing scripts from content loaded via other “domains”. In this case the external SVG file is considered to be in violation of the default CSP.
CSP is shorthand for Content Security Policy, see the https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for details
Problem solved, right?
Well, no. If a page uses an <embed>-tag to include the file the problem manifests itself again. There are quite a few other possible ways for the script to execute.
Let’s take the second example and see what we can do with the script.
We’ll change the html file to:
Let’s also change the svg file to:
Open it again in a browser and we’ll have access to the cookie. You can also see a live example at https://nodejs-production-66de.up.railway.app/part1/test.html
Of course you wouldn’t be able to access cookies via script if they’re correctly set as httponly. How could an attacker utilise this kind of an attack in the real world? We’ll see in the next part.
Originally published at https://www.linkedin.com.
