What Is Cross-Site Scripting?

Date First Published: 10th September 2022

Topic: Web Design & Development

Subtopic: Web Development

Article Type: Computer Terms & Definitions

Difficulty Level: 6/10

Learn more about what cross-site scripting is in this article.

Cross-site scripting, also known as XSS, is a type of website vulnerability that allows an attacker to inject malicious client-side scripts into a website for visitors. An example of an XSS attack is an attacker inserting JavaScript code into a form field that users fill out when submitting a review and once submitted, the website performs that action. If it does, it is vulnerable to XSS attacks, causing the script to be stored on the server side and run for every visitor that sees that review, even though the JavaScript code is not visible on that review. Since JavaScript can be used to do almost anything on a website, attackers could also use it for malicious purposes. Instead of directly attacking victims, XSS attacks exploit a vulnerability in a website that victims visit and get it to deliver a malicious script.

Note:

The end user's web browsers have no way of knowing whether the script injected by the attacker should be trusted and will run whatever script they receive. XSS attacks take advantage of the inability of web browsers to differentiate legitimate scripts from malicious scripts.

What Can An Attacker Do By Performing XSS Attacks?

The types of XSS attacks are almost unlimited, but they often include:

• Stealing session cookies from victims in order to gain access to their accounts.
• Redirecting victims to web content controlled by the attacker, such as a phishing page or a page that contains links to malware.
• Creating scripts that loop or overload web browsers and cause them to crash.
• Capturing victim's keystrokes on the website.
• Bypassing security features on the website.
• Defacing a website (e.g. completely rewriting the content of a HTML page using JavaScript).

Types Of XSS Attacks

XSS attacks can come in various types, including:

Stored XSS Attacks

Also known as persistent XSS attacks, these are the most harmful type of XSS attacks. The injected script is permanently stored on the target server, such as in a database, blog, forum post, or comment field, unless the webmaster is aware of the attack and removes it. The injected script then becomes part of the webpage when victims visit it. Each time victims visit the webpage, the injected script will run without any user interaction. These are the same as blind XSS attacks, since the malicious code cannot be seen and the payload is saved on the web server and reflected back to the victim from the backend.

Reflected XSS Attacks

The attacker uses social engineering tactics to trick the victim into unintentionally making a request to the web server that includes the XSS script. Malicious code is added to the end of the URL of a website for a trusted, legitimate website. Each time the victim loads the URL with the XSS script at the end of the URL, the code will be run and reflected inside the web browsers. Attackers will find websites vulnerable to reflected XSS attacks. For example, the victim might receive an email that claims to come from their bank. The email will look something like this:

The first part of the URL looks legitimate and contains the domain name of a trusted website, but the code added to the end of the URL can be malicious. The attacker is hoping that victims don't notice the code at the end of the URL and send their private data to them. Since reflected XSS is not a persistent attack, the attacker must deliver the injected script to each victim.

DOM-based XSS Attacks

A less common and complex type of XSS attack where the malicious script is run by modifying the DOM (Document Object Model) environment in the victim's web browser used by the client-side script so that the script runs in a different way. The client-side script on the page runs differently due to the modifications made in the DOM environment. Because the malicious script is stored within the client's browser environment, the attack cannot be detected through the use of traffic analysis tools. They can only be seen by checking the DOM and client-side scripts at runtime. They are only possible when the client-side script of a web application writes user-provided data to the DOM. When the data is read back from the DOM, the malicious scripts are run.

Self XSS Attacks

This type of XSS attack relies on the attacker using social engineering tactics to trick the victim into running malicious JavaScript code in their web browser. Even though it is not a true XSS vulnerability because it relies on tricking a user into running code rather than a vulnerability in the affected website that allows an attacker to perform an XSS attack, it still has the same risks as a normal XSS vulnerability if properly run.

How To Prevent Cross-Site Scripting?

Webmasters can prevent cross-site scripting by following the guidelines below:

• Properly encoding, escaping, and sanitising submitted data. This will prevent user input from containing HTML, CSS, and JavaScript.
• Use proper escaping and encoding techniques and use existing libraries for escaping. Escape a lesser than symbol (<) with < and a greater than symbol (>) with > to prevent escaping an escape. However, if a user input needs to contain HTML, it cannot be escaped and encoded because it would break valid tags. Instead, a trusted and verified library should be used to parse and clean HTML.
• Not trusting user input. Any user input that is used as part of HTML or JavaScript output has a risk of an XSS attack.
• Never accepting and running JavaScript from an unknown source or JavaScript that they don't understand.
• Only accepting data that they need. For example, if a field is for a surname, only the letters A-Z should be accepted and numbers and special characters should be automatically removed.
• Taking cookie security measures - Websites can also set rules for their handling of cookies that can prevent cookie theft by XSS attacks. For example, a cookie might be restricted to certain IP addresses so that XSS attackers cannot access them. Rules can also be created to block JavaScript from accessing cookies.
• Never placing user-generated data into a <script> or <style> tag name attribute.
• Setting the HttpOnly flag when using cookies. If it is included in part of the HTTP response header, the cookie is inaccessible through the client-side script. Using the HttpOnly flag helps to reduce the risk of client-side scripts accessing the protected cookie.
• Using a CDN, such as Cloudflare that protects sites against cross-site scripting and detects and blocks any attempts to perform an XSS attack. A WAF (Web Application Firewall) provides protection against these types of attacks.

How To Test A Website For Cross-Site Scripting?

A simple way of testing whether a website is vulnerable to cross-site scripting is to add the following code to a form field, such as a comment or forum field, submit it, and see if it returns an alert box with the message 'Cross-Site Scripting'. A form field should not return an alert box or accept any JavaScript. If it does, it is vulnerable to cross-site scripting and an attacker could run any script of their choice. Below is an example of a non-malicious script that can be used to test a website for cross-site scripting.

Web scanning tools can be used to test a website for cross-site scripting vulnerabilities. These work by injecting a script into the website. If the tool is able to inject that type of information into a webpage, then the site is vulnerable to cross-site scripting.