Reflected Cross-Site Scripting

What is Reflected Cross-Site Scripting?

Unlike stored XSS, Reflected XSS does not store the payload to the database. An attacker can use the GET parameter like search_text, filter_name, etc. When un-sanitized user input is directly reflected in the HTML and malicious script is injected in the HTML, it is called Reflected Cross-Site Scripting.

Example:

Suppose an application is having a feature of searching the products from the product name via following URL

https://www.mystore.com/search?searchtext=book

If the parameter searchtext is reflected anywhere in HTML, there is a possibility of an XSS. Let's assume searchtext parameter is reflected like: 

<p> Search Results for the book:</p>

If XSS prevention is not applied to the searchtext parameter, an attacker can exploit it to generate a reflected XSS. An Attacker can provide the following payload to the searchtext parameter.

https://www.mystore.com/search?searchtext=book<script>exploit_script();</script>

When the above payload is displayed on the web page, the following code would be generated.

<p>Search Results for the book<script>exploit_script();</script>:</p>

As we can see malicious code is injected in the source code and it will be executed by the browser.

What is the impact and risk of Reflected XSS?

Risk and Impact of the reflected XSS depend on the way an attacker distributes the malicious link to victims. However, any kind of XSS is severe because it can cause an impact up to the account takeover of the victim. 

Prevention:

·      Input Validation: Application should validate each input and filter HTML tags and restricted words like "script". Validation must be done at the client-side and the server-side.

·      Encode Output: Application should encode each value to be displayed which is entered by the user. The application should use HTML, URL, Javascript, and CSS encoding.

·      Response Headers: If the web page is not intended to contain any HTML or JavaScript, the application should use the "Content-Type" and "X-Content-Type-Options" headers to make sure that browsers prevent any malicious code execution.

·      Content Security Policy(CSP): A developer should use CSP to reduce the impact of any XSS vulnerabilities.