Cross-site scripting (XSS) is a type of injection security attack in which an attacker injects data, such as a malicious script, into content from otherwise trusted websites. Cross-site scripting attacks happen when an untrusted source is allowed to inject its own code into a web application, and that malicious code is included with dynamic content delivered to a victim's browser.
Cross-site scripting allows an attacker to execute malicious scripts in another user's browser. However, the attacker doesn't attack the victim directly; rather, the attacker exploits a vulnerability in a website the victim visits and gets the website to deliver the malicious script for the attacker.
How cross-site scripting works
Like all injection attacks, XSS takes advantage of the fact that browsers can't tell valid markup from attacker-controlled markup -- they just execute whatever markup text they receive. The attack circumvents the Same Origin Policy, which is intended to prevent scripts originating in one website from interacting with scripts from a different website.
The Same Origin Policy requires that all content on a webpage come from the same source. When the Same Origin Policy isn't enforced, an attacker is able to inject a script and modify the webpage to suit their own purposes -- for example, to extract data that will allow the attacker to impersonate an authenticated user, or to input malicious code for the browser to execute.
XSS can be used in a number of ways to cause serious problems. The traditional use of XSS enables an attacker to steal session cookies, allowing that attacker to pretend to be the user (victim). But it's not just stealing cookies; attackers can use XSS to spread malware, deface websites, create havoc on social networks, phish for credentials and in conjunction with social engineering techniques, perpetrate more damaging attacks.
Types of XSS vulnerabilities
There are three main categories of cross-site scripting vulnerabilities: stored XSS, reflected XSS and DOM-based XSS.
Stored (persistent) XSS is the most damaging type of cross-site scripting attack. The attacker injects a script -- also called the payload -- that is stored permanently on the target application, such as a database. For example, an attacker inserts a malicious script on a blog, in a forum post or in a comment field.
The XSS payload will be then be served as part of a webpage when the victim navigates to the affected webpage in a browser. Then, once the victim views the page in a browser, he will end up inadvertently executing the malicious script.
Reflected XSS is the most common type of cross-site scripting vulnerability. In this type of attack, the attacker has to deliver the payload to the victim. Therefore, the attacker's payload script must be part of the request sent to the web server and reflected back so the HTTP response includes the payload from the HTTP request.
The attacker uses phishing emails and other social engineering methods to lure the victim to inadvertently make a request to the server that includes the XSS payload. The victim then executes the script that gets reflected and executed inside the browser. Because reflected XSS isn't a persistent attack, the attacker must deliver the payload to each victim.
DOM-based cross-site scripting is an advanced type of XSS attack made possible when the web application's client-side script writes user-provided data to the Document Object Model (DOM).
The web application then reads the data from the DOM and delivers it to the browser. If the data isn't handled correctly, the attacker is able to inject a payload that will be stored as part of the DOM. The payload is then executed when the data is read back from the DOM.
Cross-site scripting prevention methods
The following are best known practices to prevent cross-site scripting:
Escaping user input is one way to prevent XSS vulnerabilities from appearing in applications. This means taking the data an application has received and ensuring it's secure before rendering it for the user. Escaping user input prevents key characters in the data that a webpage receives from being interpreted as executable code. This means preventing the browser from interpreting characters used to signal the start or end of executable code, and it translates them to "escaped." For example, quote characters, parentheses, brackets and some other punctuation marks are sometimes used to set off executable code; "escaping" these characters means converting them from single characters that would not be displayed into strings that the browser interprets as printable versions of the characters.
Sanitizing user input is another way to prevent cross-site scripting attacks, which is especially helpful on sites that allow HTML markup. This prevention method scrubs the data clean of potentially executable characters, changing unacceptable user input to an acceptable format and ensuring the data received can't be interpreted as executable code.
Input validation makes certain an application is rendering the correct data and preventing malicious data from harming a website, database and users. Validating input helps prevent XSS in forms because it stops a user from adding special characters into webpage data entry fields by refusing the request. Input validation helps reduce the possibility of harmful effects if an attacker should discover such an XSS vulnerability.
Continue Reading About cross-site scripting (XSS)
- Find out how website design platforms can expose cloud apps to cross-site scripting and other attacks