November 27, 2020

A7-Cross-Site Scripting (XSS)

Objective

Compromise other visitors or the administrators of the web application to steal cookies, hijack sessions, take over accounts, bypass 2FA.

Tactic 1: Reflected XSS

Add malicious link to the attacker controller server into a text box on a vulnerable web application. To be effective the results of the text box must be visible to other users, such as blog comments. The malicious link is available on page load from the compromised server.

Another method would be to get a malicious advertisement onto the target web application.

To make the attack more effective, obfuscate the link with a url shortening service (e.g. bit.ly)

Defense for Reflected XSS

Escaping user request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL).

Tactic 2: Stored XSS

Add malicious code into a text box on a vulnerable web application. To be effective the results of the text box must be visible to other users, such as blog comments.

Defense for Stored XSS

Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL).

Tactic 3: DOM XSS

Send a Invisible to the server, the malicious code is executed at some point after the page has loaded because it references a client-side DOM variable that contains malicious code, as a result of the page’s legitimate JavaScript treating user input in an unexpected way.

Defense for Reflected XSS

HTML Escape then JavaScript Escape Before Inserting Untrusted Data into HTML Subcontext within the Execution Context

General XSS Defenses

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

  • Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
  • Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
  • Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
  • Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
  • HTTPOnly flag in the cookie. If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker’s website.