A5: Broken Access Control 2017 OWASP

What is access control?

Access control as the name implies is there to grant or restrict rights to certain users on the application. If the access control is implemented the right way a regular user should not be able to request and view documents that are only visible for administrators. If an attacker finds a way to do this then he successfully bypasses the access control. However, access control doesn’t restrain itself only to users. It can also be found when it comes to processes or devices.

The 3 main types of access control

• Administrative access control

In this instance we are talking about the access controls put in place which are defined to enforce the overall security policy. The main focus lies on two topics: The personnel and the business practices. A few examples would be policies, hiring procedures or background checks.

• Technical access control

Technical, also called logical access controls are the hardware and software based access controls which are used to create an extra layer of protection for access control systems or resources from unauthorized use. Typical ways of implementation include things like passwords, yubi keys, smart cards, protocols or firewalls. Those help tremendously in increasing the API security.

• Physical access control

Those are the types of access controls that have their focus on the non technical side of things. For instance video cameras, security guards or locks that restrict access to certain environments.

How is access control carried out

Typically there are three different types of access control for files -> read only, readable and writable and or executable. However those can vary depending on the type of file one is dealing with. They should be carried out through the system and the standard operating procedure. The enforcement should follow a certain multi step protocol:

• First of all there would be the subject ID which defines who requests access.
• Next up would be an identity check of the person who is making the request which is done through some sort of authentication.
• After the authentication was successful the request needs to be checked against the access control list to make sure the user has the rights to access whatever he is requesting and to determine the level of access he will be granted.
• Lastly there should always be audits in place to check for flaws and or weaknesses in the system so that no one can bypass the access control.

Understanding broken access control 

To properly take advantage of this vulnerability, we need to first realise what it means to have access control in the first place. After all we’d need to know how something works before we can break it and the same goes for access control. There are various different possibilities for a server to provide or deny rights to request a certain resource. This can be session cookie or JWT token for example. When the user requests access to a resource, the server first checks if the user can access that resource before executing it. This can be via a GET call but other HTTP methods such as POST/PUT/DELETE are also possible. The problem arises when we start realising that developers have to secure every single endpoint with every possible HTTP method. So for a broken access control issue to occur we need to first have access control and implement it well. It’s essential to realize there are other ways of access control such as only serving content to the user if they are on the internal network.

When does access control become vulnerable

Vulnerabilities appear when a user is able to successfully request access to something he usually shouldn’t have access to. Oftentimes this is found when the authorization is not implemented properly. A typical example would be a certain endpoint on a website that throws a 403 forbidden error which is then bypassed by adding an X-Forwarded-For: “127.0.0.1” header. Another example would be old directories from a development phase that haven’t been deleted or properly protected. Sometimes users also store their passwords in plain text on their computer now if the computer gets compromised the attacker would be able to gain access to other systems, portals, etc. However sometimes the passwords are just too weak and could be guessed which also leads to broken access control. From this and the previous chapter we can conclude that a broken access control issue occurs - OWASP top 10 vulnerabilities:

• On any HTTP method so we need to either disallow unwanted HTTP methods or secure them
• On either an ObjectID or on a userID basis
• Either by directly talking to a server ourselves or having the server perform an action on our part such as a broken access control through import functionality
• Items that are only served on the internal network only use the x-forwarded-for header as a check and nothing else
• Even when UUIDs are being used instead of IDs if you expose endpoints that list those UUIDs

How to detect broken access control

In order to detect them one should review the access policies. If they don’t exist in the first place then the company is very likely to be vulnerable. Those policies should enforce access controls together with documentation that highlights the guidelines and best practices. Code review and penetration aid in the detection of possible access control flaws and should be regularly conducted in order to find these flaws before an attacker does. Thoroughly conducted audits with the goal to check if the policies and controls in place hold up should also be carried out.

Examples for broken access control

• CVE-2019-15511

The software GOG Galaxy below the version 1.2.60 has a BAC flaw which allows for a local privilege escalation. The software runs with SYSTEM privileges and does not restrict commands which are sent over a local TCP connection. However this alone does not result in command execution. But the application has a predefined set of privileged commands that it can execute which would allow an attacker to take over any file. So this way a malicious actor can escalate his privileges.

https://nvd.nist.gov/vuln/detail/CVE-2019-15511

• CVE-2019-14273

If a file with restricted access is embedded within some content through links or images then users who normally don’t have access to them can view those files straight away. This could lead to the leakage of delicate information.

https://nvd.nist.gov/vuln/detail/CVE-2019-14273

‍

How to prevent broken access control

The most obvious step is to check permissions and make sure they are on point. However this needs to be done thoroughly and for each and every file. Only personnel who need to edit certain files should be granted write access, a good way to implement this is through the principle of least privilege. On restricted pages client side caching should be disabled as it may allow others to re-access those sites. Also one should never rely on so called presentational access controls. The absence of a button which takes one to a restricted page is just security through obscurity and probably won’t hold up against any serious attacker. So those sensible pages should always be locked behind authentication.