Let’s take a scenario like so:

I have a web application that allows people to buy software I created – after a person has bought the software, an account must be made. After the individual creates an account, the software can be downloaded. After the purchase, the customer is also granted access to some resources available exclusively to customers. Should any issues arise, support tickets can be lodged.

Now imagine you’re an attacker who wants to gain access to the resources available only to customers. What would you do?

In order to gain unauthorized access, an attacker could utilize social engineering, and indeed, the nefarious party could also find flaws, compromise the system and gain access that way. Or, in this case, the attacker could simply navigate to a URL..

In case it isn’t already clear, having a page that should be available only to authenticated members available to everyone is not exactly ideal. The above page is vulnerable to the fifth vulnerability in the OWASP 2017 list – broken access control.

What is broken access control?

Defining broken access control is pretty simple – the title is pretty much self explanatory. A web application is vulnerable to broken access control if someone is able to access resources that should not be accessible to them.

A web application might not seem to be vulnerable to such a vulnerability at first glance (i.e it might have a page that requires you to log in to access another page), but, upon manual inspection, such a vulnerability can be noticed in an instant – simply navigate to a page that should require you to be authenticated in order to access it, and, if you are able to access the page while not authenticated, the website is vulnerable.

Is it dangerous?

The consequences of such a vulnerability being exploited may be severe. It may leave a medium impact. In fact, such a vulnerability may even be next to insignificant. It all depends on your web application and what functionality it has. If your web application only stores images, the impact of broken access control could be low. However, if your web application allows users to buy items or stores personal information, the ramifications could be way, way more serious.

How do I determine if my web application is vulnerable?

In short, your web application is vulnerable to such a flaw if users can access data that should not be accessible to them. In order to determine if your web application is vulnerable, you could simply log in to your web application, visit pages that require authentication in order to be accessed, log out, and pay a visit to those pages once again. If you can access those pages when logged out, you have got a problem – your website is vulnerable to broken access control.

Now that I covered how you can determine if your page is vulnerable to broken access control, I should probably show you how it all looks code-wise. Here’s a vulnerable page:

The vulnerability here should be pretty easy to spot – anyone can access the page because there is no authentication checks in place.

Mitigation

In order to mitigate broken access control, a principle of denying by default could be applied. Broken access control can be patched in other ways, too, have a look at how I accomplished it:

The above page is no longer vulnerable because the code tells the page that if a session named “User” is not set, it should redirect to the login page. That’s it. It’s that simple. One more thing that should be noted is that you should always exit after utilizing header() in PHP. If you do not, the script can still execute even after the redirect.

Summary

Broken access control is a fundamentally basic security risk yet its inclusion in the 2017 OWASP Top 10 tells us that such a flaw is indeed very serious and that it needs more attention. In order to avoid such a risk being introduced into your web application in the first place, utilize the principle of denying by default, or, if you do not wish to do that, check if a session is set after defining it upon login – such a risk is not hard to avoid.