Skip to main content

Hacktivity Highlights: XSS via SVG

  • July 14th , 2016

Welcome to episode #1 of our Hacktivity Highlights blog series! What the hack is a Hacktivity Highlight? It is recurring blog where we take an interesting publicly disclosed vulnerability report and add our own analysis and thinking to it.

Let’s get to it! Earlier this month a vulnerability was disclosed using an SVG containing JavaScript that was then used to turn it into a Stored Cross-Site Scripting (XSS) vulnerability. Stored XSS, also known as Persistent XSS, is achieved when the server actually stores (persists) the malicious JavaScript payload. This means that the server will serve up the malicious payload upon request and it will get executed in the user session. Persistent XSS is often considered far more serious than a reflected XSS, since XSS auditors built into most modern web browsers will not be able to catch the malicious payload.

The Finder describes that most dangerous file types, such as HTML files are securely served using the text/plain MIME type. However, the reporter also identified that SVG images were served as-is, allowing possible XSS attacks. While the initial report could have been more clear about why it was a vulnerability in the first place and how it could be remedied, the program owner Scott Arciszewski (@paragonie-scott) did respond quickly and produced a fix within minutes. Scott (jokingly?) made a suggestion to change the MIME type for SVGs to begin with application/ instead of image/. We thought that was an interesting observation and turned to Twitter for a poll. It looks like the community disagrees, but thought it was worth to poll at the least:

Alt text@Michielprins Twitter Poll

Now, what can we learn from this finding?

  1. Never blindly trust user input.This is especially important when working with tricky input such as images; ImageTragick is still too fresh in our memories to trust anything.
  2. Serve user attachments from a sandboxed domain. At HackerOne, we serve all user generated files from hackerone-user-content.com. We do this so we can benefit from the Same Origin Policy (SOP) built into web browsers. This simply means that if someone were to execute JavaScript on hackerone-user-content.com, those scripts can not access session information on hackerone.com.
  3. Define a Content Security Policy (CSP). It allows you to define what can and what can’t run in your site on the client side. For instance, you can disable inline JavaScript and only allow JavaScript from whitelisted remotes (e.g. your CDN).
  4. The internet has lots of quirky old stuff that not necessarily every software developer knows about.

If you have an opinion, we encourage you to join the fray on Twitter!

Want to explore other publicly disclosed vulnerability reports? Check out Hacktivity!

Michiel Prins

Recent articles

Announcing The Largest DoD bug bounty challenge ever: Hack The Air Force

The Air Force is asking hackers to take their best shot following the success of Hack the Pentagon and Hack the…

Zero Daily Newsletter: Fun, yet informative, AppSec, bug bounty, and hacker news

Read the news every day, and check the usual websites? Want to get your industry news and have a little humor…

More Hardware, More Problems

Bounties are for hardware, too. Microwaves notwithstanding, there is an increasing amount of connected…