Tales from the Road: Taking Control of Access Controls to Protect Sensitive Data from Unauthorized Users

Tales from the Road: Taking Control of Access Controls to Protect Sensitive Data from Unauthorized Users

How a recent DirectDefense application security assessment revealed a common vulnerability.

A large financial corporation recently called on us to perform a comprehensive security assessment of their client-facing application. Among other findings, the engagement revealed just how easy it would be for someone with ill-intent to exploit the application via access controls that were not implemented properly – a very common issue. Once such a flaw is discovered, the consequences of a broken access control scheme can be devastating. In addition to viewing unauthorized content, an attacker might be able to change or delete content, perform unauthorized functions, or even take over site administration.

Don’t let an insecure application threaten your company’s reputation and the integrity of your customer data. Read on to learn how to secure your applications by fixing broken access controls to ensure the protection of financial data, Personally Identifiable Information (PII) and intellectual property.

Make Sure Your Applications Are Secure

Using a comprehensive set of testing tools, custom scripts and manual techniques to thoroughly identify possible threats to our client’s application, our team discovered several critical vulnerabilities that provide attack vectors that a suitably-skilled adversary could leverage to gain unauthorized access to sensitive data.

Access control, sometimes called authorization, is how a application grants access to content and functions to some users and not others. These checks are performed after authentication, and govern what authorized users are allowed to do. Our team discovered that many of the application functions validate that the session is valid but do not verify that the user associated with the session has proper privileges to access the requested functionality. By making requests directly to these functions, authenticated low-privilege users can bypass access controls to gain greater application access, allowing them to perform unauthorized actions and compromise critical data.

Take Control of Access Control

Access control sounds like a simple problem, but is often difficult to implement correctly. An application’s access control model is closely tied to the content and functions that the site provides. In addition, each user may fall into a number of groups or roles with different abilities or privileges. This complex interrelationship between functions, data, users and roles makes it challenging for developers to implement access control correctly.

During the engagement, our team identified that the application’s access controls do not prevent authenticated users from accessing functionality that they are not intended to access or retrieving data from accounts of which they are not members. Using a common technique known to attackers, it didn’t take long for our penetration team to discover and exploit our clients flawed access control:

What We Did: By logging in as an authenticated user that belonged to a different group, our team simply crafted a series of requests for functions that should not be granted. Using this effective technique, we were able to obtain unauthorized read access to a substantial amount of personal and private data including SSNs, bank account information, deposit information, payment information, transfer information and more. Even though we didn’t have write access, we could have easily deleted data.

How to Fix It: Enforce strong protections on authorization controls. Ensure that users have sufficient privilege to use certain functions and authorization for the accounts that they are accessing or modifying.

Application Security Starts with a Security Program

The most important step in fixing broken access controls is to think through an application’s access control requirements and capture it in an application security policy. At DirectDefense, we strongly recommend the use of an access control matrix to define the access control rules. Without documenting the security policy, there is no definition of what it means to be secure for your site.

The application security policy should:

• Document what types of users can access the system and what functions and content each of these types of users should be allowed to access.
• Include plans to extensively test the access control mechanism to be sure that there is no way to bypass it.
• Test a variety of accounts and include extensive attempts to access unauthorized content or functions.

Some specific access control issues to test for include:

• Insecure IDs: Most applications use some form of ID, key or index as a way to reference users, roles, content, objects or functions. If an attacker can guess these IDs, and the supplied values are not validated to ensure they are authorized for the current user, the attacker can exercise the access control scheme freely to see what they can access. Applications should not rely on the secrecy of any IDs for protection.
• Forced Browsing Past Access Control Checks: Many applications require users to pass certain checks before being granted access to certain URLs that are typically deeper down in the site. These checks must not be by-passable by a user that simply skips over the page with the security check.
• Path Traversal: This attack involves providing relative path information (e.g., ../../target_dir/target_file) as part of a request for information. Such attacks try to access files that are normally not directly accessible by anyone, or would otherwise be denied if requested directly. Such attacks can be submitted in URLs as well as any other input that ultimately accesses a file (i.e., system calls and shell commands).
• File Permissions: Many application servers rely on access control lists provided by the file system of the underlying platform. Even if almost all data is stored on backend servers, there are always files stored locally on the application server that should not be publicly accessible, particularly configuration files, default files and scripts that are installed on most application servers. Only files that are specifically intended to be presented to users should be marked as readable using the OS’s permissions mechanism. Most directories should not be readable, and very few files, if any, should be marked executable.
• Client-Side Caching: Many users access applications from shared computers located in libraries, schools, airports and other public access points. Browsers frequently cache web pages that can be accessed by attackers to gain access to otherwise inaccessible parts of sites. Developers should use multiple mechanisms, including HTTP headers and meta tags, to be sure that pages containing sensitive information are not cached by users’ browsers.

The bottom line: There are many application layer security components that can assist you in the proper enforcement of various aspects of your access control scheme. In order for access controls to be effective, they must be configured with a strict definition of what access requests are valid for your individual application. Regular application security assessments are important to ensure that vulnerabilities are identified and mitigated before they become a larger issue. 

Contact Us Today!

How secure are your apps? If you’d like to know how a application security assessment can help protect your organization, let’s talk. Visit directdefense.com or call us at 1 888 720 4633.

   By: Kelly Kish   04.29.21