Cross-Site Scripting

Types of XSS attacks

Reflected XSS
Overview
Key Characteristics:
Example of a Reflected XSS Vulnerability
Stored Cross-Site Scripting (XSS)
Overview
Key Characteristics:
Example of a Stored XSS Vulnerability
DOM-Based Cross-Site Scripting (XSS)
Overview
Key Characteristics:
Example of a DOM-Based XSS Vulnerability
Preventing XSS Attacks
Key Prevention Measures:
Reflected XSS
Lab
Information
Solution
Impact of reflected XSS attacks
Searching for Reflected XSS Manually
Stored XSS
Lab
Information
Solution
Searching for Stored XSS Manually
DOM-based XSS
Labs
Information (Lab 1)
Solution (Lab 1)
Information (lab 2)
Solution (Lab 2)
Information (Lab 3)
Solution (Lab 3)
Information (Lab 4)
Solution (Lab 4)
Testing DOM XSS Manually
Testing HTML Sinks:

Cross-Site Scripting 1
 Testing JavaScript Execution Sinks:

Types of XSS attacks

Reflected XSS, where the malicious script comes from the current HTTP
request.

Stored XSS, where the malicious script comes from the website's database.

DOM-based XSS, where the vulnerability exists in client-side code rather

than server-side code.

Reflected XSS
Overview
Reflected XSS is a type of cross-site scripting vulnerability that occurs when an
application receives data in an HTTP request and includes it in the response
without proper sanitization.

Key Characteristics:
The attack is reflected rather than stored.

It requires the victim to click on a malicious link.

The attack is executed within the user's browser in the context of their
session.

Example of a Reflected XSS Vulnerability

Safe URL:

https://insecure-website.com/status?message=All+is+well

Response:

<p>Status: All is well.</p>

Malicious URL (Exploiting XSS):

https://insecure-website.com/status?message=<script>/*+Bad+stuff+her

Cross-Site Scripting 2
 e...+*/</script>

Response:

<p>Status: <script>/* Bad stuff here... */</script></

Impact:

If a user visits the attacker’s crafted URL, the malicious script executes in
their browser.

The script can perform actions or access sensitive data in the context of
the user’s session.

Stored Cross-Site Scripting (XSS)

Overview
Stored XSS, also known as persistent XSS or second-order XSS, occurs when
an application stores untrusted user input and later includes it in HTTP
responses without proper sanitization.

Key Characteristics:
The attack is stored on the server and affects multiple users.

It executes when users view the stored content.

Common sources include blog comments, chat messages, and user

profiles.

Example of a Stored XSS Vulnerability

Safe User Input:

<p>Hello, this is my message!</p>

Malicious Input (Exploiting XSS):

<p><script>/* Bad stuff here... */</script></p>

Impact:

Cross-Site Scripting 3
 The malicious script is saved in the database and executed whenever users
view the content.

It can steal cookies, session tokens, or sensitive information.

It may perform actions on behalf of other users.

DOM-Based Cross-Site Scripting (XSS)

Overview
DOM-based XSS occurs when client-side JavaScript processes data from an
untrusted source in an unsafe manner, modifying the DOM and potentially
allowing script execution.

Key Characteristics:
The attack occurs entirely in the browser.

It does not require a server response to inject malicious scripts.

The DOM is directly modified by insecure JavaScript.

Example of a DOM-Based XSS Vulnerability

Vulnerable JavaScript Code:

var search = document.getElementById('search').value;

var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

Malicious Input (Exploiting XSS):

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

Impact:

The attacker's script executes when the manipulated DOM element is

rendered.

It can steal user data, manipulate the page, or perform unauthorized

actions.

This often occurs when data is taken from URL parameters, input fields, or
local storage and inserted into the DOM without sanitization.

Cross-Site Scripting 4
 Preventing XSS Attacks
Key Prevention Measures:
Filter Input on Arrival: Validate and sanitize user input as strictly as possible.

Encode Data on Output: Use HTML, URL, JavaScript, and CSS encoding to
prevent execution.

Use Secure Response Headers: Set Content-Type and X-Content-Type-Options to

control browser interpretation.

Implement Content Security Policy (CSP): Restrict script execution to

reduce XSS risks.

