During their penetration tests (pentests), our security analysts at usd HeroLab repeatedly uncover vulnerabilities that pose significant risks to corporate security. They increasingly encounter the same vulnerabilities. Our blog series "Top 3 Vulnerabilities" presents them and provides tips on how to avoid them - for #moresecurity across all IT assets.
Today we look at the three most common security-critical vulnerabilities that our analysts have identified in Pentests of Web Applications in recent years.
Why pentest web applications?
Web applications are at the heart of many modern workflows and often process sensitive data. This can include personal information, health data, payment data or company secrets. Due to their high relevance, these web applications require the best possible protection. In our pentests, we regularly discover critical vulnerabilities in web applications despite increased security awareness.
Broken Access Control / Sensitive Data Disclosure
In the OWASP Top 10, an overview of the most frequently occurring vulnerabilities in web applications, "Broken Access Control" has been in first place since 2021 (https://owasp.org/www-project-top-ten/). We also find that this type of vulnerability occurs in a large number of our pentests.
The vulnerability occurs when the authentication or authorization of an application has been insecurely developed or configured, allowing access to sensitive resources. Attackers can exploit this to gain access to information that they should not be able to view. Therefore, a common consequence of Broken Access Control is the disclosure of sensitive information.
Broken Access Control covers various dimensions. During a pentest, the analyst should check whether functions or resources can be accessed without a valid session. This simulates unauthenticated attackers. In addition, a large number of web applications offer a complex role profile and/or multi-client model. It is important to check whether users of a role also have access to resources of other roles or clients.
Reasons for frequent occurrence of this vulnerability:
- Security scanners rarely detect this vulnerability
- Insufficient security training for developers or administrators - Time pressure during development
- Lack of review of security guidelines
- Lack of updating of security guidelines
- Complex application logic
To illustrate this scenario, we present a real-life example of unwanted file access for unauthorized third parties. An Apache web server that is responsible for processing requests is affected. To protect directories from unauthorized access, an ".htpasswd" file is created in the main directory of the web server and the corresponding users are defined there.
Due to a configuration error in the Apache web server, access to this file was possible without authentication or authorization. The file contained a user name and the hash of the password, which could then be cracked, thus revealing the plain text password. This sensitive information could be used to access the protected area of the web application.
Security tip:
We recommend preventing access to sensitive functions or information by default. Necessary access should be explicitly enabled by a global access control. Every function should evaluate the user's access rights. The easiest way to do this is to use frameworks, as access control is a typical functionality within web applications.
Cross-Site-Scripting
Cross-site scripting (XSS) is another security vulnerability that we find in a large number of web applications. This vulnerability occurs in web applications when user input is not properly validated or filtered. XSS allows attackers to inject malicious JavaScript code into trusted websites. The user's browser then executes this code.
Examples of the effects of XSS are:
- Theft of user data
- Session hijacking
- Monitoring of keystrokes
- Manipulation of web content
- Redirection to malicious websites
- Reputational damage to the website operator
Cross-site scripting vulnerabilities are usually divided into three categories:
Reflected XSS occurs when the malicious code is inserted into the URL and the server then embeds the code in the HTTP response.
Stored XSS occurs when the malicious code is stored on the server, typically in a database, and then served to all users each time the corresponding page is requested.
DOM-based XSS refers to attacks in which the malicious code is executed directly in the DOM (Document Object Model) of the page without being sent to the server. The vulnerability is often located in client-side JavaScript and is exploited by manipulating it.
To illustrate this, we show a stored XSS vulnerability that we found with our tool FlowMate (https://github.com/usdAG/FlowMate) in admidio 4.2.9. You can edit your own profile in admidio. This is done using a form with fields for city, country and email address, among others. The following excerpt shows the vulnerable form.
HTML tag attributes can be embedded within the "City" input field. As shown in the screenshot, a typical XSS payload can be inserted in this field. Due to the lack of processing for the quotation marks, this input would result in the following HTML the next time the form is displayed:
<div class="col-sm-9">
<input type="text" name="usf-5" id="usf-5" value="test" onfocus="alert(document.domain);" autofocus="" a="a" class="form-control" maxlength="100">
</div>As can be seen in the HTML, an "onfocus" event is entered. When the event is executed, the embedded JavaScript is executed. In our case, "alert(document.domain)" displays the domain within a pop-up window. A further HTML attribute is then inserted, which causes this input field to be focused by the browser by default. Effectively, this payload always leads to the JavaScript being executed as soon as users are shown this form.
If an administrator visits the form, the embedded JavaScript is now executed. This results in a pop-up window being displayed. The following screenshot shows the pop-up window.
Security tip:
To prevent XSS vulnerabilities, it is important to properly encode all user input before it is inserted into the web application. The encoding must be based on the context in which the data is inserted so that it cannot be interpreted by the browser as website code.
File upload RCE
Many web applications offer functionalities for uploading files such as images or other documents. These functionalities represent a particularly interesting attack vector for attackers. Uploading files can create the potential for remote code execution (RCE) if the validation is insufficient. Attackers can exploit this vulnerability to inject malicious code in the form of an uploaded file and then execute it on the server.
During one of our pentests, it was possible to upload files within the CKEditor. The uploaded files are then stored in the main directory of the web application. If these files can then be retrieved, it is possible for the uploaded files to be interpreted and executed as code by the web server. The following screenshot shows an example of HTTP communication for uploading a PHP file. The code within the file causes the "whoami" command to be executed on the underlying operating system.
After the file has been uploaded, its execution can be triggered via another HTTP request. The following excerpt illustrates this. The uploaded file name is specified within the request. The web server calls up the file and executes it. In the HTTP response, "nt authority\uusr" is displayed, which is therefore the user executing the web server process.
This shows that users with access to the CKEditor are able to upload files without restrictions. This in turn enables them to execute any commands on the underlying server.
Overall, uploading unvalidated files with subsequent execution is a serious security vulnerability that can have a serious impact on the security of a web application.
Security tip:
It is important to implement robust security measures to avoid this vulnerability. This includes careful validation and filtering of uploaded files, as well as the use of anti-virus software and other security mechanisms to protect against malicious code.
Please note that there may be many other vulnerabilities in addition to those mentioned. As every web application has different functions, new threats can also arise. A pentest can provide clarity and help you to effectively protect the data of your company, your customers and your employees.
Would you like to comprehensively examine your web application and identify potential gateways for attackers? Contact us, we will be happy to help you.
