August 17, 2020
Cyber Security | Threat Primer
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.
When hackers identify pages that take "parameters" and reflect those parameters back to the user, they begin to experiment with what else they might be able to "pass in" on those parameters. For example, if they find a URL that accepts a plaintext "message" as a parameter, they might try to "inject" a trivially simple line of Javascript code into that parameter. A typical test would be injecting an alert, like the one shown above.
If the attacker attempts that type of test and is able to find any portion of the target website that reflects that Javascript back to the user, the hacker senses that they are close to being able to exploit the vulnerability.
Reflected Cross-Site Scripting: Attacker Step 2
In the prior step, we talked about injecting a trivially simple Javascript fragment into a URL. However, we all know that this is just the naive proof-of-concept. Hackers intend to inject something much more devious. Examples of code fragments that hackers might choose to inject, include:
- 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)
- Traditional XSS Code: code that attempts to load a Javascript file containing any arbitrary code the attacker wishes, from a URL controlled by the hacker
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
Hackers know that in order to take advantage of users with this attack strategy, they most cause an unwitting user to come across the exploitative Javascript code. Although there are many ways that hackers attempt to achieve this goal, a simple illustrative example is a case of a hacker impersonating a representative of the website via email. A typical example is a hacker sending a message that appears to be a routine alert/message about your account, with a link that you (supposedly) should click to see more details of the notification. You can bet that most sophisticated hackers will hide the full text of the URL behind HTML. If they are lucky, you might not "hover" to see the destination link that you are about to browse to:
If the hacker succeeds at persuading you to click the link, you are now running Javascript code that the hacker has crafted for exploitative purposes.
Wrap-Up
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.
