Hello folks! It's darksp1rit again with another walkthrough blog. Today we'll go through the Damn Vulnerable Web Application's Reflected XSS lab. Let's not waste time and dive into the writeup.

XSS and it's type

Cross-Site Scripting (XSS) is a web security vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. These scripts can steal sensitive information, hijack user sessions, or deface websites. XSS attacks are generally categorized into three main types: Reflected XSS, Stored XSS, and DOM-based XSS.

Reflected XSS

Reflected XSS occurs when malicious scripts are injected through user input and immediately reflected back in the server's response without proper validation or sanitization. Unlike Stored XSS, the malicious payload is not permanently stored on the server but is typically delivered through crafted URLs or form submissions. This type of attack requires the victim to click a malicious link or submit a manipulated form to trigger the execution of the injected script.

Let's look at our lab. We start with low to high difficulty.

Reflected XSS — Low

After logging into DVWA, navigate to XSS (Reflected) section. That looks like this.

If it's not set to low level, go to DVWA Security and set it to low for beginning.

Here, we can see a input field asking name. Whatever we type, it just shows that. Now, let's make things interesting. Submit an input including HTML tag like <h1>XSS</h1> . Ah! It now reflects exactly as a HTML code.

Let's try something spicy by inserting a simple JavaScript code like <script>alert('XSS')</script> and see what happens.

Voila! This input field is vulnerable to RXSS. Now, let's see what happend in the backend by viewing the source code.

It's just taking an input, and gives the output as Hello {INPUT} , that means it isn't sanitizing the input. Whatever we input, it just reflects. That's why the vulnerability occurs.

Reflected XSS — Medium

Go to DVWA Security and set the level to Medium . Now, let's repeat our previous steps.

Again, it reflects the HTML tags. But when we input <script>alert('XSS')</script> , it show like

What happened? Okay, we'll find the issue later. For now, let's try another payload like <sCrIpT>alert('XSS')</sCrIpT>

Yes!!! It's popped up again like this

What happened here? Let's have a look into the source code.

Here, input is a little bit sanitized by hardcoded <script> . So, when we try to use <script> , it replaces the string with a blank string. But when we mix upper and lower case like <sCrIpT> , it executes the tag since it just looks for <script> and doesn't even checks all for both upper and lower case. In general, all XSS payloads should work here except something with <script>

Reflected XSS — Hard

Now, set the difficulty to Hard

Let's try with our second payload <sCrIpT>alert('XSS')</sCrIpT>

The output is like this. So, our second payload is not working here, and the first one will also not work for sure. Let's try something other. Here's some interesting XSS payloads.

Okay! Now insert "><img src=x onerror=alert('XSS');> and ENTER.

So, this one is working. Why? Again, let's check the source code.

Here, the level is using harder sanitization with this regex /<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i

So, whatever we use using <script> or <sCrIpT> or <scrXXXipt> or something like these, the payload won't work here.

Our "><img src=x onerror=alert('XSS');> this payload isn't sanitized by the application. So, it's being executed as it is.

Reflected XSS — Impossible

Whatever payload you use here isn't going to be executed. Let's see the source code to understand why.

• htmlspecialchars() replaces <, >, & (and by default ") with HTML entities, so any <script> or HTML tag you send becomes plain text in the browser and cannot create an element or execute JS.
• The echoed value is placed inside a text node (inside <pre>…</pre>), not inside an attribute or inside innerHTML of existing markup — that's a safe output context for escaped text.
• There is also an anti-CSRF token check (checkToken) that prevents CSRF-style injection via a third-party site submitting a crafted link if the token is required and unavailable.

That was all about DVWA Reflected XSS. Hope to continue writing with something else. You can stay updated by connecting to my LinkedIN. Till then,

./logout