What is Reflected Cross-Site Scripting (XSS)?
Reflected Cross-Site Scripting vulnerabilities are a subcategory of XSS vulnerabilities. Reflected XSS attacks occur when an attacker is able to trick a user to execute a malicious browser script by giving the user a URL to a vulnerable application including a malicious (often obfuscated) payload. The victim clicks on the URL with the payload (often in form of a URL parameter) which opens the web application and unwittingly executes the payload in the browser.
Reflected XSS is also sometimes known to as Non-Persistent or Type-I XSS. It is formally defined by Mitre in CWE-79: “Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)” along with the other categories of XSS. In the latest OWASP Top-10 2021, reflected XSS is included along with other injection vulnerabilities in the “A03:2021-Injection” category.
Reflected XSS attacks are often considered to be the more easier to execute than stored XSS attacks, because the malicious input is directly added to a URL parameter. However, both types of attacks can be devastating to a web application and its users.
Reflected XSS Examples
In a reflected XSS attack, the attacker injects malicious code into a web page without storing the injected code on the server-side. Instead, this code is then reflected back to the user, and is executed by the browser. Most typically, this is done via URL parameters where the code is injected into the URL of the page. For example, the following URL contains a malicious script in the “input” parameter:
http://example.com/page.php?input=<script>alert(‘XSS’)</script>
The application reflects and displays the value of the parameter back to the user in such a way that the JS code is executed in the client’s browser. If the exploit is successful, a popup with the ‘XSS’ text should be displayed.
Reflected XSS FAQ
What Causes Reflected Cross-Site Scripting (XSS)?
There are many causes for reflected cross-site scripting. A common cause is when user input is not properly sanitized before being displayed back to the user. This can happen when user input is inserted into the HTML without being properly escaped.
How does reflected XSS differ from stored XSS?
With reflected XSS, the malicious script is injected into the web page through user input. Once the page is loaded, the script is executed, and the user’s session is hijacked. With stored XSS, the malicious script is stored on the web server. When the user visits the page, the script is executed, and the user’s session is hijacked.
What is XSS?
XSS is a type of security vulnerability that allows an attacker to inject malicious code into a web page. This code is then executed by the web browser of any user who visits the page.
What is the security impact of reflected XSS?
The short answer: it depends. As with all types of XSS,the malicious code provided by the attacker is executed by the victim’s web browser. Attackers can leverage this to perform actions such as having the user send their session cookie to other users and perform actions in the application. Often this can lead to the attacker gaining access to the victim’s account, stealing sensitive information, or even in some extreme situations infecting the victim’s computer with malware. Often XSS is chained with other attacks and have been known to be used in some attack chains leading up to arbitrary command injection into the vulnerable application.
Does BB-SEC help detect and prevent reflected XSS?
Yes! BB-SEC offers penetration testing services as well as static and dynamic code analysis that tests for all types of Cross-Site Scripting Vulnerabilities including reflected Cross-Site Scripting. Schedule a free consultation to see how BB-SEC can help you maintain your applications and software free of such vulnerabilities.
Reflected Cross-Site Scripting Prevention
Reflected Cross-Site Scripting (Reflected XSS) is prevented with the same techniques as other types of XSS:
- Using secure frameworks and libraries
- User input validation followed by escape and sanitization
- Output encoding
- Usage of safe sinks
- Usage of security headers
- Web Application Firewalls
To read about these controls in depth, check out our Ultimate Cross-Site Script Prevention Guide HERE.
