All about Business Logic Flaws in Web Applications

What are Business Logic Vulnerabilities??????

Business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organizations.

Let’s take an example to understand this:-

A person who sells garments to consumers worldwide from his site-XYZ.com.You will observe some checkout processes or steps:-

1. The customer picks one or more items and adds them to the basket
2. The customer then go to the order page to initiate a purchase
3. Customers will go for payment or checkout option
4. The owner will send order and customer details to its Payment partner for authorization
5. Payment Company returns transaction id to owner XYZ.com
6. The owner will display confirmation details on the customer page

So in the above workflow, if we observe, we can do a currency attack on this Owner of XYZ.com.At step[3], the attacker manipulates a currency-related in post request and can change the currency type from “Rupees” to “US Dollars”.As a result, the attacker was able to exploit this logic flaw by paying less for the order.

Before going more deeper into this, first, we need to understand What is/is not a Business Logic Flaw?

Difficulties finding Business Logic Vulnerabilities with established security tools

Problems with Business Logic Flaws

1. Security Scanners can’t identify them…Why??

They focused on “pattern-based vulnerabilities discovery” influenced by untrusted inputs ie when you are analyzing the open redirect type of vulnerabilities like XSS, HTTP error code or you are looking for SQL injection. But when you are talking about Application Logic Vulnerabilities, there is no pattern present.

2. Web Application Firewalls can’t defend from all of them…Why??

We need to reconfigure the software and heavily customized the WAF anytime those applications are changed. If we don’t have an automation system and have a human configuring this policy, then at some point your WAF always falls behind.

3. IDS(Intrusion Detection) can’t detect them, Why??

It lacks the context of the application and can’t effectively differentiate between legitimate users or business logic abusers.

How to test for Business Logic Flaws??

1. Check for Time-of-Check-time-of-use and race condition issues

• Try to fire the transaction request in the web application at the same time
• Try to open the checkout page one with less price item and one with high price item in the cart, then perform a transaction on the less price item page and check whether the high price item is also included in it.
• Change the order after payment completion.

2. Parameter Manipulation

• Price Manipulation
• Currency Manipulation (if it is in USD/Eur try to change in INR)
• Quantity Manipulation ( by providing values such as 0.01 in decimal form)
• Response Manipulation
• Replay attacks

3. Hidden and Insecure backend API’s

4. Using test data in the production environment

Attacker Mindset

• Understand how the application works by following information flow
• Discover points of interest-Web Forms, User Registration, Password Recovery, etc.
• Intercept points of interest inflows to identify overrides. For example:-

1. User inputs in requests

2. Outbound channels of communications

3. Naming conventions used in request/response paradigm

Attack Vectors for Business Logic

The top 10 business logic attack vectors include:-

1. Authentication flags and privilege escalations at the application layer

How to test for this business logic flaw:

1. During the profiling phase or through a proxy observe the HTTP traffic, both request and response blocks.
2. POST/GET requests would have typical parameters either in name-value pair, JSON, XML, or Cookies. Both the name of the parameter and the value needs to be analyzed.
3. If the parameter name is suspicious and suggests that it has something to do with ACL/Permission then that becomes a target.
4. Once the target is identified, the next step is evaluating the value, it can be encoded in hex, binary, string, etc.. The tester should do some tampering and try to define its behavior with a bit of fuzzing.
5. In this case, fuzzing may need a logical approach, changing bit patterns or permission flags like 1 to 0 or Y to N, and so on. Some combination of brute-forcing, logical deduction, and artistic tampering will help to decipher the logic. If this is successful then we get a point for exploitation and end up escalating privileges or bypassing authorization.

2. Critical Parameter Manipulation and Access to Unauthorized Information/Content

How to test for this business logic flaw:

1. During the profiling phase or through a proxy, observe HTTP traffic, both request and response blocks.
2. POST/GET requests would have typical parameters either in name-value pair, JSON, XML, or Cookies. Both the name of the parameter and the value needs to be analyzed.
3. Observe the values in the traffic and look for incrementing numbers and easily guessable values across all parameters.
4. This parameter’s value can be changed and one may gain unauthorized access.

In the above case, we were able to access other users' profiles.

