Cross-Site Scripting (XSS)
Cross-site scripting—referred to as XSS—is an application vulnerability that has the potential to wreak havoc on applications and websites. XSS is so rampant and potentially harmful that it continues to be included in the Open Web Application Security Project (OWASP) list of top 10 vulnerabilities.
What is Cross-Site Scripting (XSS)?
Cross-site scripting is a website attack method that utilizes a type of injection to implant malicious scripts into websites that would otherwise be productive and trusted. Generally, the process consists of sending a malicious browser-side script to another user. This is a common security flaw in web applications and can occur at any point in an application where input is received from the browser and used to create output without first validating or encoding the data.
In some cases, browser-side script can also introduce this vulnerability allowing an attacker to exploit it without the target user making a request to the web application.
Attackers exploit XSS by crafting malicious code that can be routed to another user, is then executed by the unsuspecting browser. Since the script is most often included in the content of the web application’s response, it is executed and has the same access as if the script is legitimate. Access may be allowed to session tokens, cookies, and even confidential or sensitive information the browser has access to on that site, even rewriting the HTML page content.
How does Cross-site Scripting work?
Exploiting cross-site scripting vulnerabilities is a relatively simple task for attackers. By injecting a malicious script into unprotected or un-validated browser-supplied input, the attacker causes the script to be returned by the application and executed in the the browser. This could allow it to take control of the application’s functionality, manipulate data, or plant additional malicious code.
What are the types of XSS attacks?
There are three main types of XSS attacks: reflected XSS, stored XSS, DOM-based XSS.
In reflected XSS attacks, the malicious script is injected into an HTTP request (usually by specifically crafted link supplied to the user). As the simplest variety, it uses input parameters in the HTTP request that can be easily manipulated to include the damaging script content. The malicious script is then reflected from the server in a HTTP response and gets executed in the victim’s browser.
Since the script is received by the browser in the application’s response, it appears to be legitimate and executes in the user’s browser, allowing retrieval and manipulation of any data that the browser has access to via the DOM for that site.
Stored XSS attacks are where the malicious script comes from a database on the website. The XSS attack involves locating a vulnerable object on the website and injects the script into the unsuspecting field on the server, such as a text or comment field. This content is stored by the site in a database to be used in creating responses to future requests. Each visitor on the website that receives that content then executes the script, which again allows retrieval and manipulation of any data that the browser has access to via the DOM for that site.
In a DOM-based XSS attack, the vulnerability lies in the browser-side script code instead of the server-side code, modifying the environment in the unsuspecting victim’s browser. The result is that the supplied malicious code and modify access data or modify the behavior of the application itself within that browser session.
What are the Cross-site Scripting attack vectors?
There are several vectors commonly utilized in XSS attacks:
- <body> tag: Event attributes can also be the source of the script when provided through the “body” tag.
- <iframe> tag: Especially effective for phishing attacks, this vector allows the XSS attack to embed another HTML page into the current page.
- <input> tag: Some browsers allow manipulation through this vector, which can be used to embed a script.
- <link> tag: This tag can contain a script, instead of the normal use of linking to external style sheets.
- <table> tag: Where the background attribute normally refers to an image, this could be compromised to refer to the offending script.
- <div> tag: This tag also contains a background reference and can be used in the same way as <table> to refer to a script.
- <object> tag: Scripts from an external site can be included using this tag.
While there are other vectors XSS attackers use in their efforts to steal information and compromise websites, these are some of the most commonly used methods. Developers must adhere to proper escaping and sanitizing practices to guard against such attacks.
What is the impact of XSS vulnerabilities?
XSS has the potential to wreak havoc on applications and websites. The fact that XSS has been present in every OWASP top 10 list illustrates the need to protect web applications from this vulnerability.
Depending on the attacker and their malicious intent, XSS attacks can result in different impacts including:
- hijacking a user’s session, utilizing credentials to access other sites or redirect the user to unintended websites,
- altering website pages or inserting sections into a web page,
- executing scripts to extract sensitive information from cookies or databases,
- if the victim has administrative rights, the attack could extend to the server side, causing further damage or retrieving additional sensitive information.
How to test Cross-site Scripting?
Testing for XSS vulnerability begins at the design phase, taking best practices into account from the beginning. Website designers should build in security measures, not add them after-the-fact.
Initial tests include bench scans of code to identify the use of common XSS attack vectors that present potential vulnerabilities. This allows mitigation of the weaknesses before actual application testing begins.
Key steps in testing for XSS vulnerabilities for critical web applications include:
- utilizing a code scanning tool to detect vulnerabilities that allow code corrections during the development process,
- implementing automated testing functionality that will reveal potential vulnerabilities thoroughly and quickly.
What is a Cross-site Scripting example?
Cross-site scripting can be exploited when a web application uses data supplied by the browser to create responses to user requests. A very simplistic example would be a case where a web application makes use of a parameter in the URL to provide a customized response to the user.
Let’s say exmple.com/profile contains a name parameter. The URL for the request would look like https://example.com/profile?user=Tammy. The web application responds with “Hi Tammy” at the top of the page based on this input.
If the user parameter is not validated to ensure it only contains expected data, an attacker could have a user visit a malicious version of the URL that looks like this:
When the response is sent to the browser, it includes that malicious script which is then executed in the browser, likely without the user even knowing. This is an example of a reflected XSS attack. The malicious code is immediately “reflected” back to the user making the request.
- Sanitize input: Whether for internal web pages or public websites, never trust the validity of user input data. Screen and validate any data fields, especially if it will be included as HTML output.
- Scan code: Implement software that scans code for vulnerabilities, including cross-site scripting, to ensure that best practices are being followed and minimizes exposure from XSS and other OWASP-listed vulnerabilities.
- Content Security Policy: Use Content Security Policy (CSP) to define what a website can do, and by this reduce the risk of an XSS attack. By using CSP, XSS can be blocked entirely (by blocking all in-line scripts) or be reduced to much lower risk.
OWASP provides additional guidance on how to prevent XSS vulnerability with a comprehensive cheat sheet.