Defending Your Start-Up or Small Business from Authorization Bypass Attacks

When you’re responsible for development in a start-up or small business, cybersecurity is often not a primary strategic concern. Technical infrastructure that supports customer relationship management and the software development process are legitimate priorities that can crowd out cybersecurity when it’s time to choose where to spend limited time and financial resources. If you’re building a software product the priority is on creating an exciting feature set that delights the customer.

New products and CRM systems also demonstrate return on investment much more clearly and quickly than technical security practices nested inside the development process. Regardless of the size of the business, customers, employees, business partners, and regulators expect you to safeguard their data, and cybersecurity is a vital part of providing a great customer experience.

Research has found that many small business leaders still believe their companies are too small to need to worry about a data breach. A survey by Insureon found that only 16% of 2,400 participants were concerned about cyberattacks, and an analysis by the Poneman Institute found that in 2017 cyberattacks cost small and medium sized businesses $2,235,000.

Start-ups and small businesses are still attractive targets for malicious users. They know you’re often under-resourced and that the pressure to get to market creates an environment where something important might get missed in the development process.

These potential oversights don’t happen because of negligence or a lack of design skill. When you’re trying to build the bicycle while riding it in the Tour de France there’s just a lot to keep track of, and attackers bank on the fact that these multiple priorities have the potential to introduce vulnerabilities that make it possible to bypass authorization.

This guide describes three common authorization bypass attacks and provides steps you can take to prevent them.

There are three common ways attackers use to bypass authorization controls and gain access to secure data.

• Forced Browsing
• Parameter Manipulation
• Weak application level authorization checks

Before diving into the details, it’s important to remember that authentication and authorization are different security controls.

Authentication

• Refers to the verification of identity.
• Is the user really the user who she/he claims to be?
• Examples: Unified Login, Single Sign-On (SSO).

Authorization

• Refers to the verification of privileges.
• Is the user allowed to perform the action she/he is trying to perform?
• Is the user supposed to view/edit the data she/he is trying to access?

The Authorization Bypass Attack

Authorization bypass attacks refers to a series of attack vectors used by malicious users to perform actions which they are not authorized to perform.

Examples include:

• Bypass workflow logic (e.g. approve your own requests)
• Read/modify/delete data belonging to another user.

Forced Browsing

Forced Browsing exploits insecure direct object references (IDORs) and is also known as:

• Predictable Resource Location
• File Enumeration
• Directory Enumeration
• Resource Enumeration

A direct object reference occurs when the application design exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. If an access control is not in place, the attacker can alter direct object references to access other objects without authorization.

In this scenario, an attacker uses the authorization URL to directly request pages and resources that don’t belong to them. These attacks are performed manually and are common with business applications that allow users to create accounts and edit their profile after authentication.

Here’s an example of a URL that’s vulnerable to a forced browsing attack.

In this case, the attacker simply makes incremental changes to the numeric values until they hit one that corresponds to an actual user ID, like this:

If this small change grants the attacker access to the profile editing workflow, it becomes possible to take full control of the account. In the case above, /1235 is acting as an insecure direct object reference. Each number corresponds directly to a user and there are no authorization checks in place.

Tutorialspoint has a nice guide to insecure indirect object references that provides examples how unverified data in a SQL call accessing account information can set the stage for a bypass attack.

Forced Browsing Mitigation

One way to prevent Forced Browsing is to eliminate insecure direct object references that attackers can easily guess and manipulate. By removing object references like /1234 you can immediately gain an extra level of security.

Another key mitigation step is to authorize —not just authenticate—every page request. If the attacker tries to access /1235 as in the previous example, check to ensure it’s actually the account holder who is trying to access the page.

The Open Web Application Security Project (OWASP) has published a great cheat sheet about how to secure direct object references.

Parameter Manipulation

Parameter Manipulation is similar to forced browsing, but in this case the attacker uses parameters in the HTTP request to bypass authorization. Again, let’s consider an application that lets users edit their profile page after authentication.

In this example, the attacker tries to change the HTTP account parameter in the request and then attempts to edit another user’s data, like this:

By incrementally changing the account value by 1 the attacker hopes to open the edit profile page of another user, and in this case the value of the account was easily guessable for each user.

But what if we use POST instead of GET?

It won’t matter. Not one bit. The attacker can still use a proxy to change the account parameter. If your application design does not include authorization checks for the Parameter Manipulation scenario, the system can be undermined.

Parameter Manipulation Mitigation

One way to prevent Parameter Manipulation is to make sure your application doesn’t include parameters that attackers can easily guess and manipulate, like this one:

Remember that sending parameters in POST does not solve the problem and that authentication alone will not stop someone from using parameter manipulation to gain access to data.

Authorize every request. Period. If the attacker tries to gain access using profile?account=1235, an authorization check should be in place to determine if it’s the actual account holder who’s trying to access the page.

The Burp Community Edition is a great proxy for reviewing requests and responses used by your application.

In these cases, malicious users carefully profile application behaviors and look for ways to exploit them. Perhaps your product is a payment application that allows merchants to add secondary accounts for managing certain activities like reviewing transaction history. These types of applications are a common first-stop for attackers in search of an easy target.

Attackers profiling payment services applications are overjoyed when they discover that a secondary user with view-only access is allowed to withdraw money from the account.

A malicious user notices that she/he can add the same secondary account to multiple primary merchant accounts. By doing this, the attacker can gain access to transaction history information or other account data your customers rely on you to protect.

Weak Application Level Authorization Checks Mitigation

One mitigation for this attack is to include an application level check that prevents secondary accounts from belonging to more than one primary account.

As with the other flavors of this attack, authorization is a key line of defense. Make sure the secondary user’s action is authorized. Attackers targeting payment services applications are overjoyed when they discover that a secondary user with view-only access is allowed to withdraw money from the account.

Another way to prevent this attack is to make sure each request passes through a set of matrices before allowing access.

User and object types matrix

	Page 1	Page 2	File 1	File 2
Users	Allow	Deny	Deny	Deny
Power Users	Allow	Deny	Allow	Deny
Administrators	Allow	Allow	Allow	Allow

Users of the same type/role and objects. Acknowledges that there could be access restrictions even with the same role/type of users.

	User 1 Data	User 2 data	User 3 Data	User 4 Data
User1	Allow	Deny	Deny	Deny
User2	Deny	Allow	Deny	Deny
User3	Deny	Deny	Allow	Deny

Add this checklist to your QA process, and if you don’t develop the software used by your business, make sure your 3rd party vendor selection process covers these areas.

1. Don’t use object references attackers can easily manipulate either in URL or in request parameters (GET or POST) and disable directory traversals on your web server.
2. Always authenticate and authorize every request. Understand that these are both separate authentication controls and cannot solve authorization related issues.
3. Implement authorization matrices in your application for user types v/s objects and users of the same type v/s objects and evaluate each request through these matrices.

Remember that POST request parameters are also vulnerable so using POST instead of GET doesn’t solve the problem.

Regardless of the size of your business, it’s important to make application security a priority. An understanding of the common attack vectors used in authorization bypass attacks will help you build an application that not only delights your customers, but protects them as well. Solving potential vulnerability problems upstream in the design process will produce a better product and help you build trust with your customers. When it comes to security, setup is almost always easier than clean-up and it’s usually a lot less expensive.

Joseph O’Meara, “Defending Your Small or Medium Sized Business from Authorization Bypass Attacks,” Setup is Easier Than Cleanup Volume 1, No. 1. February, 2020.

Copyright 2020; Rampant Geek LLC – All Rights Reserved