What makes web applications an easy target for hackers?

 

Web applications form a major part of an organization’s attack surface and according to Verizon’s 2020 Data Breach Investigation Report, web applications are the single most significant cause for data breaches. Web application attacks account for 43% of all successful data breaches. 

These websites contain several vulnerabilities such as Remote Code Execution (RCE), Server-Side Request Forgery (SSRF), Local File Inclusion (LFI), Server Side Template Injection (SSTI), and more. Some of these vulnerabilities allow intrusion of corporate networks. These vulnerabilities are the result of mistakes that programmers make. Developers trust and hope that their applications will end up in the right hands, which often turns out to be the biggest mistake they ever made. 

In this multi-part series about web apps, we explore the common mistakes and threats affecting web applications, as well as point out factors regarding applications that appeal to threat actors. The first part of this multi-part series focuses on web app user input and the pitfalls of not validating or sanitizing it. The article also sheds a light on the steps one can take to prevent application attacks and reduce vulnerabilities.

 

Rule #1: Never trust user input

While developing an application, web programmers should refrain from accepting data from users and in fact should presume all data is bad until proven otherwise. This is how threat actors leverage different vulnerabilities:  

 

Remote Code Execution

In an instance where the Image File Upload functionality of an application uploads the filename and contents onto a server, the server processes it further. However, if the application doesn’t validate user inputs, it permits the attacker to upload the server side language extension file, such as the .php file. This further allows the attacker to execute OS commands on the server.

 

Local File Inclusion 

Similarly, when web applications are coded poorly, hackers can inject local files into the include statements. For instance, an attacker can exploit the Local File Inclusion vulnerability by changing the path of a PDF file with that of another sensitive file such as passwd. If the application doesn’t validate the input, the attacker can simply read internal server files.

 

Example

Test URL: https://vulnerable.site/somefile.php?file=validpdffile.pdf

To 

Attacking URL: https://vulnerable.site/somefile.php?file=../etc/passwd

 

Server Side Request Forgery

In an attack that exploits this vulnerability hackers gain partial or complete access to the requests sent by the application, to abuse a functionality. This allows them to make the server-side application to configure HTTP requests that lead to malicious domains of the attacker’s choice. If the website does not validate the user input, the hacker can access internal server files and more.

 

Example

Test URL: https://vulneralbe.site/somefile.php?filetocall=https://external.site/somefile.js

To

Attacking URL: https://vulneralbe.site/somefile.php?filetocall=file:///etc/passwd

 

SQL Injection

This vulnerability allows hackers to insert or inject a query into an entry field, so as to execute malicious SQL statements. This enables actors to retrieve sensitive data from the database evading any security measures.

 

Example

Test URL:https://targetsite.com/somefile.php?id=2

However, if the web application does not validate the user input, the attacker can submit something like this:

Attacking URL: https://targetsite.com/somefile.php?id=’ OR ‘1’=’1’–+

From the above instances and scenarios it is clear that if the user input is not properly validated or sanitized, most web app vulnerabilities can be exploited, eventually leading to breaches and data loss.

 

How can you reduce vulnerabilities and prevent attacks

Let us look at the issue at hand before we suggest a solution. The following instance summarizes the problem:

This is a test application that accepts the user input and returns results based on it.

Web App normal search

An average user looks up topics such as Python or JAVA, while hackers with a malicious intent would submit something like this:

Web App unvalidated

There are a number of symbols we can inject, such as a single quote(‘), double quotes (“), open, closed angle brackets (<>), equals to (=), and open, closed brackets [()], and if the web application accepts these without validating them, attackers can used this as a weapon to steal session cookies of other people, by using advanced XSS payloads (Cross-Site scripting payloads).

Now, let’s try to understand the logic of the code:

Web App coding gone bad

The GET variable named $_GET[‘vulnparam’] at the TOP accepts the user input, which then allows the webapp to proceed with that variable name $vulparam. As you may have noticed, the user input variable $_GET[‘vulnparam’] is not validated. The web application is using it as it is.

The right way to code

In order to validate the user input first, we use the htmlentities() function that converts characters and symbols to HTML entities. This helps to prevent Cross-site Scripting (XSS) attacks and the web app proceeds further with the encoded user input.

 

Summary

Almost every OWASP Web Vulnerability is exploited in real world websites as web applications fail to properly validate user input, before processing it. Therefore, it is important that app developers and security testers regularly collaborate with each other. Once the programmer has built a particular feature or an app, security testers can test it before deploying them on the prod servers. Ultimately, this will save them a lot of time and prevent any data loss that could have resulted from exploitation. 

Utkarsh Agarwal
Cyber Security Analyst, who also plays a significant role in the POC team, at CloudSEK.
This is Alt
Cyber Intelligence Editor, CloudSEK
Total Posts: 2
She is a Cyber Intelligence Editor at CloudSEK. A lawyer by training and a content writer by choice, she prefers to write on matters concerning current affairs, security, and human frailty.
×
Utkarsh Agarwal
Cyber Security Analyst, who also plays a significant role in the POC team, at CloudSEK.
Latest Posts
  • Why attackers can't resist Android apps
CloudSEK is continuously analyzing the Surface, Deep and Dark web to identify the emerging threat indicators and trends. For real-time threats emerging against your organization or industry, you can request a demo for free.