The premise of a Reflected Cross-Site Scripting attack is that certain websites accept user input that they “reflect” back to the user somewhere in their interface/portal. For example, imagine a website that asks for your first name, your job title, or your phone number. Think that input is shown somewhere in the interface, perhaps in an accounts page or somewhere else? It most likely is. And that’s not necessarily a problem. But, the problem is a half-step away, if the website’s developer was even slightly careless.
Reflected Cross-Site Scripting: Attacker Step 1
Attackers seeking to take advantage of this strategy begin by taking inventory of vulnerable URLs on the target website. Specifically, they look for URLs that accept a “parameter”. Ever see a URL that has a “?” in it, followed by some semi-readable text? Most of us have seen that at some point. And hackers love to see it, because it leads them to believe that there is a possibility of a reflected cross-site scripting vulnerability.
Reflected Cross-Site Scripting: Attacker Step 2
- Session Token Stealing Code: code that attempts to discern the secret that the web browser and the target website use, when they decide whether to “trust” that the user is a valid, signed-in user.
- Action-Taking Code: code that causes the target website to take some particular action on behalf of the user (for illustration: granting some access privileges to another user)
The first two examples above are ones that rely exclusively on orchestrating a reflected cross-site scripting attack; the third example is one that attempts to expand the attack beyond just the reflective strategy, to a broader XSS attack.
Reflected Cross-Site Scripting: Attacker Step 3
See below for a full illustration of the steps in this Threat Primer example. Many variants exist, but we hope that you find this primer to be informative. With a higher awareness of this type of attack strategy, we believe you will be better prepared to recognize — and avoid — variants of this attack strategy.