Cross Site Scripting (XSS)

What is Cross-Site Scripting (XSS)?

Cross-site scripting also known as XSS can be defined as the vulnerability which is caused by the injection of malicious code or scripts into the content of a trusted website. The term was coined by Microsoft.

When the victim opens the infected website, the malicious scripts run and perform the designated tasks resulting in the compromise of the victim’s sensitive data and information. This malicious script runs without any issue because the browsers assume that the trusted website is running the script and not any other external attacker. This allows the attacker to bypass the same origin policy.

An XSS vulnerability is so common that it is included in the OWASP Top 10 vulnerabilities. This vulnerability is generally caused due to improper sanitization of the inputs received from the user which leads to the execution of malicious scripts.

How Does XSS Work?

So, let us see how cross-site scripting works. This vulnerability is exploited by executing malicious JavaScript on the victim’s browser. The malicious JavaScript can be used to steal sensitive information, and compromise any data transfer or any other information entered by the victim. So, let’s see how this malicious JavaScript is injected into the webpage.

Suppose for example there is a shopping website and it is accepting some input such as name or any other input which is not checked or sanitized before processing and that input is used further, that would make it possible for the attacker to insert the JavaScript into that field so that the script is processed directly instead of the expected function it will now perform the action the attacker indented to. We will see the proof of concept of cross-site scripting moving forward in the article which will explain how this XSS is working in real-time.

As mentioned above, an attacker can send a malicious script or payload to a user. These scripts can even rewrite the content of the HTML page. The user's browser does not differentiate between the original and this changed script. Moreover, now the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. This exploit is indeed highly effective as it seems like it is coming from a legitimate website.

XSS Proof of Concept

Although there are multiple payloads available most of the alert() function of JavaScript is used. If the input field is not verifying or sanitizing the input content before using the input it would lead to a popup box appearing in the browser showing the alert. The following example shows how an alert() dialog box appears on the browser.

So, Now we know how an alert() function works, let us see how this is connected to cross-site scripting. If the alert() function is working if inputted through an input field it means the JavaScript is working through that field and now can be used to input the malicious JavaScript which when executed in the victim's computer will perform the desired action of the attacker. For example, the following script can be used to load the malicious JavaScript payload:

In the above example as the query field was XSS attacks susceptible, hence in the above example we used the script tag to specify the browser to run the JavaScript from the source of my malicious website which is hosting the malicious JavaScript.

When executed it will load the modified website from the JavaScript and can be easily used to trick a victim into believing that this is the original website. This example is performed on a website that allows and teaches testing of XSS payloads.

The testing must be performed on only authorized websites, and if performed on any other website, the permission of the owner is a must for pen testing; otherwise, legal action can be taken against the possible attackers.

We have seen how the alert() function is possibly used to check quickly if JavaScript is working or not but the Chrome browser has implemented a feature to prevent cross-origin iframes from calling the alert() function. We can use other payloads to test the same. An easy example would be using the print() function instead, which when called opens the print dialog box suggesting that JavaScript can be used.

Types of XSS Attacks

These cross-site scripting attacks can be further classified into various types depending on the attack methodology. Primarily they can be classified as persistent also called reflected XSS, non-persistent also known as stored XSS, and DOM-based XSS. Some other types of XSS are self-XSS and mutated XSS.

Non-Persistent or Reflected XSS

Reflected XSS is the most basic and commonly found vulnerability. This happens when any type of user input is used by the server and the input is parsed by server-side scripts leading to the execution of the malicious script. But for reflected XSS to work the attacker needs to send the link with the script to the victim, which when clicked and interacted with compromises the user’s data. For example, as seen above the URL contains the script to be executed. The website looks legit but it is executing a malicious piece of code.

Persistent or Stored XSS

Stored XSS is used when the malicious JavaScript is stored on the webpage and whosoever visits the webpage gets affected by it. Stored on the webpage means suppose you have a comment field or any other field which results in posting that information directly on the website and that can be viewed by any user visiting the website. As the user visits the website while loading the page the malicious JavaScript stored on the page loads and performs the malicious action it is intended to. This keeps on working continuously until the script is removed and each user visiting the page is compromised.

DOM – Based XSS

As seen above, the code was somewhere related to server-side code in stored XSS the script was being stored on the server side and shared with the client. But DOM-based XSS can be defined as client-side XSS. This can be classified as a subpart of reflected XSS where the malicious code is not involved with the server but completely works on the client side. It is also exploited by sending URLs with the malicious script to the victim. As soon as the user visits the URL or triggers an action on this page, the browser updates the DOM to include the attacker-provided script or perform any action which the attacker indented to.

Self – XSS

This is not a type of cross-site scripting attack but a sort of social engineering attack which results in the victim executing the malicious scripts or codes into the console of their browsers. For example, you might have seen some websites telling you to run certain scripts so that you may be able to get premium service for free or get a free gift card by running a certain script on the console of the web browser. This should be avoided at any cost as this is most certainly a fraud as well it contains a high chance that the script is malicious and will certainly cause damage. The act of the victim running malicious script in their own browser is termed as Self – XSS.

Mutated XSS

As the name suggests the Mutated XSS is a form of advanced XSS attack in which the script might not look malicious and thus bypassing antivirus, filters, and firewalls, and is harder to detect.

