One of the early internet hygiene tips I was told when I created my first email account was to avoid “clicking on random links” in emails that I was not expecting. For a long time, I thought this warning was made to avoid visiting sketchy websites, maybe the kind that would immediately initiate a download without my consent. However, a good part of the logic behind this advice stems from XSS concerns.

Reflective XSS is the use of malicious URLs to make a victim’s browser commit some action they never intended. Most examples you see online, including this one, make the victim’s browser generate an alert message, meaning just a text box with any chosen text inside of it. However, XSS can be used for much more malicious purposes, including executing commands on behalf of the victim on the chosen website, sending user data such as cookies to an attacker-controlled server, or inserting content into a trusted website, like a fake login page, to trick the user into giving up their credentials. XSS could allow a malicious script to execute any action that a user is capable of performing on a given web app.

Executing XSS

XSS is done by manipulating the parameters of a URL. These parameters must be utilized within the HTML of the webpage without any sanitization or escaping. A classic example is a search bar. Let’s say a website called example.com contains its own search function. Searching “corn” may result in a URL like https://example[.]com/directory?search=corn. When no results are found for corn at example.com/directory, the site HTML displays the text “no results found for corn.”

Because the client has control over the value of the parameter “search,” an attacker can insert whatever text they want. This text will then be loaded into the HTML as a string. What if the attack decides to insert an HTML tag into the page, like <script>? Then the attacker could insert code into the HTML capable of carrying out commands. A classic test for XSS is to insert the “alert” command as so:

This would execute a search for ```<script>alert("XSS")</script>``` which, when not found, would find itself in the HTML of the page itself, causing the user's browser to generate a pop-up alert saying "XSS". An attacker could take this URL and send it to a victim, and the script would execute on the victim's browser once they visited the malicious link.

## Mitigations

Most web frameworks automatically prevent developers from leaving XSS in their HTML templates. Django, for example, escapes and variables inserted into the HTML of a web page. However, developers could choose to turn off these protections in Django using the "safe" tag. Below is an example of the safe tag applied to the variable "search_term." This code could be vulnerable to an XSS attack:

No results for !

```

Limitations

It’s important to note that while XSS can be used to deface sites, steal session information, or execute actions on behalf of a user, there are specific limitations to the attack. It is a client-side attack, meaning it cannot be used to directly access server-side resources or bypass server-side security controls. XSS will not be your ticket directly into a server, but may allow you to execute actions on behalf of a more privileged user…