Reflected XSS into HTML context with nothing encoded

In this lab, the goal is to inject JavaScript code and successfully call the alert() function to demonstrate a reflected cross-site scripting (XSS) vulnerability. Click “ACCESS THE LAB” to begin.

Once the lab loads, it presents a simple blog website with a search functionality. As part of the initial reconnaissance, we should explore all available features to identify potential vulnerabilities.

I started by entering a basic keyword, hello, into the search box. I observed that the search term was reflected directly in the URL and immediately rendered on the page.

Next, I tested whether the input was properly sanitized by injecting simple HTML code into the search field. The browser rendered the HTML instead of treating it as plain text, which should not happen on a secure website

This behavior confirms that the application is vulnerable to reflected XSS.

With this confirmation, it was time to perform the final attack. I injected the following JavaScript payload into the search box: <script>alert('hello')</script>

The payload executed successfully and displayed an alert popup, proving that arbitrary JavaScript can be executed in the victim’s browser.

This completes the lab and demonstrates a successful exploitation of a reflected cross-site scripting vulnerability.

Reflected XSS into Attribute with Angle Brackets (HTML-Encoded)

Let’s begin by opening the lab by clicking on ACCESS THE LAB and exploring the website’s functionality.

At first glance, the website appears to be an exact copy of the old version. To verify whether a reflected XSS vulnerability exists, I started by testing a simple payload: <h1>hello</h1>.

However, this payload did not execute. Instead, the application displayed the input as plain text, indicating that HTML tags were being encoded or filtered.

Next, I entered a simple alphanumeric string:

cybercena123

This time, instead of relying on the rendered output, I inspected the page source. Using the browser’s Developer Tools and the search feature, I searched for the injected keyword.

From the source code, it was clear that the input was being reflected back into the HTML. More importantly, it was reflected inside a quoted HTML attribute.

Recognizing this context, I crafted a simple attribute-breaking payload to manipulate the HTML and inject JavaScript behavior. The payload used was:

" onmouseover="alert(1)

After submitting this payload, I inspected the source code again and observed the following reflected HTML:

<input type=text placeholder='Search the blog...' name=search value="" onmouseover="alert(1)">

As shown below, the payload successfully breaks out of the value attribute and injects a new event handler (onmouseover).

Now, whenever the mouse cursor is moved over the search input field, the JavaScript alert(1) function is triggered, resulting in a popup.

This confirms the presence of a reflected XSS vulnerability in an HTML attribute context, even though angle brackets are HTML-encoded.

Reflected XSS into a JavaScript string with angle brackets HTML-encoded

In this lab, I first tried entering a simple alphanumeric value, cybercena123. The application displayed the same content in the response, and nothing unusual was visible in the output.

To understand how the input was being handled, I checked the page source and searched for the injected value. I found that the input was reflected inside a JavaScript block and stored within a string:

<script>     
var searchTerms = 'cybercena123';     
document.write('<img src="/resources/images/tracker.gif?searchTerms=' + encodeURIComponent(searchTerms) + '">');
 </script>

This shows that the application places user input directly inside a JavaScript string. Although angle brackets are HTML-encoded, the input is still interpreted within a JavaScript execution context.

Next, I attempted to break out of the JavaScript string by injecting the following payload: '-alert(1)-'

Visually, the page appeared unchanged, similar to the previous input. However, this time an alert popup was triggered in the browser. When I inspected the source code again, I could see that the injected payload had modified the JavaScript logic:

<script>
var searchTerms = ''-alert(1)-'';     
document.write('<img src="/resources/images/tracker.gif?searchTerms=' + encodeURIComponent(searchTerms) + '">');
 </script>

Here, the payload successfully breaks out of the JavaScript string and uses JavaScript’s subtraction operator to force execution of alert(1). Even though the final value of searchTerms becomes invalid (NaN), the JavaScript code is executed during evaluation.

This confirms a reflected XSS vulnerability in a JavaScript string context, despite angle brackets being HTML-encoded.