What is Cross-Site Scripting vulnerability? How to find and prevent an XSS attack?

In this article, We'll explain a critical web security risk known as Cross-site scripting, its indications, types, and how to prevent an XSS attack.

So let's get started!!

What is cross-site scripting?

Cross-Site Scripting is a type of injection attack which allows an attacker to inject malicious client-side code (executed by victims) that leads to impersonating users to get privileged access to the web application, perform cross-site request forgery attacks to another vulnerable website, redirect victims to an attackers site, download malicious files, etc.

XSS can be chained to other vulnerabilities to get full access to the target system.

Proof of concept (POC):

This is what a basic XSS attack looks like. Yes, just showing an alert with some message whenever someone opens the attacked page is also an example of XSS, because the attacker executes a Javascript code whenever the webpage opens.

XSS is all about adding arbitrary HTML and Javascript code in response if developers do not sanitize users' input properly and encode the HTML characters in the response.

You can start by injecting some innocent HTML payloads like <u>, <br>, <p>, etc. And then use a Javascript function inside HTML tags to confirm an XSS bug. The alert() was used as a proof of concept of an XSS bug for decades but now it's replaced by print(), alert(document.domain) and alert(window.origin).

Type of cross-site scripting vulnerability

1. Reflected XSS - When the XSS payload in request gets reflected immediately in the response, that is reflected XSS attack. It's not permanently saved on the server.

   • Example - Let's say the requested link is sent to the victim by phishing or is embedded in any other website which has a show HTTP parameter which doesn't properly sanitize the user's input and reflects in the response page without proper encoding. So this endpoint is vulnerable to an XSS attack.

   • So, An attacker uses this bug to execute malicious code in the victim's browser.

// REQUEST URL
https://website.com/profile.php?show=><script>print()</script> 
// RESPONSE code has
<script>print()</script>

2. Stored XSS - When the XSS payload is saved to the server (in the database) and executed for every other user accessing the vulnerable web page. The code is saved permanently in the website's database and could be used to create a worm.

   • Example - Let's take an example of a community forum, where everyone can post/comment their thoughts and it is stored permanently on the server. Now even if a user normally visits the page he sees the stored data provided by the server, like questions and answers. An attacker can exploit the XSS bug on the forum to post a malicious XSS payload (while posting a question or an answer), if proper validations are not done for user input. Whenever any user will open that page the malicious script will get executed.

3. DOM-based XSS - When the bug is found in the source code of the vulnerable web page and the files attached to it. The Document Object Model is a convention used to represent and work with objects in an HTML document as well as in other document types.

<script>
     var pos=document.URL.indexOf("context=")+8;
     document.write(document.URL.substring(pos,document.URL.length));
</script>

How to prevent XSS attacks?

Cross-site scripting has been among OWASP top 10 security risk list since 2010 so it is important for developers to write secure code and prevent XSS attacks.

As XSS is an injection vulnerability the key to preventing these attacks is to never trust user input. Also, a non-practical answer would be never to let user-provided data be rendered into a webpage directly without proper checking.

XSS prevention methods:

Following are some of the common methods that will help you prevent unwanted XSS attacks.

1. Use a Web Application Firewall

   1. A firewall immediately blocks certain malicious payloads and tags in HTTP requests.

   2. A firewall can be bypassed in some cases but it could get very frustrating for the attacker.

2. DevSecOps

   1. Tools like Snyk.io can be used.

      1. It finds and automatically fixes vulnerabilities in your code, open source dependencies, containers, and infrastructure as code.

      2. Use Snyk's extensions for your IDE.

      3. Scan for vulnerable docker containers.

3. Validate and sanitize user-provided data

   1. User data should be validated on the front end of sites for correctness (e.g. username, email, domain, and phone number formatting), but it should also always be validated and sanitized on the backend for security.

   2. Depending on the application, you may be able to whitelist alphanumeric characters and blacklist all other characters. However, this solution is not foolproof.

4. HTML Encoding

   1. Whenever you are rendering user-provided data into the body of the document (e.g. with the innerHTML attribute in JavaScript), you should HTML encode the data.

   2. Some examples of HTML encoding are:

      1. " should be replaced by "

      2. > should be replaced by >

      3. < should be replaced by <

      4. & should be replaced by &

      5. ' should be replaced by '

5. Use a security encoding library

   1. For many languages and frameworks, there are security encoding libraries that can help prevent XSS.

   2. Use updated framework versions.

6. Use iframe tags

   1. You can use an iframe tag to prevent stealing cookies/sessions, and privileged access.

   2. Google blogger platform uses iframe tags to render code on different subdomains and prevent XSS on the main web app.

Wrapping Up

Following are the key takeaways:

• XSS is a critical injection vulnerability by which an attacker manipulates server response and executes arbitrary Javascript code in the user's web browser.

• There are 3 types of XSS: Reflected, DOM-based, and stored.

• XSS attacks can be used to download malicious files, do cross-site requests, steal authentication information, hijack sessions, steal sensitive data, and deface websites.

• Prevent XSS by sanitizing user data on the backend, HTML-encode user-provided data that are rendered into the template, and using a security encoding library or WAF.

Frequently Asked Questions

1. Can XSS attacks only occur on certain types of websites?

No, XSS attacks can occur on any website that accepts user input and does not properly sanitize or validate that input.

2. How can I tell if my website has already been attacked by XSS?

To know if your website has been attacked by XSS you cab see strange or unexpected behavior on your website, such as pages redirecting to other sites or user data being modified without permission.

3. Are there any tools or plugins that can help prevent XSS attacks?

Yes, there are many tools and plugins available to prevent XSS attacks. Some popular options include the Content Security Policy (CSP) plugin and the OWASP ESAPI security library.

4. What should I do if I suspect an XSS attack on my website?

If you suspect that your website has been attacked by XSS, the first step is to take your website offline to prevent further damage. You should then review your website's code and logs to determine the extent of the damage and identify the source of the attack. Finally, you should take steps to patch any vulnerabilities and improve your website's security going forward.

Related Links:

• OWASP top 10 - https://owasp.org/www-project-top-ten/

• OWASP cheatsheet - https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

• Portswigger prevention - https://portswigger.net/web-security/cross-site-scripting/preventing

• Article on Reviewing Code for Cross-site scripting Vulnerabilities - https://wiki.owasp.org/index.php/Reviewing_Code_for_Cross-site_scripting

• Portswigger research - https://portswigger.net/research/alert-is-dead-long-live-print