A cross-sites scripting attack tricks a web browser into running malicious code.
Cross-site scripting (XSS) is an exploit where the attacker attaches code to a legitimate website viewed by the unbeknownst visitor.
That malicious code can be inserted in several ways. Most popularly, it is either added to the end of a url or posted directly onto a page that displays user-generated content. In more technical terms, cross-site scripting is a client-side code injection attack.
What is client-side code?
Client-side code is JavaScript code that runs on a user’s machine. In terms of websites, client-side code is typically code that is executed by the web browser after the browser loads a web page. This is in contrast to server-side code, which is executed on the host’s web server. Client-side code is very useful with interactive webpages; interactive content runs faster and more reliably since the user’s computer doesn’t have to communicate with the web server every time there is an interaction. Browser-based games are one popular platform for client-side code, since the client-side code can ensure the game runs smoothly regardless of connectivity issues.
Code that runs client side is very popular in modern web development and is utilized on most modern websites. Since cross-site code is a staple of the modern web, cross-site scripting has become one of the most frequently reported cyber-security vulnerabilities, and cross-site scripting attacks have hit major sites such as YouTube, Facebook, and Twitter.
What is an example of cross-site scripting?
One useful example of cross-site scripting attacks is commonly seen on websites that have unvalidated comment forums. In this case, an attacker will post a comment consisting of executable code wrapped in ‘<script></script>’ tags. These tags tell a web browser to interpret everything between the tags as JavaScript code. Once that comment is on the page, when any other user loads that website, the malicious code between the script tags will be executed by their web browser, and they will become a victim of the attack.
How can an attacker use cross-site scripting to cause harm?
JavaScript cross-site scripting attacks are popular because JavaScript has access to some sensitive data that can be used for identity theft and other malicious purposes. For example, JavaScript has access to cookies*, and an attacker could use an XSS attack to steal a user’s cookies and impersonate them online. JavaScript can also create HTTP requests, which can be used to send data (such as stolen cookies) back to the attacker. Additionally, client-side JavaScript can also help an attacker gain access to APIs that contain geolocation coordinates, webcam data, and other sensitive information.
A typical cross-site scripting attack flow is as follows:
- The victim loads a webpage and the malicious code copies the user’s cookies
- The code then sends an HTTP request to an attacker’s webserver with the stolen cookies in the body of the request.
- The attacker can then use those cookies to impersonate the user on that website for the purpose of a social engineering attack or even to access bank account numbers or other sensitive data.
*Cookies are temporary login credentials saved on a user’s computer. For example when a user logs onto a site like Facebook, the site gives them a cookie so that if they close the browser window and go back to Facebook later that day, they are automatically authenticated by the cookie and won’t need to login again.
What are the different types of cross-site scripting?
The two most popular types of cross-site scripting attacks are reflected cross-site scripting and persistent cross-site scripting.
Reflected cross-site scripting
This is the most commonly seen cross-site scripting attack. With a reflected attack, malicious code is added onto the end of the url of a website; often this will be a legitimate, trusted website. When the victim loads this link in their web browser, the browser will execute the code injected into the url. The attacker usually uses some form of social engineering to trick the victim into clicking on the link.
For example, a user might receive a legitimate-looking email that claims to come from their bank. The email will ask them to take some action on the bank’s website, and provide a link. The link may end up looking something like this:
http://legitamite-bank.com/index.php?user=<script>here is some bad code!</script>Although the first part of the url looks safe and contains the domain of a trusted website, the code injected onto the end of the url can be malicious.
Persistent cross-site scripting
This happens on sites that let users post content that other users will see, such as a comments forum or social media site, for example. If the site doesn’t properly validate the inputs for user-generated content, an attacker can insert code that other users’ browsers will execute when the page loads. For example an attacker might go to an online dating site might put something like this in their profile:
"Hi! My name is Dave, I enjoy long walks on the beach and <script>malicious code here</script>"Any user that tries to access Dave’s profile will become a victim to Dave’s persistent cross-site scripting attack.
How to prevent cross-site scripting
There is no single strategy for mitigating cross-site scripting, and different types of web applications require different levels of protection. A number of protective measures can be taken, below we will outline a few.
If possible, avoiding HTML in inputs – One very effective way to avoid persistent cross-site scripting attacks is to prevent users from posting HTML into form inputs. There are other options which let users create rich content without the use of HTML, such as markdown and WYSIWYG editors.
Validating inputs – Validation means implementing rules that prevent a user from posting data into a form that doesn’t meet certain criteria. For example, an input that asks for the user’s “Last Name” should have validation rules that only let the user submit data consisting of alphanumeric characters. Validation rules can also be set to reject any tags or characters commonly used in cross-site scripting, such as “<script>” tags.
Sanitizing data – Sanitizing data is similar to validation, but it happens after the data has already been posted to the web server, yet still before it is displayed to another user. There are several online tools that can sanitize HTML and filter out any malicious code injections.
Taking cookie security measures – Web applications can also set special rules for their cookie handling that can mitigate cookie-theft via cross-site scripting attacks. Cookies can be tied to particular IP addresses so that cross-site scripting attackers cannot access them. Additionally, rules can be created to block JavaScript from accessing cookies altogether.
Setting WAF rules – A WAF can also be configured to enforce rules which will prevent reflected cross-site scripting. These WAF rules employ strategies that will block strange requests to the server, including cross-site scripting attacks.