Skip to content

Self-XSS

Scene: The Internet

Picture yourself, looking for memes, navigating through websites, clicking links; a typical day online. However, an unconventional and lesser-known security threat is hiding in plain sight. The dreaded (🙂‍↔️) Self-XSS (Self-Cross-Site Scripting). Let's get into some of the intricacies of this relatively rare attack vector.

What is Self-XSS?

Self-XSS (also called the 4th type of XSS) occurs when an attacker tricks someone into executing malicious JavaScript in their own browser's developer console. Unlike traditional XSS, Self-XSS exploits user behavior rather than application vulnerabilities.

Attack Chain

  1. Setup: The attacker creates a convincing message—often phrased as a harmless hack or a feature enhancement.
  2. Execution: The user copies and pastes the provided JavaScript code into their browser's console.
  3. Payload Delivery: The script executes with the privileges of the user, potentially exposing sensitive data like session cookies, local storage, or executing further network requests.

Why is it Rare?

Generally, people are "aware" of being hacked and the bajillion scams nowadays, which in turn makes them less likely to fall for simple, and sometimes obviously complex tricks. Since almost all browser's developer tools now include warnings about executing untrusted code, this further reduces the chances of success for would-be attackers. Since Self-XSS only affects the individual running the code, it lacks the broad impact attackers typically aim for, making it less appealing. On top of that, increased education in classrooms, workplaces, and in social media has made people more cautious overall.

What Does Detection Look Like?

Detecting Self-XSS is somewhat difficult due to its reliance on the user's actions rather than system vulnerabilities.

no..., don't..., stop

You could put every 🛑 and 🚨 on something and someone is still going to ignore it.

That being said, modern browsers include a myriad of warnings in their developer tools to discourage people from running random code. In a corporate environment, behavioral monitoring can enhance this by logging unusual console activity, such as attempts to access the dev console (why is this person at the front desk suddenly abusing their F12 key?!?). And as always, proactive and consistent [you gotta repeat the message] end-user education/trainings are crucial for raising awareness about general secure usage practices.

Prevention

Preventing Self-XSS entirely can be tough, but there are a few key steps that can significantly reduce the risk:

  1. End-user education is critical; regularly reminding users about the dangers of running untrusted code and sharing examples of common scams can go a long way.
  2. Implementing strong Content Security Policies (CSP) helps block inline scripts (Content-Security-Policy: script-src 'self';) and restrict script sources, adding a solid layer of defense.
  3. Recommending browser extensions like NoScript can give some extra protection against potentially harmful scripts.

In the end, honestly, self-xss isn't that much of a concern. It's more effort than it's worth for the generic attacker as they are much easier ways to trick someone (phishing, other XSS, malware, etc).