Authorization-related vulnerabilities are very common. In this chapter, we’ll look at how to detect and exploit them.
Understand the Concept of Authorization
If you remember in the previous chapter, we defined the terms “authentication” and “authorization”. So, you should now understand the difference. In this chapter, we’re going to focus on the concept of authorization. Here are the definitions again, just as a reminder:
Test Horizontal Access Control
Horizontal access control involves checking that user A cannot access user B’s security perimeter.
In the example.com application we’re testing, this means checking whether a doctor (who has their own patients) can access the medical records of another doctor’s patients.
Another example of horizontal access control is when, as a user of a banking application, you have no access to another user’s accounts.
To check whether horizontal access control is in place (or not), simply test each request with the different profiles provided to you. You’ll then be able to see whether you’re getting the expected result. The system should “block” you when you don’t have permission to access the data.
With gray-box testing, it’s relatively easy to check thoroughly for this type of vulnerability.
If you’re gray-box testing, you’ll use the following method:
Go through the application with each profile (in the case of our healthtech application, as a nurse, doctor, and manager).
Consolidate all the requests into a single list.
Then rerun all the requests with each profile, changing the session cookies if that’s the method used for session persistence.
The black-box approach involves an additional step before this, where we identify—or guess—functions that we don’t necessarily have access to with the profiles provided to us.
Functions that are particularly vulnerable are those that retrieve certain results using a reference in the URL, as in the following example:
http://example.com/patient/8976453
To protect confidentiality in our client’s application, only Doctor A should have access to this patient’s medical records through this URL. If Doctor B has access to this file (associated with Doctor A’s patient), this means that the horizontal access control between doctor profiles is broken!
This vulnerability has even been given a specific name: Insecure Direct Object Reference, or simply IDOR.
Test Vertical Access Control
Vertical access control follows the same principle as horizontal access control, with one key difference, namely that we look for access to functions that are outside the user’s security perimeter or access to additional—potentially more sensitive—data.
For example, we’ll try to see whether the profile for a nurse or a patient care assistant has access to data that is usually restricted to doctors or administrators.
The method is therefore exactly the same, and we can test both at the same time.
And yes, this counts as a failure of vertical access control since it’s possible to access functions that are normally restricted without authorization or authentication!
Use Tools to Test Access Control Effectively
You can test access control manually:
by opening multiple browser sessions with private browsing tabs, for example.
by rerunning requests one by one in the Burp Repeater (but admittedly, this isn’t very practical).
To avoid this, I strongly recommend using the PwnFox plugin in Firefox and the associated Burp extension. They allow you to compartmentalize tabs in Firefox—solving the problem of having multiple private browser sessions open to generate multiple valid cookies—and automatically highlight requests related to a particular profile in Burp.
Let me show you!
Let’s Recap!
Authorization involves verifying that someone has permission to do what they’re asking to do, such as use a particular function.
Horizontal access control refers to access controls in place between two users with the same privilege level, but with different security perimeters. An example in our case would be two doctors who have different patients.
Vertical access control refers to access controls in place between different privilege levels. For example, a nurse does not have access to the same functions and data within a hospital as a doctor.
Access control fails when the system allows a profile to access data outside its defined security perimeter or to access functions not normally accessible with the profile’s privilege level.
That’s all we have to say about technical vulnerabilities on this course! In the next chapter, we’re going to talk about other points that crop up during a pentest. I think it’s important to cover these because they may put the application at risk and would therefore be of interest to the client.
