What is it

BAC: Broken Access Control

Broken Access Control is exactly as it states. It can manifest itself in both horizontal and vertical privilege escalation.

When we speak about privilege escalation, we are talking about the ability to execute functionality we are not supposed to be able to execute. But what exactly do we mean by verticale and horizontal?

If that functionality is something we can execute, but not with the parameters we feed into it, we are talking about horizontal priviledge escalation. A good example of this would be IDORs. If on the other hand, we can not execute that functionality at all, not even with our own data, we are talking about Verticale priviledge escalation.

We can also give a few examples of this behaviour but first we need to define some properties. To speak of BAC, we need to have the following conditions met:

Some examples:

Attack strategy

Again we can test this manually or we can test this semi automatic. I do not believe robots have the ability to execute complex stateful scenario’s where often sequential steps rely on previous input.

Manually

To test for BAC manually, we have several options at our disposal. One of the most powerful tools we have is javascript and the developer console of the browser.

JavaScript files will contain functions that can be executed. One common tactic developers use to protect their programs is to simply disable the UI elements. This means that the javascript functions might still be executable. If that is the case, say for example if we can not click on the UI element to open the invoices BUT we might be able to execute the javascript function which prints the invoice details, we have a BAC on our hands.

You may have noticed this requires some knowledge of how your target works because you need to know which levels of authorisation exist and what those types of accounts can and can’t do. You will also need to be able to recognise what the different javascript functions might do.