XSS Attack Examples

Some of the XSS attack examples are included in the article. These XSS attacks are only performed on websites that allow users to try and learn about XSS attacks. The following website can be used to try XSS attacks.

Stealing Cookies Using XSS

One of the possible attack examples is stealing cookies or session tokens using XSS. When a vulnerable website is exploited by the stored XSS or the reflected XSS method. For example, the XSS payload is stored in one of the comments and the user triggers it the cookie information stored in the browser is sent to the attacker which can and will be misused. The cookie stores the sensitive information of the victim’s machine. The following script can be used to capture the cookie.

The code grabs the cookie which is then parsed through the escape function so that it can be sent through the HTTP protocol with the GET method.

XSS Examples with Code Snippets

Sometimes a few payloads are filtered out but a lot of payloads are still working we should check them. Some of the payloads are explained below:

1. <script>alert(1)</script> // This payload works where no sanitization checks are available and the JavaScript runs directly into the browser which will pop up an alert depicting the website is vulnerable.
2. foo<script>alert(1)</script> // This payload works when the input field is partially sanitized that is it checks that the input doesn't start with the script tag, so we use a dummy text and after that we use javascript.
3. <IMG SRC=JaVaScRiPt:alert('XSS')> // This payload works when the input field is sanitizing input with strict match comparison which can be bypassed by using these payloads.
4. <body onkeydown body onkeydown="javascript:javascript:alert(1)"></body onkeydown> // This payload will be triggered on pressing the down arrow key by the victim.
5. ">ABC<div style="font-family:'foo'\x3Bx:expression(javascript:alert(1);/*';">DEF // This type of payload easily bypasses normal sanitization checks which check for a specified format expecting the payload.

These are just quite a few examples of how sanitization checks can be bypassed. These payloads need to be changed depending on the requirement of the target website.

What Can XSS Be Used for?

Assuming the XSS attack is successful what exactly the attacker can do:

• They can be used to steal cookies, session token
• They can be used to get login credentials by targeting login fields.
• They can be used to deface the website by changing the DOM structure.
• They can be used to create a path for other browser-related exploits.

Impact of Cross-Site Scripting XSS Vulnerabilities

The impact of cross-site scripting vulnerability depends upon the user’s privilege level and exploits available and the nature of the application.

• Considering that the browser user is not having any administrative permission or sensitive information used or saved. The harm sustained will be little.
• The impact will typically be severe if the affected user has elevated rights within the program, enabling the attacker to gain complete control of the weak application and jeopardize all users and their data.

How to Find and Test for XSS Vulnerabilities?

To find XSS vulnerabilities, we can use various web scanners and payloads available to test our website. XSS scanners automatically check out for the possibility of an XSS attack. Some examples include XSStrike, XSSer, BRuteXSS, Cyclops, BurpSuite vulnerability scanner, etc. These tools can test out the vulnerability and then the report generated can be used to fix the vulnerability. For testing the website manually we have a list of payloads available which can be used to check for XSS vulnerability. These payloads can be accessed from Github's Payload, Portswigger

How to Prevent XSS Attacks?

To reduce the likelihood of a cross-site scripting attack, there is no single effective tactic. Various techniques mentioned below should be used to prevent XSS vulnerability. But this is not an exhaustive list as attack methods are evolving each day.

• Whitelisting rather than blacklisting - Instead of blacklisting keywords for input, we should Use positive or "whitelist" server-side input validation because we can blacklist all-known things but still, the attacker might find some other vulnerability. The best way is to take expected input only from the user.
• Input validation - Input validation on both the client side and server side to rule out any possibility of an XSS attack through modified requests.
• Don't use innerHTML in combination with user input – Using innerHTML to expect input might cause scripts to run and thus result in exploitation.
• Avoid storing sensitive information – As the cookies and session tokens are vulnerable to being stolen they should be encrypted and if possible storing sensitive data should be avoided.
• Keeping the software up to date – Update your software and also ask your users to update their client-side software.
• Using HTTPOnly Flag on cookies – Using this flag prevents the contents of the page from accessing the cookies thus preventing cookie access through the webpage.
• Through Penetration testing - There are various tools for automatic and manual pen testing such as XSStrike, XSSer, BRuteXSS, Cyclops, BurpSuite vulnerability scanner, etc. With the help of these tools, pen testing will result in finding out vulnerabilities, and fixing those will lead to fewer chances of a successful attack.

Post-Hack Actions

In an event of an attack on your website, you should take the following steps to reduce further damage and patch the exploit so that your website is no more exploitable.

The first step would be to find out why and how this attack happened and what are the possible damages already occurred and what damages that can possibly happen. After thoroughly analyzing the same, we need to find the vulnerable code. Cross-site scripting attack means there must have been some vulnerable part through the inputs taken from the user.

After identification, we need to fix the code. After that, you may need to check for any malicious data or scripts left by the attacker to cause further damage and remove them as soon as possible. Expecting that almost everything stored on your computer could have been compromised and would result in further damage, hence update all your credentials. So that even if the attacker has the credentials, they won’t be able to use them. And also, lastly, update all your software so that any other exploits available would be patched.