How to Exploit Poor HTTP Usage
In the previous article, we discussed some fundamental concepts associated with the HTTP protocol and risks associated with it if it is used improperly. In this article, we will discuss how poor HTTP usage in applications can be exploited. This article will essentially cover high level details of various possible scenarios that can lead to attacks against applications using HTTP protocol.
Use of HTTP without encryption
There are several applications that use HTTP for communications which involve sensitive data transfers. Sensitive data in transit (as well as on disk) should always be protected using some encryption technique. Use of TLS is a common way for protecting data in transit. When sensitive data is sent over the network without encrypting, attackers can leverage Man In The Middle Attacks (MITM) to see clear text traffic. In addition to it, developers must ensure that sensitive data stored in databases must be protected using appropriate encryption.
Poor input validation
Poor input validation on user supplied data can lead to various attacks on applications. Specifically in web applications, following are various risks that are possible due to missing input validation on user supplied data:
- Remote Command Execution
- SQL Injection
- Cross Site Scripting
- Deserialization Attacks
- XML Injection attacks
To exploit input validation issues, attackers often inject data that is not expected by the application and force it to do things that are useful for an attacker. For example, use a deserialization feature to execute arbitrary system commands on the target server.
Lack of output encoding
When sending user supplied data in HTTP responses and displaying it in the web page, vulnerabilities like Cross Site Scripting(XSS) can be introduced into the applications. While some XSS vulnerabilities can be prevented using input validation, output encoding is often required to properly prevent XSS vulnerabilities.
To exploit Reflected and DOM based Cross Site Scripting vulnerabilities, attackers often need to send a specially crafted malicious URL and trick the victim to access it in his/her browser. In case of Stored Cross Site Scripting vulnerabilities, attackers submit a malicious payload through a vulnerable parameter and it will be stored in a database. The payload will later be executed when another user visits the page.
Lack of principle of least privilege
Consider a web application, which is running with root privileges on the server. If the application has a vulnerability such as Remote Command Execution, the attacker will be able to gain privileged access remotely on the underlying system. Without requiring any efforts to elevate the privileges, an attacker will become root on the underlying server just by exploiting a web application vulnerability.
Lack of CSRF Protection
Cross Site Request Forgery vulnerabilities have a potential to occur wherever the application has features with state changes on the server side. These often occur through features with form submissions. One such For example, submitting a form to change password is a feature, where state change happens. If the developers do not implement CSRF tokens, the form submission request can be forged by an attacker and executed on behalf of the victim leading to password change (for example) without the victim’s knowledge. This attack requires user interaction.
Weak Access controls
There can be scenarios, where application users are associated with predictable values to validate authorization. For example, user 1 is assigned the value 1 to determine if the user is authorized to access a specific resource on the server and user 2 is assigned the value 2 for the same purpose. In such cases, attackers can easily predict the values associated with victim users to access resources on their behalf. Another commonly seen way of determining user’s privileges is via parameters such as admin=false. One can change the value false to true and access the resources as administrators.
Missing security headers
There are several HTTP response headers to instruct browsers on how to react to certain situations of the application. Developers often do not use these headers until a web application goes through a security assessment such as a penetration test. While missing security does not directly pose a security risk, having them will have an additional layer of security.
In this article, we discussed how cryptography is used in applications. It is clear that we interact with applications leveraging cryptography in our daily life and modern day applications surely deal with cryptography in one way or the other. Use of SSL became a common practice in almost all the applications running on the internet. In the next few articles, we will discuss how cryptography can go wrong when used incorrectly in applications.