What is cross-site scripting?
Cross-site scripting (XSS) is an exploit where the attacker attaches code onto a legitimate website that will execute when the victim loads the website. 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?
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?
How can an attacker use cross-site scripting to cause harm?
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.
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. The Cloudflare WAF offers turnkey installation and protects web applications from cross-site scripting, DDoS attacks, SQL injection, and other common threats.