Identify and Fix XSS Vulnerabilities in Your Web App –

What Is Cross-Site Scripting?

Cross-Site Scripting (XSS) is a code-injection vulnerability that occurs in applications that process HTML when developers do not sanitize user input well enough before inserting it into an HTML template. It allows an attacker to insert arbitrary JavaScript code into a template and execute it in the user’s context:

In the image above, the developer failed to sanitize the content of the “last-name” div, which resulted in users being able to include malicious scripts by manipulating their last name.

Is XSS Common?

Despite the fact that numerous frameworks and libraries provide users with all the necessary tools to get rid of XSS, this is still one of the most common vulnerabilities found in web applications. It consistently appears in the OWASP list of the Top Web Application Security Risks and was used in 40% of online cyberattacks against large enterprises in Europe and North America in 2019. According to HackerOne, XSS vulnerabilities are the most common vulnerability type discovered in bug bounty programs.

Where Can I Spot XSS Vulnerability?

There are two types of Cross-Site Scripting:

Is XSS Really That Dangerous?

Simply put, it’s a disaster. Here’s a list of what an attacker can do if they’re able to exploit an XSS vulnerability on the client side:

• Remote Code Execution (Browser exploits, CMS exploitation)
• Session Hijacking
• Bypass CSRF protection
• Keylogging
• Forced Downloads
• Man-in-the-Middle Attacks
• All sorts of phishing: Credential Harvesting, Ad-jacking (Ad injection), Clickjacking, Redirecting users to a malicious website, etc.
• Stealing data from local- session- web- storages, cookies, IndexedDB, page source code, taking screenshots
• DoS and DDoS
• Content Spoofing
• Pivoting into hidden, internal networks, protected by firewalls: JS can be used for host & port discovery, service identification, and interaction (Is extremely slow)
• Stealing geo-location, capturing audio, web camera, or gyroscope data (requires explicit permission)
• Crypto mining (Is hard, the browser will try to protect a user)

Server-Side XSS is even worse because it allows:

• Remote Code Execution
• Local File Inclusion
• Server-Side Request Forgery
• Internal Path Disclosure
• Stealing information from the result document
• DoS
• Crypto mining

The attacker is also able to get information and control the tab in real-time mode:

Misconceptions About XSS

“XSS Is Not a Threat if the Website Uses HTTP-Only Cookies for Authentication”

I hear that a lot and that’s just ridiculous. Yes, an attacker can’t steal HTTP-only cookies with JavaScript; however, they don’t even need to. The true danger of XSS comes from the ability to execute arbitrary JS in the current user’s context. If an attacker can’t steal the cookie and attach it to malicious requests made from their machine, they’ll just move the malware into the victim’s browser, and the browser will attach the cookies for them. I admit the exploitation becomes more complicated; however, it’s A LOT stealthier and safer for the attacker.

“XSS Is a Non-Persistent Type of Attack #1: I Leave the Vulnerable Page, and It’s Fine”

Wrong again! Once an attacker can inject arbitrary JS into your browser, they can change the application’s behavior so that you NEVER leave the vulnerable page. By manipulating requests/responses and the HTML DOM, they can make it seem like you left the page by re-rendering new content on the vulnerable page. However, this kind of trickery can be defeated if the user manually types the URL they’re interested in into the address bar.

“Xss Is a Non-Persistent Type of Attack #2: I Just Leave the Website, and It’s Fine”

That is not true: malicious JavaScript files CAN be persisted in your browser. That’s rare but still possible via Server Workers. To register a malicious service worker, one of the following conditions must be met:

1. An attacker has to write access on the frontend server
2. There’s an unfiltered JSONP endpoint exposed

If an attacker manages to register a malicious Service Worker, they can maintain persistence in your browser indefinitely. Service Workers can be used to sniff and modify traffic (for instance, to supply new malicious scripts with each response). Check out the ShadowWorkers project for more details.

How Many Types of XSS Are There?

There are several different ways of XSS manifestation. Security specialists usually single out 3.

Dom-Based XSS. DOM XSS stands for Document Object Model-based Cross-site Scripting. A DOM-based XSS attack is possible if the web application writes data to the Document Object Model without proper sanitizing. The attacker can manipulate this data to include malware on the web page. Key points:

• Generally, DOM-Based cross-site scripting attacks are client-side attacks. Malicious code might never reach the server.
• Malware is executed AFTER the HTML template is rendered; it happens at some point during runtime.

Reflected XSS. Reflected XSS occurs when the server takes a part of a request and inserts it into the response without proper sanitizing. Key points:

• Reflected XSS payload ALWAYS reaches the server; it is part of both request and response.
• Unlike DOM-Based XSS, Reflected XSS payload is executed WHILE a browser renders an HTML template since the payload is part of the response and usually is embedded into the template.

Stored XSS. Stored XSS happens when developers blindly trust data that’s being stored in their databases, web-caches, files, etc. Key points:

• Stored XSS is saved somewhere (not necessarily the database) for a while
• The payload might be executed on multiple pages and usually does not require any user interaction to fire (unlike DOM-Based and Reflected XSS, which are usually spread via malicious links and require user interaction).

If I Use React, Am I Safe Then?

Surprise reveal: React is not fully safe from XSS, although it really tries to protect users from it. There are several ways to inject malicious JS into a React app:

• React does not filter what you’re passing to props:
  • href (Exploitation via “javascript:” or “data:text/html” URI)
  • src (Exploitation via “javascript:” or “data:text/html” URI)
  • srcDoc (Exploitation via inserting malicios HTML)
  • formAction (Exploitation via “eval(…arbitrary js)”)
  • data (Exploitation via “javascript:” or “data:text/html” URI)
• React also allows you to directly manipulate the DOM, bypassing its restrictions and protections. You can achieve this by using the dangerouslySetInnerHTML prop. As a “Security precaution”, React ignores ’. Additionally, IPS systems ship with known exploit traffic signatures; for example, Snort is able to detect and disrupt exploitation of CVE-2011-1897 — XSS vulnerability in Microsoft Forefront Unified Access Gateway.

  Beware of Inserting User Input Into the “Script” Tag

  If an attacker is able to insert JS where it’s being evaluated, there's not much you can do. There are numerous ways to encode and mutate malicious scripts by using dedicated obfuscators or esoteric JS dialects, like Katakana, JJEncode, or JSFuck. Consider the following JJEncode snippet:

  ```js $=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_$$:({}+"") [$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$__:++$,$_$:++$,$$__:({}+"")[$],$ $_:++$,$$$:++$,$___:++$,$__$:++$};$.$_=($.$_=$+"")[$.$_$]+($._$=$. $_[$.__$])+($.$$=($.$+"")[$.__$])+((!$)+"")[$._$$]+($.__=$.$_[$.$$_])+($. $=(!""+"")[$.__$])+($._=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+ (!""+"")[$._$$]+$.__+$._+$.$+$.$$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$$+"""+$. $_$_+(![]+"")[$._$_]+$.$$$_+"\"+$.__$+$.$$_+$._$_+$.__+"("+$.__$+")"+""") ())(); ```

  When inserted in a