Mitigation

Welcome to the third and last part of Broken Access Control session. In this part, we will discuss broken access control mitigation. We will start discussing what makes an application vulnerable, and then we will hunt OWASP Juice Shop vulnerable source code. Before closing this session, we will discuss how to avoid such vulnerabilities. In our target application, managing customer feedback are actions reserved to administrators. We saw that directly requesting specific routes or manipulating data to be verb, we could execute those same actions. Some applications address that because addresses to access specific pages are not known. They are reserved to those who knows the URL.

Security through obscurity is a misconception, and there are plenty of word lists and automatic tools to help uncovering such hidden addresses. Misconfigured cross origin resource sharing policies may allow access to resources from unauthorized origins. In such situations, attackers who are able to drive victims to visit the website under their control will be able to interact with the application behind the scene and on victim’s behalf. If untrusted data, just as well is from cookies or even fields, drive access control decisions, then the application is likely vulnerable. Let’s review Juice Shop vulnerable source code. From project’s page, we will jump to the GitHub repo.

First, we want to see how the feedback’s API endpoint is set up in the server.js file.

Regardless, the HTTP verb, when the request is made to the feedback’s API endpoint with an identifier, the isAuthorized method of the Insecurity library is called. Let’s check its implementation.

isAuthorized is a simple function that calls the expressJWT function.

The expressJWT function is provided by the npm expressJWT package.

According to the documentation, this package does nothing else than validate the JSON web token. No ownership validation is performed upon the requested resources, and this is why we were able to access and delete other users feedback.

Let’s see if there’s something else in the server.js file.

Requests to create, retrieve, and delete feedback records are passed directly to the Feedback model. Let’s see its implementation.

The implementation has no additional access control validations.

Let’s discuss how to prevent this type of loss.

You should always follow the principle of least privilege. In particular, abstraction layer of a computing environment, every module, such as a user, must be able to access only the information and resources that are necessary for its legitimate purpose. Deny access by default except for public resources. Building and using a centralized access control mechanism will make your life easier not only managing privileges, but also discovering and fixing bugs. Log access control failures with enough details and alert the administrators so that they can act in a timely fashion when required. Implement rate limiting to minimize the amount of data exposed by a single endpoint in case of a broken access control issue. In our next session, we will discuss security misconfiguration.

Until then, take your time to carefully read the Broken Access Control section of OWASP Top 10.