Cross-Site Scripting (XSS) is avulnerabilitythat 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 theexploit.

Reflected XSS

The vulnerability in the last example belongs to a subcategory of XSS calledreflected XSS(as opposed tostored XSS

Reflected XSS is as easy as 1-2-3

In reflected XSS the vulnerable application:

1. Takes a piece ofdata from the request…

2. Inserts itinto 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 theGETmethodto 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 thatcould be mistaken for HTML, and turning it intoactual HTMLthat 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 formulaa<b>cturns it intoa<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 atswisskyrepo/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 stringjavascript:alert(1)is safe as a part of an HTML element’s text, but dangerous when treated as a URL.

  TheOWASP XSS Prevention Cheat Sheetis 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 ondenylists
  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/PayloadsAllTheThingsprovides 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 iscontextual, 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.