Headshot of Marcus Harding

Marcus Harding

Cross Site Scripting (XSS) attacks

Overview

XSS attacks are a type of injection, where malicious scripts are injected into otherwise safe and trustworthy sites. They occur when an attacker uses a web application to send malicious code in the form of a browser-side script.


Flaws allowing attackers to successfully inject malicious scripts are common as they can occur anywhere in a web application that uses input from a user within an output, without validating or encoding this input first.

Key points to note

  • The end user’s browser has no way to know that the script should not be trusted.
  • Malicious scripts can access any cookies, session tokens, or other sensitive information retained by the browser.
  • These scripts can even rewrite the content of the HTML page.

A few types of XSS Attacks

Stored (Persistent) XSS

Occur when attackers store their payload on a compromised server, causing the website to deliver malicious code to other visitors. This is the most dangerous and commonly employed type of attack.

Reflected XSS

This is when the malicious payload is stored in the data sent from the browser to the server.

Self XSS

This occurs when attackers exploit a vulnerability that requires extremely specific context and manual changes. The only one who can be a victim is yourself.

Notable attacks

Samy

Samy was an XSS worm designed to propagate across the social networking site MySpace. Within just 20 hours of its October 4, 2005 release, over one million users had run the payload making it the fastest-spreading virus of all time.

Apache hosted JIRA, Bugzilla, or Confluence

On April 5th, the attackers via a compromised Slicehost server opened a new issue, INFRA-2591. This issue contained the following text: "I've got this error while browsing some projects in Jira http://tinyurl.com/XXXXXXXXX".

The URL redirected back to the Apache instance of JIRA, at a special URL containing an XSS attack. The attack was crafted to steal the session cookie from the user logged into JIRA.

When this issue was opened against the Infrastructure team, several administrators clicked on the link. This compromised their sessions, including their JIRA administrator rights.

My own experience

Whilst working on a project using Vue and WordPress via rest API I would access post content via a rendered property that returns all the raw post content. For this reason, it works best to use the V-HTML attribute to render the markup and tags from the raw output.

A V-HTML directive is used to change the inner HTML of a DOM element. It may seem safe and cool, but that could be one of the first things attackers are looking for when trying to attack your website.

How can we protect against attacks?

In the case of the example above using V-HTML a few things we could have done:

  • Rid the V-HTML tag altogether.
  • Use v-text instead, this way Vue engine would sanitize content provided for us. However, we would lose any potential styling the authors intended to retain from the original source.
  • Sanitize the incoming content manually (the option I opted for).
  • Utilise allowlist Values.
  • Use HTTPOnly Flags on Cookies.

And lastly:

  • Use a web application firewall (WAF) to protect against attacks.

A WAF typically protects web applications from attacks such as cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection, among others.

Summary

Long story short the risk of creating possible routes for XSS attacks is high when using externally inputted user content on websites and applications. But the risk can be mitigated pretty easily. We should always be utilising a solution to ensure raw content coming from external sources is safe.

As seen with the Samy and Jira attacks, a small and easily patchable vulnerability can lead to a large-scale, damaging attack with knock-on consequences for all users of your site and service.

References