What is Cross Site Scripting (XSS) ?

Cross-Site Scripting (XSS) is a vulnerability in a web application that allows a third party to execute a script in the user's browser on behalf of the web application. Cross-site Scripting is one of the most prevalent vulnerabilities present on the web today. The exploitation of XSS against a user can lead to various consequences, such as account compromise, account deletion, privilege escalation, malware infection, and many more.

When other users visit the page, the script runs in their browser, which can lead to:

Types of XSS

There are majorly three types of XSS

1. Reflected XSS

If the input has to be provided each time to execute, such XSS is called reflected. These attacks are mostly carried out by delivering a payload directly to the victim. Victim requests a page with a request containing the payload and the payload comes embedded in the response as a script. An example of reflected XSS is XSS in the search field.

Reflected XSS Practical Walkthrough

1. Security Level: Low

• The input is not validated or sanitized, so any script entered by the user executes directly.
• Here are the step-by-step DVWA: XSS (Reflected) instructions, with just enough detail

Step 1: Log in & set security

• First, log in to DVWA and open the “DVWA Security” settings page. In the security level options, select “Low” from the dropdown menu and then click on the “Submit” button to apply the change.

Step 2: Open the reflected XSS lab

• Next, go to the “Vulnerabilities” section and select “XSS (Reflected).” On this page, you will find a simple text box, usually labeled with something like “Enter your name.”

Step 3: Confirm normal behavior

• In the input box, type a harmless value such as “Geeks” and then click on the Submit button. The application will display a response like “Hello Geeks.” This simple test confirms that whatever you type into the form is reflected directly back onto the page.

Step 4: Inject a basic script

• In the input box, enter:

  <script>alert('XSS')</script>

• Click Submit.
• Expected result: A popup appears with XSS.
  Why it works: The app inserts your input directly into the HTML without escaping.

2. Security Level: Medium

Step 1: Go to DVWA Security and set Security: Medium then Submit.

Step 2: Baseline Test

Enter:

Geeks

Step 3: Simple HTML Tag Probe

<b>HELLO</b>

• If you see HELLO bolded then reflection occurs without encoding.

Step 4: Try Attribute/Event Handler Injection

• This shows a successful reflected XSS test in DVWA, where the input Hello <img src=x> was reflected back unescaped, proving the page is vulnerable.

3. Security Level: High

Step 1: Switch Security Level

• Go to DVWA Security then Select High.

Step 2: Token Reflection

• Enter this payload to check what is being reflected back at the client side (Web Interface).

TEST_HIGH

Step 3: Special Character Probe

• Now to check what special charaters are allowed and what are black listed enter these characters, which will later help us in payload balancing.

< > " '

• In the bottom-right corner, you will see the View Source option. Click it to analyze how the backend processes this HTML page. You will notice that the </script> tag is blacklisted, so we need to craft our payload accordingly.
• If we use an XSS payload containing <script> tags, it will be sanitized and displayed as normal text. However, if we balance our payload and use something that is not being sanitized by their secure code, we can successfully execute an XSS attack. This requires testing different inputs through a trial-and-error method.

Step 4: Confirm Filtering

• Lets try with our classic payload:

  <script>alert('High')</script>

• Usually blocked. Instead of execution, you may just see > being displayed because the script tag is being sanatised.

• Now search xss payloads github, and in the payload list seach "script" now all the payloads which are not containing scripts in it try using those payloads in this submit form.
• For reference I am using this payload which is not using script tag, it is working on on error and promt functionality:

<image src/onerror=prompt(8)>

• Here you can see the payload was successfully executed so the alert was generated.

2. Stored XSS:

When the response containing the payload is stored on the server in such a way that the script gets executed on every visit without submission of payload, then it is identified as stored XSS. An example of stored XSS is XSS in the comment thread.

• Here the payload and methodology remains the same but the payload is executed on the server side, therefore the input payload is saved on the server and the malicious payloads persists on this page forever.

3. DOM Based XSS

There is another type of XSS called DOM based XSS and its instances are either reflected or stored. DOM-based XSS arises when user-supplied data is provided to the DOM objects without proper sanitizing. You can either change it in the URL or the source of the web page.

Hand-On DOM XSS on DVWA

1. Security Level: Low

Step1: Go to the DVWA DOM XSS Module

Navigate to:

http://127.0.0.1/dvwa/vulnerabilities/xss_d/

Step 2: Observe how input is used

• DVWA’s DOM XSS page typically uses location.hash and writes it into the page with innerHTML.
• Example vulnerable code inside DVWA :

• This means whatever you put in the URL after #default= gets directly inserted into the page.

Step 3: Test with harmless input

http://127.0.0.1/dvwa/vulnerabilities/xss_d/?default=%3Cscript%3Ealert(0)%3C/script%3E

2. Security Level: Medium

Step 1: Start with the normal test

http://127.0.0.1/dvwa/vulnerabilities/xss_d/?default=%3Cscript%3Ealert(0)%3C/script%3E

You’ll see that <script> is blocked or printed as text, not executed.

Step 2: Use alternative HTML elements & attributes

• Image error event:

  http://localhost/dvwa/vulnerabilities/dom/#default=<img src=x onerror=alert(1)>

• SVG with onload:

  http://localhost/dvwa/vulnerabilities/dom/#default=<svg/onload=alert(1)>

• Iframe with JavaScript source:

  http://localhost/dvwa/vulnerabilities/dom/#default=<iframe src=javascript:alert(1)>

Step 3: Bypass using encoded payloads

http://127.0.0.1/dvwa/vulnerabilities/xss_d/?default=</select><img src =x onerror=alert(1)>

• If bypass works, you will get an alert popup (1).
• If not, check View Source or DevTools to see how your payload was sanitized — then adjust accordingly.

3: Security Level: High

Step1: Try your old payloads

http://127.0.0.1/dvwa/vulnerabilities/xss_d/?default=</select><img src =x onerror=alert(1)>

• As we can see, the previous payloads are being sanitized by the High security level. Therefore, we need to craft and adjust our payloads based on how the backend code handles input and the errors it produces.

Step 2: Use alternative HTML elements & attributes

http://127.0.0.1/dvwa/vulnerabilities/xss_d/?default=English#<script>alert(1)</script>

• If bypass works, you will get an alert popup (1).
• If not, check View Source or DevTools to see how your payload was sanitized — then adjust accordingly.