Stay in touch

Application security insights and invitations to exclusive events in your inbox


Your data will stay confidential Private and Confidential

OWASP Top 10: Broken Access Control, the risks and solutions

Thursday, July 12, 2018 By

Broken Access Control is #5 in the current OWASP Top Ten Most Critical Web Application Security Risks. It should be viewed in conjunction with Broken Authentication, currently the #2 risk.


OWASP Top 10: Broken Access Control, the risks and solutions

In 2012, the South Carolina Department of Revenue suffered a huge data breach. A vast amount of taxpayer data was stolen, including 3.6 million social security numbers. The breach appears to have been made possible by a simple spear phishing attack. The government system was theoretically secure against unauthorised users, but only up to the point the attackers could breach or bypass the user authentication.

From then onward, there was insufficient internal access control [CWE-284] to prevent the ‘authenticated’ attackers accessing and stealing the sensitive IRS data.

Generally speaking, authentication is considered to be part of the overall discipline of access control. In the OWASP top ten risks, however, authentication (OWASP #2) concerns proving user identity, while access control (OWASP #5) concerns what the user (authenticated or otherwise) can access on the system.


What is the Broken Access Control risk?

Broken access control can be exploited by very sophisticated attacks, or very simple ones. Such attacks can range from the harvesting of user credentials with the help of specialist tools like Mimikatz (enabling lateral movement within a compromised network), to simple URL experimentation and manipulation. Essentially, broken access controls occur whenever users who are not authorised to access files or functionality can access them anyway.

A basic method of exploiting access control flaws in an application's code is known as forced browsing. Consider the hypothetical website http://web_net_thing.com. This website normally authenticates its users and administrators, and only delivers the appropriate pages after authentication. If attackers know the appropriate URL, they can simply enter in their browser:

http://web_net_thing.com/user_page
or
http://website.com/admin_page

A properly secured website would simply redirect the user to the login page. If, however, this method allows access to those pages, it is a form of broken access control. Even a rudimentary attack like this can cause alarming damage if user data is stored improperly.

http://website.com/password_list.txt

could give an attacker direct access to the cleartext passwords for the website's users.

This specific result would require the website's security to be spectacularly bungled in multiple areas – but forced browsing vulnerabilities are still a problem for large organisations handling sensitive customer data. There have been examples of curious users noting the structure used to access individual users’ account pages, changing a number in the URL, and gaining direct unauthenticated access to a stranger’s account.

The basic principle behind forced browsing extends into more sophisticated attacks. Poorly-configured Cross-Origin Resource Sharing (CORS) is vulnerable to very similar attacks. Without proper safeguards, some applications may allow access tokens – such as session keys or JSON Web Tokens – to be manipulated and allow users to access privileged functions or other users' accounts.


The potential extent of the problem

Access control is often structured to work as a ‘gatekeeper’. Unauthorised users are kept on the outside until they gain proper authorisation (authentication), through such means as a username and password. The problem with this is that application design rarely accounts for when malicious agents gain this authorisation. Once someone can get ‘in’, there is often little or no further access control to prevent them harvesting data, falsifying records or accessing privileged functions.

In 2015, the IRS was once again breached. This time, the attackers did not need to break the authentication since they already had access to user credentials. Despite all the lessons learned from the 2012 breach, the IRS did not have adequate access controls to prevent the ‘authenticated’ attackers impersonating legitimate users and manipulating the system. The attackers were able to file fraudulent tax returns and received $50 million in government payouts before the attack was detected.

SAST and DAST testing can help to detect the absence of access control in a system, but cannot determine whether it functions properly when in use. Since a breach often involves tricking the access controls into accepting the attacker as a legitimate user, automated tools may not be able to detect a breach after the fact.

Broken access control is difficult to spot in advance and during an ongoing breach.

Put together, these factors leave us with a very tricky security risk. Broken access control is difficult to spot in advance, can be even harder to detect during an ongoing breach; and can have extremely far-reaching and costly consequences.


Solutions

Application structure can mitigate access control problems by implementing additional layers of security to protect sensitive data. This way, even if an attacker gains access to a certain level of privileged functions, user data or administrative commands can remain protected. Writing about the 2015 IRS breach, a Gartner blog pointed out: You have to assume the criminals can get through at least one layer, so the more layers and measures you have the better off you are.

Enforcement of access controls should always be handled server-side. Even if client-side controls are implemented, they should never be the sole means of authentication enforcement, especially when it comes to sensitive data. With the right tools, client-side controls can always be bypassed or modified.

A common step taken in web applications is to incorporate authorised IP addresses and device IDs into authentication. A user signs in from a new device or location, and cannot login until entering an MFA code sent by the app. This alone is not watertight protection, but it prevents broken access control by an attacker who has gained access to basic login credentials.

Manual testing and proactive security are the best tools to protect access controls. OWASP has released guidelines for authorisation testing, with the sections on directory traversal and authorisation bypassing especially relevant. A separate top 10 list of the most important proactive security controls is also available, which High-Tech Bridge has analyzed previously here and here.

Manual testing and proactive security are the best tools to protect access controls.

Until technology improves, developers are forced to work with binary access controls. We can only focus on keeping applications tightly-coded and implementing those proactive controls. High Tech Bridge's Immuniweb Discovery service is a good place to start being proactive, combining the best aspects of manual and AI-driven testing to help keep all aspects of access control as strong as possible.


Actionable introduction and analysis of web and mobile application security, DevSecOps and Machine Learning for AST.

User Comments
Add Comment

High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email
Share