Cross-site scripting (XSS) is a client-side code attack carried out by injecting malicious scripts into a legitimate website or web application. The injected malicious scripts are commonly referred to as a malicious payload. Currently, XSS is the most widespread type of web application vulnerability. It occurs when a particular web application uses unencoded or unvalidated user input in the output it generates.
XSS lets an attacker target a victim indirectly. In other words, the attacker exploits a vulnerability within a website or web application that the victim would visit, using it as a vehicle to deliver the malicious script to the victim’s browser.
An XSS attack is one of the most dangerous attacks for web applications because it can have significant consequences.
As shown above, the script is a print out of the latest comment from a comments database. If the page is vulnerable, an attacker could submit a comment that contains a malicious payload such as XSS:
The web page visitor will then get served the following HTML on the page.
As soon as the page loads in the victim’s browser, the malicious script will execute. In most cases, the victim is unaware of, and therefore unable to prevent, the attack.
XSS Attack Example
Below is a comprehensive list of XSS attack vectors used by attackers to compromise the security of a website or web application.
The XSS payload can be placed inside the body tag by using the onload attribute.
The iframe tag supports the embedding of another HTML page into the parent page. iFrames provide an effective way to pull off phishing attacks.
The link tag can be infected with scripts because it is often used to link to external style sheets.
The framework trait of the table and cell (td) tags can be used to connect to a script instead of an image.
The div tag can also embed a script.
An external site can use the object tag to include a script.
Types of Cross-Site Scripting Vulnerabilities
There are three types of XSS vulnerabilities: Stored XSS, Reflected XSS, and DOM Based XSS.
Stored XSS vulnerabilities occur when the malicious payload is saved. Stored cross-site scripting is pretty scary for a couple of reasons: The payload is invisible to browsers’ XSS filter, and when users visit the page they accidentally trigger the payload.
The Reflected XSS vulnerability is created when the user input from a URL or POST data is displayed on the page without being stored. This kind of payload is generally caught by built-in browser XSS filters in Chrome, Internet Explorer or Edge.
DOM Based XSS
The vulnerability occurs in the DOM (document object model) rather than the HTML.
The impact of XSS vulnerabilities vary and can include CSRF attacks, session hijacking, tokens and more. By employing an XSS vulnerability, an attacker can trick the user and take control of their account. When the victim has administrative rights, depending on the application and privileges of that account, an attack may even lead to code execution on the server.
To steer clear from cross-site scripting vulnerabilities, it is essential to implement context-dependent output encoding. In a few cases, it is sufficient to encode the HTML special characters like the opening and closing tags. In other cases, URL encoding is necessary.
Today, web browsers come with a built-in XSS filter, but they cannot track all kinds of cross-site scripting attacks. A browser's XSS filter should be considered just one line of defense to minimize the impact of existing vulnerabilities.
Web developers should avoid using blacklists as there are ways to bypass them. They should also avoid the removal of risky functions and characters because the browsers' XSS filters can't recognize the dangerous payloads when the output is tampered with, allowing for possible bypass.