🚀 CloudSEK has raised $19M Series B1 Round – Powering the Future of Predictive Cybersecurity
Read More
A vulnerable web applications can open the door to your critical assets. Stay protected with CloudSEK BeVigil Enterprise Web App Scanner module.
Schedule a Demo
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.
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:Â Â
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.
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.
Test URL: https://vulnerable.site/somefile.php?file=validpdffile.pdf
Attacking URL: https://vulnerable.site/somefile.php?file=../etc/passwd
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.
Test URL: https://vulneralbe.site/somefile.php?filetocall=https://external.site/somefile.js
Attacking URL: https://vulneralbe.site/somefile.php?filetocall=file:///etc/passwd
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.
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.
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.
An average user looks up topics such as Python or JAVA, while hackers with a malicious intent would submit something like this:
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:
The GET variable named $_GET 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 is not validated. The web application is using it as it is.
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.
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.Â
Discover how CloudSEK's comprehensive takedown services protect your brand from online threats.
How to bypass CAPTCHAs easily using Python and other methods
What is shadow IT and how do you manage shadow IT risks associated with remote work?
Take action now
CloudSEK Platform is a no-code platform that powers our products with predictive threat analytic capabilities.
Digital Risk Protection platform which gives Initial Attack Vector Protection for employees and customers.
Software and Supply chain Monitoring providing Initial Attack Vector Protection for Software Supply Chain risks.
Creates a blueprint of an organization's external attack surface including the core infrastructure and the software components.
Instant Security Score for any Android Mobile App on your phone. Search for any app to get an instant risk score.
min read
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.
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:Â Â
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.
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.
Test URL: https://vulnerable.site/somefile.php?file=validpdffile.pdf
Attacking URL: https://vulnerable.site/somefile.php?file=../etc/passwd
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.
Test URL: https://vulneralbe.site/somefile.php?filetocall=https://external.site/somefile.js
Attacking URL: https://vulneralbe.site/somefile.php?filetocall=file:///etc/passwd
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.
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.
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.
An average user looks up topics such as Python or JAVA, while hackers with a malicious intent would submit something like this:
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:
The GET variable named $_GET 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 is not validated. The web application is using it as it is.
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.
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.Â