If you’ve ever had a toddler or a cat, you know they usually enjoy that box that an item comes in more than the item itself. In other words, you already know the first rule of business logic testing: the way people use applications isn’t logical.  

As a developer, you have a set idea about what your application should do based on the business needs and requirements. You know how people should use the application, but people aren’t as predictable as code. When testing for business logic vulnerabilities, you need to think creatively and anticipate the accidental threats people create when they do the unexpected. 

If you’re looking for a place to get started, you can turn to the Web Security Testing Guide (WSTG) from OWASP for some best practices around testing for business logic vulnerabilities. 

Why business logic vulnerability testing is challenging

Business logic vulnerabilities arise from a disconnect between a web application’s intended use case and how attackers can misuse mechanisms to achieve their objectives. Testing for business logic vulnerabilities typically requires insight into:

• Business logic: The business reasons for people using the application
• Application logic: The way the code translates this into a user interface

Business logic testing is often a manual process because it requires understanding the application’s business functions and how the application’s code achieves them. 

As you work toward building secure software, you can implement threat modeling to help identify potential misuse cases. Threat modeling is a structured approach based on four basic questions:

• What type of environment or technology are you working on?
• What can go wrong?
• What are the appropriate next steps?
• How well did the solution work?

Most business logic vulnerabilities arise from how data flows across your application, meaning that most vulnerability scanners that look for commonly known vulnerabilities won’t identify these problems. Ultimately, you need people who can think like threat actors to identify business logic vulnerabilities. 

WSTG’s 9 Tests for Business Logic Vulnerabilities

The OWASP Web Security Testing Framework provides steps you can take across the software development lifecycle (SDLC) to build application security into your development processes and culture. Unfortunately, since business logic vulnerabilities are application-specific, to identify and remediate them, you should use one of the nine tests that the WSTG suggests. 

Business Logic Data Validation

If your application allows user-controlled data inputs, it should validate data on both the client-side and server-side. Although you may already be testing for format and semantics, you should also ensure that the application validates the data and how it passes it through different data flows. 

The WSTG suggests:

• Reviewing documentation to look for data entry points and hand-off points 
• Using HTTP POST/GET to identify variables and locations where the application passes information
• Sending invalid data to ensure that the server functions properly and refuses to accept it

Ability to Forge Requests

Forged requests often use hidden parameters that leak data or help bypass the business logic. If sending these fake inputs can break the business logic workflow, then applications respond in ways that enable attackers to compromise it.

The WSTG suggests:

• Observing HTTP POST/GET to identify easily guessable elements or hidden features
• Changing these values to see if the application behaves in an unexpected, insecure way

Integrity Checks

When an application displays and hides different fields based on user situation, threat actors can submit values to hidden fields using browser or proxy editor tools. Server-side controls should perform relational or server-side edits that prevent people from submitting invalid information directly to the server. Additionally, controls should prevent anyone from making unauthorized read, write, and delete changes to system artifacts, like logs. 

The WSTG suggests:

• Observing HTTP traffic for hidden fields or places to insert information
• Seeing how fields compare with the application interface
• Submitting different data input to circumvent the business process and manipulate values without appropriate authorization

Additionally, for any application or system components that these attack methods can compromise (like databases and logs), you should test to see if anyone can read, edit, or remove it without appropriate authorization.

Process Timing

Threat actors can monitor the time an application takes to complete a task or provide a response, enabling them to manipulate or break business process flows by keeping sessions open. Process timing logic vulnerabilities may leak information about the application’s or system’s background processes that malicious actors can use to guess what will happen next. 

The WSTG suggests:

• Draw data process flow diagrams identifying injection points
• Identifying time-dependent processes that provide either a window for task completion or execution time between two processes
• Automate requests attempting to abuse the processes

Number of Times a Function Can Be Used Limits

Many applications set a limit on how many times a function can be used or an action executed. Malicious actors attempt to circumvent the business logic by executing the function more times than allowed. 

The WSTG suggests:

• Identifying single-use or specified-number-of-use functions and features in business logic workflow
• Develop abuse/misuse cases
• Attempt them to see if they work or not

Circumvention of Workflows

When attackers can circumvent the intended set of steps that users must complete when engaging in actions, the application has a workflow vulnerability. When attempts to use a different order occur, the workflow should terminate and cancel all actions. 

The WSTG suggests:

• For an e-commerce application:
  • Start a transaction that triggers credits/points to the user account 
  • Cancel transaction or reduce final tender to determine whether the application recorded the appropriate credits/points
• For a content management/bulletin board system:
  • Begin and save a message
  • Try to edit or remove data, creating incorrect or invalid values, to see if the application saves or deletes them

Defenses Against Application Misuse

When the application has no active defenses, misuse and invalid use of valid functionality can identify potential attacks. 

The WSTG suggests collecting the following metrics from all other tests:

• Changed responses
• Blocked requests
• Actions that log a user out or lock their account

Additionally, localized security controls are not sufficient, so the application should have the appropriate logging and monitoring capabilities. 

Upload of Unexpected File Types

When the application’s business processes allow users to upload or manipulate data submitted via files, attackers may submit a normally innocent yet unexpected file type containing malicious code. The application should specify and validate the file types that can be uploaded and processed.

The WSTG suggests:

• Studying logical requirements and preparing a list of “not approved” file types
• Attempt to submit a “not approved file type”
• Check for application to determine whether it:
  • Only checks on the client-side JavaScript
  • Only checks by “Content-Type” in HTTP request
  • Only checks by file extension
  • Allows other uploaded files to be accessed directly by specified URL
  • Allows  uploaded files to include code or script injection
  • Creates a file path checking for uploaded files

Upload of Malicious Files

Unlike unexpected file types, the malicious files business logic vulnerability means that the application fails to scan files for exploits or shellcode that could be detected or stopped at various points across the application architecture. 

The WSTG suggests:

• Only allowing trusted file types to be uploaded
• Scanning file contents for malware, malicious zip files, large files, XML file vulnerabilities, and file formats with known security concerns, including CSV, Office, and PDFs
• Reviewing source code for common API/methods of upload, like
  • Java: new file, import, upload, getFileName, Download, getOutputString
  • C/C++: open, fopen
  • PHP: move_uploaded_file(), Readfile, file_put_contents(), file(), parse_ini_file(), copy(), fopen(), include(), require()

Qwiet AI: Secure Code and Business Vulnerability Testing

With Qwiet AI’s preZero platform, you can scan millions of lines of code in minutes for visibility into all components, dependencies, and reachable vulnerabilities. Our platform quickly returns accurate and detailed findings while significantly reducing false positives. With our Code Property Graph (CPG), you gain a holistic view of your code, including data flows across the application, to quickly determine reachability and risk impact.

At QWIET AI, we provide more than just tools – we can deliver a fully managed application security service tailored specifically to your organization’s unique needs. Our deep expertise in application security combined with seamless CI/CD integration ensures you’re not just deploying a solution but establishing a robust partnership. 

Try Qwiet AI’s preZero platform for free to see how it can help you mitigate risks from business logic vulnerabilities.