The most common vulnerabilities of web applications in a nutshell
It’s hard to find a company these days that doesn’t have its own website. Often this is not just a static web presence, but includes various dynamic functionalities that work with the database, such as searching, adding comments, sending feedback or user login. Complex web applications containing a larger number of functionalities (e.g. e-shop or internet banking) are also common. Such web applications can be developed to fit the needs of a specific company or some ready-made solutions can be used. However, security is usually not a priority for developers when developing and deploying web applications. This is a common reason for customer data leakage (personal data, passwords, etc.). Some vulnerabilities in web applications can also be exploited under certain conditions to penetrate the internal network or to gain access to other applications.
But how do you know if the web application you are developing or running is secure enough? What could a potential attacker do and what corrective measures should you take? These are the questions that a penetration test focused on web application testing can answer. A penetration test is actually a simulated cyber attack that examines the security of the system under test, in this case a web application. The applications that can be tested are both those accessible from the Internet and those running on an internal network. A penetration test can also vary depending on the amount of information available to ethical hackers. The test can be performed from the perspective of an unauthenticated attacker or from the perspective of an ordinary user. Also, an account with administrator rights may be available to test authorization (to check whether the normal user cannot perform admin actions). The web application penetration testing process is typically based on the OWASP Web Security Testing Guide (current version 4.1). OWASP has also released a well-known list of the most common web application vulnerabilities (OWASP Top Ten). In this article, we will review some of the most common vulnerabilities encountered when testing web applications.
SQL injection
This is a relatively old vulnerability, but it can still be encountered today. We find it most often in older applications or internally developed PHP web applications. It is based on insufficiently handled user inputs (typically POST and GET parameters) that are used in the construction of SQL queries subsequently executed in the database. This way, an attacker is able to modify the database query to obtain an arbitrary stored record. Below is a simple example of a query in which another part of the query (in bold) is inserted instead of the identifier:
SELECT name FROM users WHERE id=‘ 0 ‘ UNION SELECT password FROM users – – ‘
It is often detected in the so-called blind variant, when the requested database content is not directly returned. It must be extracted (guessed) on a character-by-character basis, based on different server responses (different error conditions or response times). Although this is a lengthy process, it can be automated using the SQLmap tool.
The impact of this vulnerability is usually very severe, as it can be used to extract arbitrary data from the database, often modifying its contents or even gaining remote access to the web server command line.
Cross-site scripting
This vulnerability is also caused by untreated user input. Values entered by the user are subsequently inserted into the content of the web page. If this input is properly formatted and contains javascript code, it will be executed in user’s web browser. A simple example that is used in testing and displays a warning window when the code is executed is:
<script>alert(0)</script>
This vulnerability may be present in multiple variants. In the case of the so-called reflected variant, the code that is entered as part of the web address (URL). This vulnerability can be exploited in a phishing attack, where users are sent a link pointing to a legitimate domain, but when the link is opened, a malicious action is performed within the web browser. In this way, an attacker can simply obtain a session cookie to log into the application; perform actions directly within the web application as another user; obtain the content of a page within the application; prompt the user for login credentials; or redirect the user to their own site.
In the case of the stored variant, which is less common, the code is stored on the web page and is executed in the web browser of each visitor to that page. In this case, the attacker does not need to send a modified address via a phishing email. A particularly dangerous (but more difficult to detect) variant may be the so-called blind variant, where the code is launched in the browser of another user, typically an administrator.
Vulnerabilities related to authentication
Several other security vulnerabilities may be associated with logging into web applications. Often, especially on an internal network, default login credentials may be left to log into a web application (admin:admin is a popular combination).
Another login weakness is if the application responds differently when you enter a non-existent username and correct username with an incorrect password. In this way, the attacker can detect multiple usernames in use and then attempt to guess passwords.
The possibility of unrestricted password testing can also be considered a vulnerability of the web application. In fact, password entry can be easily automated and up to thousands different passwords can be checked per minute. Various lists of frequently used passwords are available, or the attacker can create his own list. If user uses a weak password, the attacker can easily gain access to the application.
Authorization flaws
Authorization means verifying that user is authorized to perform a certain action. If this was not considered during development, an ordinary user may be able to perform actions that are reserved only for the application administrator. In some cases, user authorization is not verified at all, and some administrator actions can be performed by a non-logged-in user if they know the address to perform them. The web server also quite often contains various files with potentially sensitive content (e.g. logs or configuration files) that should also not be accessible to non-logged-in users.
Also, flaws that allow access to information of other users with the same authorization level are quite common. Typically, this can be achieved by manipulating the value of the object’s numeric identifier, e.g. if a call with userId=69 displays information about the currently logged in user, changing the numeric identifier may display information about other users.
Path traversal
This is an attack based on the ability to retrieve files from a web server disk outside of the intended directory by manipulating the file name or path to the file. A simple example can be given – if a call to download.php?file=dokument.pdf downloads a specified document, then download.php?file=../../../etc/passwd can download a Linux users configuration file. In this way, the attacker can obtain various configuration files that may contain passwords, web application source code, or other files with sensitive data.
The ability to upload any file
If a web application allows users to upload files, other vulnerabilities may be associated with this. The worst case is if a user can upload a file that is later executed on the server side (e.g. .php or .aspx), which can lead to the attacker taking control of the server. File type authentication is often only implemented on the client side and can be overcome by manipulating the request being sent.
Furthermore, a file with malicious code can be uploaded to the server, which is then downloaded and run by another user of the web application. It is also possible to cause the server to lock up and make the web application unavailable to other users by uploading large files.
Encryption errors
Today, it is standard for web applications to communicate via the secure HTTPS protocol. Otherwise, all information (including login credentials) is sent in readable form and can be obtained by a potential attacker. However, even when encryption is used, communication may not be completely secure, depending on which version of SSL/TLS is used and what encryption algorithms are used.
Cryptographic algorithms are also used when storing passwords, which should not be stored in the database in a readable form but encrypted using a suitable one-way (hashing) function (e.g. Bcrypt or PBKDF2). If the database is compromised, the attacker does not directly obtain the user passwords but only their hashes, from which it is quite difficult to recover the passwords (depending on the hashing function used). Common (fast) hashing functions such as MD5 or SHA are not suitable for this purpose, as an attacker can try billions of possibilities per second while cracking passwords.
So what to do?
The above vulnerabilities are just an example of the most common and severe ones. Web applications are also affected by other categories not covered in this article, such as CSRF, SSRF, XXE, cache poisoning, request smuggling, and deserialization. Often, severe vulnerabilities also consist of multiple sub-steps that individually do not impose a significant security risk.
If you want to check whether the web applications you are using contain weaknesses that could be exploited by a potential attacker, we recommend performing a specialized penetration test by our experts.