Common Web Application Vulnerabilities - Part 2
In a previous blog, we discussed two severe but very common issues that we frequently encounter when performing web application penetration tests. In this blog, we are going to be continuing this series by examining two further vulnerabilities that could negatively affect your web applications and discuss how you can easily remediate these issues.
Cross-Site Request Forgery
Commonly referred to in its acronym form, CSRF is quite a simple vulnerability, and does not require any overly complex exploits or techniques. It requires tricking a user into submitting a form without their knowledge. Say, for example, a web application contains a form that allows users to change their password by providing the value of the new password. When performing this action, the URL could appear to look something like:
www.example.com/changePassword?password=newpassword
As the form on the web page does not require any steps other than providing a new password and clicking submit, an attacker could set up a malicious website that mimics the form and automatically submits a new password for anyone visits. An example of how the URL could look would be:
www.example.com/changePassword?password=attackerchosenpassword
If a user who is already logged into www.example.com visits the malicious site, it will appear, for all intents and purposes, that the request has come from the user. The password change will be executed as normal, because it has been issued by a user with a valid session. As this attack happens in the background, the user will be totally unaware their password has been changed.
The above example is quite simplistic, but CSRF is also possible in forms that require multiple steps.
A real-life example of this occurred on a massive scale with Samy’s Worm. Previously, we discussed cross-site scripting, an attack which allowed users to inject malicious JavaScript into a webpage. This attack made use of one such vulnerability in the MySpace website. Coupled with a lack of CSRF protections, the attacker was able to forcibly update user profiles and store the same payload in the affected profile. This led to the worm propagating from user to user, quickly affecting over a million users.
Remediation
One of the primary defences against CSRF lies in the use of anti-CSRF tokens. These tokens are simply long, random values that are generated every time a user accesses a form. When an anti-CSRF token is in use and a user submits a form, the token is submitted along with the request. If the token is invalid or missing, the request is rejected. There are, of course, caveats that come with this method of protection: the CSRF token has to be generated using a secure random string generator, otherwise an attacker could predict the token and carry out the attack.
However, the positives for implementation of these tokens far outweigh the negatives. The implementations of anti-CSRF in modern frameworks generate secure, random tokens that are excellent defences against request forgery. We recommend the use of anti-CSRF tokens as your first line of defence against Cross-Site Request Forgery.
Anti-CSRF is part of many frameworks, including:
A newer addition to the list of CSRF protections is the Same-Site cookie attribute. This attribute, when attached to a cookie, dictates where and when a browser should send a cookie. This cookie has three possible values:
- Strict: In which a cookie will only be sent with requests to your domain, and will not be sent with any third-party requests
- Lax: In which cookies are sent with GET requests initiated by third-party websites
- None: In which cookies are sent freely
In-line with best practice, we recommend a defence-in-depth approach to security., As such, we’d recommend that you apply multiple defences to mitigate CSRF attacks.
Insecure Direct Object References (IDOR)
Often when designing web applications, developers will use numerical identifiers to access data. This concept makes perfect sense on the backend - to access the first user in your database, you request the user with a user ID of 1. However, an issue arises when the parameter being used to access data is exposed to the end user.
Consider the following example. We have a profile page inside of an authenticated web application that allows users to view their details. These details include Personally Identifiable Information (PII), like their email, address and phone number. The URL of this profile page could look like this:
www.example.com/profile?userID=1
An important point to note here is that the userID is a query parameter, meaning that it’s user controlled. If an IDOR vulnerability is present, an attacker can simply edit this user ID and view the details of the user with the ID of 2, or any other value, exposing the PII of other users.
While this profile page is the most commonly discussed scenario for insecure direct object references, it can occur in any number of contexts. Some common examples include document IDs or names and filenames.
Remediation
The primary fix for IDOR is to implement robust Access Control Lists (ACLs). Every time a user requests access to a resource, the application should verify that they have the correct permissions in place to access that resource.
It is also possible to avoid exposing the user ID to the user altogether. Authenticated requests are sent using a session ID. Session IDs are already associated with the user who is currently logged in. As such, the user controlled parameter can be removed, and the application can instead be designed to retrieve the details of only the user who is authenticated with that session ID.
How can we help?
Identifying these vulnerabilities without an expert’s eyes can be difficult. At Secora Consulting, we offer a range of services that can identify these vulnerabilities, and many more to help protect you from authorised access and breaches. Our web application penetration testing service will constitute a simulated attack on your web application, with the aim of replicating the actions of a malicious actor and identifying vulnerabilities. If you have any questions or want to discuss our services please contact us today.
You can email us at: info@secoraconsulting.com and call us on +353-74-970-7876.
Further Reading:
Our services
All of Secora Consulting's assessments are tailored to our client's needs.
Using our experience, we can help you determine which services are right for you.
