What is the most common Web security vulnerability?

One of the most common questions that I get from my students when I do my penetration test course is what is the most common web security vulnerability?

After years of experience in penetration testing, I had a conviction that this question has a different response depending on the period of time it was asked.

The most common web security vulnerability in the last two years is the Broken access control vulnerability. However, in the period between 2006 and 2012 SQL injection was the number one most common security vulnerability.

In this blog post, I am going to explain in detail what is the broken access control vulnerability and why it is the number one most common vulnerability in the market. In addition, I am going to explain in detail how you can avoid it. Therefore, if you are interested in these subjects, then just keep reading.

What is the broken access control vulnerability?

A broken access control vulnerability happens when the application fails to verify the user permissions before executing a functionality in the app. To better understand this vulnerability here is an example:

Suppose you have an admin functionality in the dashboard interface where the administrator can validate new users manually. After clicking on the validate button of the application’s new users table, the following request is generated:

GET /dashboard/users/342/validate

However, the application source code does not check if the user who is performing this action is an admin or someone else. Therefore, by rather intercepting the traffic going out from the administrator machine or something like that, he can discover the structure of the validation request.

After discovering the structure, all he needs to do then is to send that request to the app and validate any user account he wants.

The broken access control vulnerability happens for three main reasons:

• Permissions were not discussed at the requirement definition step
• Permissions were not clearly defined at the design step
• Developers forget to implement a control

To be honest, it is very rare to find a client that he knows in detail what he wants when he tries to develop a new app, and this is totally normal. However, it is our duty to guide him and ask the right questions to convert his desire into an application that works properly.

The impact of the broken access control vulnerability depends on the functionality that is infected. Therefore, the impact could go from as simple as personal information modification to full control over the hosting server.

Why Broken access control vulnerability is very common?

The broken access control vulnerabilities are very common nowadays because the new development technologies are getting smarter in detecting cyber-attacks. In addition, most modern software development frameworks, start to force developers to use the cybersecurity best practices that drastically reduce the obvious vulnerabilities.

Moreover, a lot of companies start to adopt what we call a DevSecOps pipeline. This pipeline helps companies to accelerate the software development process while reducing the number of obvious vulnerabilities.

This decrease in the number of obvious vulnerabilities comes from the fact that the DevSecOps requirement states that static and dynamic vulnerability scanners should be implemented in the pipeline. In addition, the most obvious vulnerabilities are data-flow-based vulnerabilities. This means that they can easily be discovered by automated tools (contrary to the broken access control vulnerabilities).

However, even modern software development technologies and automated vulnerability scanners are incapable of discovering or preventing broken access control vulnerabilities.

The broken access control vulnerabilities are mainly related to the business logic. Therefore, only the application owner and the developers are capable of understanding where and when a permission control should be performed.

How to avoid a broken access control vulnerability?

To avoid the broken access control vulnerabilities a Secure Development Lifecycle should be adopted by the software development companies. In other words, security aspects should be included in every step of the development process.

At the requirement level, the project manager should ask the client the right questions to better understand the application logic. In addition, he needs to collaborate with an application security expert to advise the client on the security aspect he needs to implement in his app to better secure it.

Defining the security aspects that need to be implemented in the application will help the project manager to better estimate the cost of the application development. These requirements will also help the application architect to better see where he needs to put every security mechanism and why.

After a good requirement definition, the design step becomes clear. At this level, the application architect needs to discuss the security aspect with an application security expert to better understand where he can implement each one of them.

The design step is the most critical step in the whole software development process. A wrong conception of the application component and security aspect may cause some critical vulnerabilities that would cost a lot of money to be fixed. In most cases when the application is very complex, a design-based vulnerability is in general only mitigated and not correctly fixed.

The reason behind this action is that cost of fixing it may be equivalent to or even higher than the development of another application with the same characteristics from scratch.

Conclusion

In my opinion, this question will never have the same response forever. If today the answer was the broken access control vulnerabilities, after few years the answer would definitely change. If we look back in the history of cybersecurity it was always the case. For example between 2013 and 2017 the top ten most common web application vulnerability have changed and more vulnerabilities have started to rise, which prove what I am saying.