Reflected XSS
Lab
Information
name: Reflected XSS into HTML context with nothing encoded

link: https://portswigger.net/web-security/cross-site-
scripting/reflected/lab-html-context-nothing-encoded

Solution
Enter the following javascript code in the Search box:

<script>alert("test")</script>

Impact of reflected XSS attacks

The attacker can:

Perform any action within the application that the user can perform.

View any information that the user is able to view.

Modify any information that the user is able to modify.

Cross-Site Scripting 5
 Initiate interactions with other application users, including malicious attacks,
that will appear to originate from the initial victim user.

Searching for Reflected XSS Manually

1. Test Every Entry Point: Check all input fields, URLs, headers, and request
bodies.

2. Submit Random Values: Use unique 8-character alphanumeric values to

detect reflection.

3. Identify Reflection Context: Determine if input appears in HTML, attributes,

or scripts.

4. Test an XSS Payload: Insert a basic XSS script and check if it executes.

5. Try Alternative Payloads: If blocked, modify the payload based on context.

6. Verify in a Browser: Use alert(document.domain) to confirm execution.

Stored XSS
Lab
Information
name: Stored XSS into HTML context with nothing encoded
Link: https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-
context-nothing-encoded

Solution
enter the following javascript code in the comment box

<script>alert(1)</script>

Searching for Stored XSS Manually

1. Identify Entry Points: Test all input fields, URLs, request headers, and out-
of-band sources.

2. Locate Exit Points: Check all responses where user data might appear.

Cross-Site Scripting 6
 3. Find Entry-Exit Links: Submit unique values and track where they reappear.

4. Confirm Data Storage: Ensure the input persists across multiple requests.

5. Test XSS Payloads: Insert scripts and verify execution in the stored
context.

DOM-based XSS
Labs
Information (Lab 1)
name: DOM XSS in document.write sink using source location.search

Link: https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-
document-write-sink

Solution (Lab 1)
1. Enter a random alphanumeric string into the search box.

2. Right-click and inspect the element, and observe that your random string
has been placed inside an img src attribute.

3. Break out of the img attribute by searching for:

"><script>alert(1)</script>

Information (lab 2)
name: Lab: DOM XSS in document.write sink using source location.search inside a
select element

Link: https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-
document-write-sink-inside-select-element

Solution (Lab 2)
1. On the product pages, notice that the dangerous JavaScript extracts
a storeId parameter from the location.search source. It then uses document.write to
create a new option in the select element for the stock checker
functionality.

Cross-Site Scripting 7
 2. Add a storeId query parameter to the URL and enter a random alphanumeric
string as its value. Request this modified URL.

3. In the browser, notice that your random string is now listed as one of the
options in the drop-down list.

4. Right-click and inspect the drop-down list to confirm that the value of
your storeId parameter has been placed inside a select element.

5. Change the URL to include a suitable XSS payload inside

the storeId parameter as follows: product?productId=1&storeId="></select>
<img%20src=1%20onerror=alert(1)>

Information (Lab 3)
name: DOM XSS in innerHTML sink using source location.search

Link: https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-
innerhtml-sink

Solution (Lab 3)
Enter the following Javascript code the search box:

<img src=1 onerror=alert(1)>

Information (Lab 4)
name: DOM XSS in innerHTML sink using source location.search

Link: https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-
innerhtml-sink

Solution (Lab 4)
Enter the following Javascript code the search box:

<img src=1 onerror=alert(1)>

Testing DOM XSS Manually

Testing HTML Sinks:

Cross-Site Scripting 8
 1. Inject a Random String – Place a unique alphanumeric value into
location.search .

2. Inspect the DOM – Use developer tools ( Ctrl+F / Cmd+F ) to locate the string.

3. Identify Context – If inside quotes, try breaking out with special characters.

4. Check URL Encoding – Some browsers auto-encode inputs, affecting XSS

feasibility.

Testing JavaScript Execution Sinks:

1. Find JavaScript References – Search ( Ctrl+Shift+F ) for location , document.URL ,
etc.

2. Use a Debugger – Set breakpoints to track input flow to execution sinks.

3. Inspect Variables – Hover over variables to check values before execution.

4. Refine Input – Modify payloads to see if XSS execution is possible.

Cross-Site Scripting 9