3. Developer’s cookie tampering and business process/logic bypass

How to test for this business logic flaw:

1. During the profiling phase or through a proxy observe the HTTP traffic, both request and response blocks.
2. Analyze all cookies delivered during the profiling, some of these cookies will be defined by developers and are not session cookies defined by the web application server.
3. Observe cookie values in specific, look for incrementing easily guessable values across all cookies.
4. Cookie value can be changed and one may gain unauthorized access or logical escalation.

4. LDAP Parameter Identification and Critical Infrastructure Access

How to test for this business logic flaw:

1. During the profiling phase or through a proxy observe the HTTP traffic, both request and response blocks.
2. POST/GET requests would have typical parameters either in name-value pair, JSON, XML, or Cookies. Both the name of the parameter and the value needs to be analyzed.
3. Analyze parameters and their values, look for ON, CN, DN, etc. Usually, these parameters are linked with LDAP. Also, look for the parameter taking email or usernames, these parameters can be prospective targets.
4. These target parameters can be manipulated and injected with “*” or any other LDAP-specific filters like OR, AND etc. It can lead to logical bypass over LDAP and end up escalating access rights.

5. Business Constraint Exploitation

How to test for this business logic flaw:

1. During the profiling phase or through a proxy observe the HTTP traffic, both the request and response blocks.
2. POST/GET requests would have typical parameters either in name-value pair, JSON, XML, or Cookies. Both the name of the parameter and the value needs to be analyzed.
3. Analyze hidden parameters and their values, look for business-specific calls like transfer money, max limit, etc. All these parameters which are dictating a business constraint can become a target.
4. These target parameters can be manipulated and values can be changed. It is possible to avoid the business constraint and inject an unauthorized transaction.

6. Business Flow Bypass

How to test for this business logic flaw:

1. During the profiling phase or through a proxy observe the HTTP traffic, both request and response blocks.
2. POST/GET requests would have typical parameters either in name-value pair, JSON, XML, or Cookies. Both the name of the parameter and the value needs to be analyzed.
3. Identify business functionalities that are in specific steps (e.g. a shopping cart or wire transfer).
4. Analyze all steps carefully and look for possible parameters that are added by the application either using hidden values or through JavaScript.
5. These parameters can tamper through a proxy while making the transaction. This disrupts the flow and can end up bypassing some business constraints.

7. Exploiting Clients Side Business Routines Embedded in JavaScript, Flash, or Silverlight

How to test for this business logic flaw:

1. Once the page is loaded in the browser one needs to analyze DOM using firebug or any other similar tool.
2. Identify all variables residing on the browser stack.
3. Look for suspicious values and parameters.
4. One can manipulate these values inside DOM and replay the HTTP request.

If the business logic is trusting only on the client-side then it may end up giving unauthorized access.

8. Identity or Profile Extraction

How to test for this business logic flaw:

1. During the profiling phase or through a particular proxy observe HTTP traffic, both request and response blocks.
2. POST/GET requests would have typical parameters either in name-value pair, JSON, XML, or Cookies. Both names of parameter and value need to be analyzed.
3. Look for parameters that are controlling profiles.
4. Once these target parameters are identified, one can decipher, guess or reverse engineer tokens. If tokens are guessed and reproduced — game over!

9. File or Unauthorized URL Access and Business Information Extraction Identity

How to test for this business logic flaw:

1. During the profiling phase or through a particular proxy, observe the HTTP traffic, both request and response blocks.
2. POST/GET requests would have typical parameters either in a name-value pair, JSON, XML, or Cookie. Both the name of the parameter and value need to be analyzed.
3. Identify file call functionalities based on parameter names like file, doc, dir, etc. These parameters will point you to possible unauthorized file access vulnerabilities.
4. Once a target parameter has been identified start doing basic brute force or guesswork to fetch another user’s files from the server.

10-Denial of Services (DoS) with Business Logic

How to test for this business logic flaw:

There are no universal DoS attacks like TCP flooding on networking at the application layer, but it depends on the features and the applications. In some cases, infinite loops implemented in the application layer can force a DoS attack.

Thanks for reading

For any quick query or getting in touch with me, You can follow me on

Follow me on Twitter, LinkedIn, GitHub