What is Cross-Site Scripting (XSS)?
Cross-site scripting (XSS) is a vulnerability in web applications that allows a third party to execute scripts in a user’s browser on behalf of the web application. Cross-site scripting is one of the most prevalent vulnerabilities on the web today. Exploiting XSS against users can lead to various consequences, such as account compromise, account deletion, privilege escalation, malware infection, and more.
In the first days it was called CSS, but it wasn’t quite what it is today. Initially, we discovered that malicious sites could use JavaScript to read data, run scripts, and modify page content by embedding responses from other sites into iframes. At the time it was called CSS (Cross Site Scripting). The definition changed when Netscape introduced the same-origin policy and cross-site scripting was restricted to enable cross-origin response reading. It was soon suggested that this vulnerability be called XSS to avoid confusion with Cascading Style Sheets (CSS). The possibility of XSSed arises when a website does not properly handle the input the user provides to it before inserting it into the response. In this case, crafted input can be provided that, when embedded in the response, acts as a block of JS code and is executed by the browser. Depending on the context, there are two types of XSS –
- Reflected XSS: If input must be provided for every execution, this type of XSS is called Reflected XSS. These attacks are primarily performed by delivering the payload directly to the victim. The victim requests a requested page containing a payload, which is embedded in the response as a script. An example of reflected XSS is XSS in search fields.
- Stored XSS: When a response containing a payload is stored on the server in such a way that every access executes the script without submitting the payload, it is identified as Stored XSS. An example of stored XSS is XSS in comment threads.
There is another type of XSS, called DOM-based XSS , instances of which are either reflected or stored. DOM-based XSS occurs when user-supplied data is provided to a DOM object without proper sanitization. Below is an example of code vulnerable to XSS attack, note the variables firstname and lastname :
- php
<?php if(isset($_GET["firstname"]) && isset($_GET["lastname"])) { $firstname = $_GET["firstname"]; $lastname = $_GET["lastname"]; if($firstname == "" or $lastname == "") { echo "<font color=\"red\">Please enter both fields...</font>"; } else { echo "Welcome " . $firstname. " " . $lastname; } } ?> |
User-supplied input is added directly to the response without any sanity checks. The attacker inputs something like –
- html
<script> alert(1) </script> |
It will be rendered as JavaScript. XSS has two aspects (and any security concerns) –
- Developer: If you are a developer, the focus will be on secure development to avoid any security holes in the product. You don’t need to delve into exploitation, just use tools and libraries while applying best practices for secure code development as prescribed by security researchers. Some resources for developers are – a). OWASP Coding Project: It is a library written in Java and developed by the Open Web Application Security Project (OWASP). It is free, open source and easy to use. Second). “X-XSS-Protection” header: This header instructs the browser to activate the built-in XSS auditor to identify and block any XSS attempts against the user. C). OWASP’s XSS Protection Cheat Sheet: This resource lists the rules to follow during development with appropriate examples. These rules cover a variety of situations where developers may miss something that could make a site vulnerable to XSS attacks. d). Content Security Policy: It’s a standalone solution to XSS-like problems, it instructs browsers about “safe” origins, and beyond that, no script should be executed from any origin.
- Security researchers: On the other hand, security researchers want similar resources to help them find instances where developers have gone bad and left entry points. Researchers can take advantage of – a). CheatSheets – 1. OWASP’s XSS filter evasion cheat sheet. 2. Rodolfo Assis’s XSS cheat sheet. 3. Veracode’s XSS cheat sheet. Second). Hands-on Labs – 1. bWAPP 2. DVWA (Damn Vulnerable Web Application) 3. prompt.ml 4. CTFs c). Reports – 1. Hackerone Hactivity 2. Personal blogs of prominent security researchers like Jason Haddix, Geekboy, Prakhar Prasad, Dafydd Stuttard (Portswigger).
