[Whole Web] CROSS SITE SCRIPTING (XSS)

Cross-Site Scripting (XSS) is a vulnerability that allows the attacker to inject their own JavaScript code into a vulnerable website. This gives the attacker full control of any browser tab that loads the exploit.

 

Reflected XSS

The vulnerability in the last example belongs to a subcategory of XSS called reflected XSS (as opposed to stored XSS, covered in a later lesson).

Reflected XSS is as easy as 1-2-3

In reflected XSS the vulnerable application:

1. Takes a piece of data from the request …

2. Inserts it into the HTML document (on the server side) or the DOM (on the client side) …

3. In dangerous a way, allowing JavaScript code embedded in that data to be executed.

 

The vulnerable line of code

The vulnerability is on the login page, so we’ll start our investigation with the login form.

The form uses the GET method to submit its data, which means the form’s input values become query parameters of the URL. This is not a vulnerability in itself, but make a mental note of it – we’ll later see why this is useful to the attacker.

<form method="GET">
  <!-- ... form details omitted ... -->
</form>

　　

Escaping saves the day

Escaping is the process of taking text that could be mistaken for HTML, and turning it into actual HTML that happens to have the same meaning as the original text. (I know, I’m confused too, and I wrote that!)

An example should make this clear. Escaping our formula a<b>c turns it into a<b>c, which is HTML for “the letter ‘a’, a less-than symbol, the letter ‘b’, a greater-than symbol, and the letter ‘c’.”

When we insert the escaped version into our HTML, no browser will see a <b> tag there, no matter how hard it squints.

<p>a&lt;b&gt;c</p>

 

Filter bypass

Check out the list of filter bypass tricks at swisskyrepo/PayloadsAllTheThings

For example:

instead of do

alert(1)

do:

alert`1`

 

Dos and Don’ts

The following rules will help you avoid both reflected and stored XSS in the code you write. Breaking these rules does not make the code automatically vulnerable to XSS, but the more rules a piece of code breaks, the greater the chance of it being vulnerable.

Do

• Be alert when dealing with untrusted data
  Whenever you include untrusted data on a web page, make sure that you use safe methods to do so and/or sanitize the data appropriately.

• Be mindful of context
  The correct way to sanitize untrusted input always depends on the context. The string javascript:alert(1) is safe as a part of an HTML element’s text, but dangerous when treated as a URL.

  The OWASP XSS Prevention Cheat Sheet is not very light reading, but it thoroughly covers the sanitization methods that should be used in different contexts.

• Know your tools and their limitations
  Whether you’re working with HTML on the server side or the DOM on the client-side, every rendering library and framework has features that are dangerous when used with untrusted data. You need to know what they are so you don’t misuse them.

• Validate on edge, convert to restrictive types
  Validate all incoming data as soon as it is received, and convert it to the most restrictive data type that can accommodate the valid data. There’s plenty of ways to inject an XSS payload into a string, but good luck doing the same with a boolean.

Don’t

• Do not rely on denylists
  There is an infinite amount of possible XSS exploits, and it’s impossible to catch all of them by comparing them to a list of “known bad” patterns.

  swisskyrepo/PayloadsAllTheThings provides a nice overview of the variety of ways in which denylists can be bypassed.

• Do not think of any data as “safe”
  As discussed above, safety is contextual, and there is no such thing as data that is universally safe. Data that has been validated or sanitized for a particular context may be dangerous in another.