Let’s talk about a plague occurring in the world of IT cybersecurity, which, in my opinion, receives too little attention. The title of the article may seem like an oxymoron, but let’s see if that’s really the case.
As an incentive, I’ll add that the topic concerns the data processed in the applications you use, including the confidential information of your company and your clients. It’s better if these data don’t leak, right?
According to data from the OWASP organization, Broken Access Control (BAC) vulnerabilities are the most common vulnerablities in applications. This is not a figure of speech; according to the data gathered, it is the most frequently occurring type of vulnerability in applications (web apps, API’s, etc.).
What are BAC vulnerabilities?
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits.
To simplify the matter as much as possible for the purpose of this article, we can assume that we are discussing BAC when user A (whether authenticated or not) can gain unauthorized access to data of user B. The actual definition is much broader, but it is irrelevant for our current discussion. This refers to access that allows at least reading data, but often we are also dealing with the possibility of manipulating user data (editing or deletion).
The simplest example assumes that your application provides an endpoint from which data about a selected user is returned. Let’s say it will be the /user/1 endpoint. This endpoint is called asynchronously through an AJAX request. The user doesn’t even see in the browser that an HTTP request has been sent to this endpoint (this interaction is not visible at the UI level). However, what will happen if someone manually makes the same request but changes the ID parameter from 1 to 2? Will your application check if the currently authenticated user definitely has access to the record with ID 2?
The results of the analysis performed by OWASP fully coincide with my personal observations. During my work nearly every day, I see at least one app that contains a BAC vulnerability and related bugs classes.
Surely many of you have invested a significant amount of time and not a small amount of cash to enhance the security of the applications you develop and those you use as external services.
We have many layers of security, after all. Code scanners (SAST), tools that runs as part of the CI/CD process, container image scanners, DAST scanners, and many other security layers. So how is it possible that so many of these vulnerabilities pass through all these layers and end up on production?
In my opinion, the answer is quite simple, and I hope not too simplistic. None of these tools or security layers understand the context of the applications being analyzed. The tools we use are not able (yet) to comprehend the business logic implemented in the application, and therefore are not able to notice bugs that allow user A to read or manipulate data of user B.
If someone is thinking of a new business, then surely integrating AI with existing vulnerability scanners is a good idea. I suspect that such solutions should appear on the market in some time, but in my opinion, they will not be fire-and-forget tools. Likely, some parameterization will be necessary, at least minimal, so that the AI model will be fully adapted to the tested application.
Until that time it’s worth taking two or three actions:
You can treat this text as a kind of appeal from me, which is meant to draw attention to what I consider to be alarming problems, which for some reason seem to be little noticed.
From this point, I would like to ask you to share this text wherever you can, so as to draw corporate decision-makers’ greater attention to this problem.