Cross-site scripting (XSS) is a cyber-attack where the cybercriminal injects malicious code into an already trustworthy and valid application or website so that the web browser can execute a properly crafted payload. Since the victim’s browser believes the code is from a legitimate source, it will run and execute it. The attacker’s purpose might be to acquire entry to a user’s data, such as any cookies or authentication information, to disguise as the user to do certain activities in the application, or to redirect users to a malicious website that they operate.
Before starting, just a list of articles about XSS for quick navigation:
- The terrifying world of Cross-Site Scripting (XSS) (Part 1)
- The terrifying world of Cross-Site Scripting (XSS) (Part 2)
- XSS in practice: how to exploit XSS in web applications
- Reflected XSS DVWA – An Exploit With Real World Consequences
- How to exploit a stored XSS vulnerability on DVWA
- How to exploit DOM XSS on DVWA
Types of Cross-Site Scripting Attacks
We can classify Cross-site scripting attacks into three different types: reflected, stored, and DOM-based.
Reflected XSS
Reflected cross-site scripting is also known as Type-II or Non-persistent cross-scripting. It is a cross-scripting attack where target servers reflect a malicious script. The attacker can include the payload into an error page, a search result, or the target server’s response to some request. The source of script in Type-II cross-site scripting is the request.
Whenever an internet user interacts with the malicious script, such as by clicking a link on a website or email, the malicious script travels to the infected site and then reflects the attack to the victim’s browser. Since the victim’s browser recognizes its server, it will execute the malicious script.
Stored XSS
Stored cross-site scripting is also known as Type-I or Persistent cross-site scripting. It is an attack where the hacker stores the malicious script on the targeted servers. The attacker usually tries to store the payload in the server’s persistent storage in some way. In this particular case, the effects are way more disruptive than the Reflected one.
When a user requests the data, the server delivers legit data mixed with the malicious script, making every application’s user a potential victim of this XSS attack.
DOM-Based XSS
It is also known as Type-0 cross-site scripting. It is an attack in which the malicious script alters the user’s browser’s DOM environment, causing the web page’s client-side code to run incorrectly.
Maybe is tricky to get the difference with Type-II XSS, but a simple way to understand the difference is just to imagine from where the error comes.
- In the case of Type-II, the poor sanitization makes the server send a dangerous page,
- In the case of DOM-Based, the error occurs inside the client. So it’s the result of a poor design in the frontend application.
How XSS is Used
Cybercriminals use XSS to trick a web application into transmitting data in a format that a user’s browser can understand. The attacker frequently provides a mix of HTML and XSS, although XSS may also be used to provide plugins, malicious files, or media assets.
An attacker can fool a web application by allowing data from an untrusted source, such as:
- sending data input in a form
- supply data to an API endpoint with client software
What makes it possible in these cases, it’s the bad sanitization of the input.
The Consequences of XSS Attack
Cross-site scripting assaults may be pretty damaging. Injecting code into a vulnerable application can allow data exfiltration or, in worst cases, malware installation on the user’s workstation. Attackers can employ session cookies to pose as authorized users, enabling them to do any activity with the same level of permissions as the victim account.
XSS may potentially harm a company’s reputation. An attacker can deface a corporate website by changing its content, causing the company’s image to suffer, or disseminating falsehoods. A hacker can also modify the instructions the users show when visiting the target website. This situation is challenging if the target is a government website or one that provides critical resources during a crisis.
The case of Mutation XSS in Google Search
An attacker uses a Mutation XSS vulnerability when his exploit takes advantage of the standard HTML parser.
It is tough to sanitize user input on the server due to browser variations. The server must account for any variations across browsers and browser versions.
For example, on September 26, 2018, one of the Closure library’s developers while patching that library, deleted part of the input sanitization. Noone was aware that the commit’s consequence was an XSS vulnerability.
A security researcher found this vulnerability in February 2019 and reported it to Google.
The fix was extremely quick, and on February 22, 2019, the vulnerability was no more present.
How to Prevent XSS Attacks
- Sanitizing Inputs: Always sanitize the inputs, it should be a general rule when you write some applications.
- Implement a Content Security Policy: It is a browser-side approach for setting access rights to client-side resources like JavaScript and CSS. It instructs the browser to execute contents only from the given sources using an HTTP header.
- Use HTTPOnly cookie flag: this option prevents client-side scripts from accessing cookies, essentially preventing XSS attacks.
- Use the correct output method: ensure you’re using the correct browser API output method. Do not attempt to encode the output manually.
Conclusion
Even if so simple and if it doesn’t appear in OWASP Top 10 2021, XSS represents a real danger for users, so as a security specialist, you must know it deeply.
I suggest you go further with your readings and learn How to build an XSS vulnerable application.
