The Wild, Wild Web - Securing Your Web Applications
Building web applications at any scale is a difficult task. There are often a myriad of moving parts to enable the simplest functionality, and the need for new features and fixes often outpaces our ability to fix them. This creates the perfect breeding ground for new vulnerabilities to arise, and in this report, we will discuss some of those more frequently encountered by Secora Consulting.
Taking access for granted
Many applications like to consider their users in neat, well-defined categories. Users from Group A can view the data and functionality related to Group A, while users from Group B can view their own functionality and data. In an ideal world, all of this data is segmented and compartmentalised. But this is not always the case.
One of the most common access control vulnerabilities discovered by Secora is that of an Insecure Direct Object Reference (IDOR). These vulnerabilities occur when an application takes some kind of identifier, usually numeric, and uses it to access data.
Think of it as a primary key in a database - the application returns all data for a user where the user ID is equal to the value of 1. The vulnerability occurs when the application does not verify that the user making the request matches up with the data being requested. This can lead to all kinds of information disclosure.
For example, an IDOR vulnerability recently occurred on a Secora web application penetration test that led to the ability to take over user accounts. When a user logged in, a request was made to an endpoint which returned a plethora of user details, including their password in plaintext. While this is an issue in and of itself, the real vulnerability lay in how the request was made.
The endpoint accepted a user ID, which was used to dictate which users' details were being accessed, all without verifying that the user making the request and the user being requested were one and the same. Through this vulnerability, Secora were able to iterate through the possible user IDs, gaining access to all user accounts within the application.
Remediation for this issue can be difficult, given that the root causes for access control issues are so varied. Our general advice would be to verify that a user has the correct access rights before presenting them with any sensitive information or functionality. This includes when using identifiers, as described in the vulnerability above.
Open Sesame
Logins act as the gatekeepers for our web applications. As they are often the only parts of the application the unauthenticated can see, they are an incredibly common and high-value point of interest for attackers.
Secora frequently encounters vulnerabilities in login forms, and they can range from benign to severe.
On the lower end of the spectrum, we have user enumeration vulnerabilities. In most logins, the application will display an error message when an attempted login fails. User enumeration occurs when this error message is just specific enough for an attacker to confirm or deny the existence of a user account.
For example, entering an email that does not exist will often return a message similar to “Sorry, this user does not exist on our system”, while an email that does not exist will return “Incorrect password.”
Resolution to this is quite simple; update the login functionality to return a generic message on a failed login. For example, return “Sorry, either your username or password was incorrect. Please verify your details and try again.” This ambiguity will make it more difficult to enumerate valid system users.
Getting slightly more severe, we have brute-force vulnerabilities. Brute-force attacks occur when attackers are allowed to make unlimited login requests to an application. This effectively allows them to guess a user’s password by compiling a list of well-known passwords and making rapid-fire requests containing the target user's email, and items off of this list of known passwords. Oftentimes, it is not even necessary to compile a list of passwords, as there are dumps of common passwords available freely online.
The solution here is twofold - the most immediate, and most effective solution to these attacks is to implement some kind of timeout mechanism. If a user makes a certain amount of successive failed login attempts, they should be unable to attempt to log in for a set period of time.
The second is more of an all-around application security recommendation; the implementation of a password policy. By forcing users to set strong passwords, the possibility of successfully gaining access to an account decreases significantly. For more information about passwords, refer to our Plight of Passwords blog post.
The most severe login vulnerability encountered by Secora Consulting recently is that of SQL Injection. As described in our Common Web Application Vulnerabilities blog, SQL injection occurs when an application incorporates user input unsafely into a statement. In the case of this application, the username had been incorporated into a SQL statement that presumably appeared as follows:
SELECT * from users where username=(user provided username) and password=(user provided password)
It was possible to insert any user's username followed by the characters ‘--, to force the application to log in without providing the user's password. This was possible as these characters terminate the SQL statement early; the apostrophe (‘) breaks out of the username string, and the two hyphens (--) comment out the rest of the statement.
As such, the application will simply log the user in without verifying their password. This gave Secora access to any account on the application.
The remediation of this issue is, thankfully, quite simple. Most programming languages support parameterised queries. Parameterised queries allow applications to differentiate between the query and the input data by providing a placeholder in the query for inputs. The statement will only execute successfully if it receives the kind of input it expects, be that a number, date or string. Further details on remediating this issue can be found in our Common Web Application Vulnerability blog post, linked above.
How can we help?
Identifying these vulnerabilities without the input of an expert can be difficult. At Secora Consulting, we approach your web applications with the skill and intent of a malicious actor, and the understanding of what’s important to your business.
Our assessments will provide you with peace of mind in how far an attacker can get with your application, and what you can do to stop them.
If you would like further information on our services, contact us or the author directly at d.kennedy@secoraconsulting.com.
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.
