**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.** 

In this article, we will explore how Reflected Cross-Site Scripting (XSS) vulnerabilities work by exploiting two real-world examples: Zixem and Acunetix’s test site. We’ll learn how attackers inject malicious scripts through URLs, how these scripts execute in the victim’s browser which could result in sensitive data like session cookies getting exposed. We’ll also discuss effective techniques to detect, demonstrate, and mitigate this vulnerability. 

What is XSS? 

Cross-site scripting (XSS) poses a threat to web security. It lets hackers insert harmful scripts into web pages that other people see. These scripts written in JavaScript, can steal cookies, session tokens, or other private data. They can send users to dangerous websites. They can even change what shows up on a web page. 

XSS problems happen when a website doesn’t check or validate what users type in. This lets malicious code execute and run on the victim’s browser. 

What is Reflected XSS? 

Reflected XSS, also known as non-persistent XSS, occurs when malicious input submitted by an attacker is immediately “reflected” back to the user by the web application, often via query parameters in the URL. 

In this type of attack: 

1. An attacker creates a URL containing a malicious script. 

2. The victim clicks the link or is tricked into doing so (e.g., via phishing emails or malicious websites). 

3. The web application includes the unvalidated input directly in the HTTP response (e.g., in an error message, search result, or form field). 

4. The injected script executes in the victim’s browser, running with the same permissions as the legitimate content of the web application. 

Example Scenario of Reflected XSS: 

A search bar on a website displays the search term entered by the user without proper sanitization. 
Malicious URL: https://example.com/search?q=<script>alert(‘XSS’)</script> 

If the application directly reflects the q parameter value in the response, the script runs in the victim’s browser when they open the link. 

Why Reflected XSS is Dangerous 

Attackers use social engineering techniques to lure victims into executing the malicious script. The attack can lead to: 

1. Theft of sensitive user data (e.g., cookies, session IDs). 

2. Hijacking of user sessions. 

Walkthrough: Reflected XSS in Zixem 

Target Link: https://www.zixem.altervista.org/XSS/1.php?name=zxm 

In the target application perform a cross-site scripting attack that calls the alert function. 

1. Copy and paste the script into the name query parameter: <script>alert(1)</script> 

Command: https://www.zixem.altervista.org/XSS/1.php?name=%3Cscript%3Ealert(1)%3C/script%3E 

2. Press Enter.  

An alert/dialog box will appear showing reflected XSS exploited successfully. 

Walkthrough: Reflected XSS in Home of Acunetix Art 

1. First, log in to the site using username and password as test and test – login page 

2. To confirm you got a session ID, press Ctrl + Shift + I or right-click on the website and click on inspect to open the developer’s console. Under Application -> Cookies -> testphp.vulnweb.com, you will find the session cookie named login whose value is test%2Ftest 

3. The search bar is vulnerable to Reflected XSS. Let’s write a script to display the session cookie in an alert box. 
   <script>alert(document.cookie)</script> 

4. An alert box is displayed in the web browser showing the session cookie. 

5. alert() is just a proof of concept to show that arbitrary javascript can be executed in a harmless way. Once an attacker can inject JS, they can do far more than just pop alerts like steal session cookies or deface the website. 

6. To mitigate this we can set HttpOnly value to True. You will find this option under the Developer option. Now if we once again try to display the document.cookie, we are unsuccessful this time. 

We can prevent XSS by: 

1. Strictly filtering user input upon arrival. 

2. Encoding user data before outputting it in HTTP responses. 

3. Using appropriate response headers like Content-Type and X-Content-Type-Options. 

4. Implementing Content Security Policy (CSP) as a final defense.