Finding the Flaws No Tool Can See: A Deep Dive into Application Logic Vulnerabilities

Application Logic Vulnerabilities are, arguably, the most crucial and difficult-to-find errors in any system. For bug bounty hunters, mastering the art of finding these flaws is what truly marks the difference between a routine security assessment and a high-impact discovery.

These vulnerabilities are not standard, predictable security mistakes. Instead, they are subtle, hard-to-find errors generated by the flawed logic applied during the application’s development. Finding them requires a profound, holistic understanding of the target system.

The Nature of Logic Flaws: Beyond Simple Syntax

To successfully hunt for logic vulnerabilities, you must develop a deep understanding of the following aspects of the application:

• How the application works: Its intended function, purpose, and workflow.
• How the application is managing each piece of information that is entered by the user: This includes understanding data validation, processing order, and storage mechanisms.
• How the application is interacting with other applications or services: Looking for weaknesses in communication between components (e.g., microservices, APIs).
• How the developers applied the technology used to construct the application: Understanding the chosen framework’s features and any custom implementations.

All of the preceding elements must be examined when trying to find errors in the implementation.

Origins of Logic Flaws: The Developer Paradigm

If development teams follow standard maturity model methodologies (structured processes to ensure quality), why do these kinds of vulnerabilities exist? How is it possible that these flaws are not detected in the design phase?

The basic idea about why application-logic vulnerabilities happen is that the developers, when creating an application, are following a specific paradigm—not a technology paradigm, but a way of thinking.

This means they make decisions in the code based on an expected, limited set of possibilities defined during the design phase. They consider only the possible options they have outlined from the initial design specification.

But, what happens if an external person, a bug bounty hunter, with different ideas and outside of that development paradigm, explores other options?

Since these different options were not thought of by the developers, the system treats it as an unexpected input or action, which sometimes results in a crash, but in some cases, it leads to a serious vulnerability.

The Main Problem: The Lack of Patterns

When we look for common vulnerabilities like Cross-Site Scripting (XSS), SQL Injection (SQLi), or Open Redirects, we are, quite simply, looking for patterns. For example, when hunting for an open-redirect vulnerability, one is always looking for a 3xx HTTP error code (a redirect response). When looking for input validation errors, we always enter special characters (like or ') to generate an error.

But, talking about application logic vulnerabilities, these are not patterns. This is the core reason why most of the automated security tools and static analysis (tools that analyze code without executing it) fail to find them. Furthermore, if the Quality Assurance (QA) team is too involved in the application’s design, they may operate within the same thought paradigm as the developers, meaning they will never detect the flaws.

Finding logic bugs requires human ingenuity, creativity, and thinking outside the expected flow.

Following the Flow: Essential Reconnaissance

As we mentioned before, the most important thing when you are looking for application logic vulnerabilities is to understand how the application works. To do so, it is essential to map the application’s flow.

Spidering: Uncovering Hidden Resources

Most of an application’s visible functionality could be discovered just by navigating through the application manually. However, there are numerous features, parameters, and hidden sections that are only referenced in the requests and responses—never directly linked on a visible page.

For this reason, using a spidering tool during navigation is absolutely essential.

A spidering tool (found in all major HTTP proxies) works by:

1. Extracting all links, redirects, and paths to internal or external resources from every request and response it sees.
2. Mapping them to discover hidden sections, potential entry points, and resources that might be out of the developer’s normal view.

Using a Spidering Tool (Burp Suite Example)

Let’s look at how to use a typical spidering tool. In this example, we will use Burp Suite’s Spider as the process is similar in other proxies:

1. Intercept the Initial Request: Access the target application with your browser configured to use your proxy (e.g., Burp Suite). Intercept the initial request you make to the application (the very first time you load the domain).
2. Send to Spider: With the request intercepted in the Proxy tab, perform a secondary click (right-click) and click on Send to spider.
3. Define Scope: If this is the first time you’ve added a request to the project, a warning message will be displayed. This message prompts you to confirm that the domain should be included in the scope.

What is the Scope?

In all HTTP proxies, the scope allows you to limit the analysis to a single domain (application) or multiple domains. This is extremely useful in bug bounty hunting when a program is limited to a specific subdomain but is hosted alongside others. For example, a bounty might include:

• shop.google.com
• applications.google.com
• dev.google.com

But it will exclude the wild card (*.google.com), mail.google.com, or music.google.com. Setting the scope ensures your tooling only analyzes the allowed targets.

4. Monitor and Navigate: After accepting the warning message, the domain is included in the scope. All subsequent requests and responses made during your navigation will be spidered. The proxy will work in the background, extracting all links and mapping them.

Now, you simply need to navigate the application and explore each section while the proxy is in the background collecting information. Sometimes, you may see messages about sections that cannot be accessed due to permissions, which can alert you to hidden administrative or privileged paths.

In the Target table of your proxy, you can see the complete map of the application and its resources. Here, you must review all the paths and domains of links that you have not seen before, as these are potential hidden gems for logic flaws.

Critical Points of Interest: Where Logic Flaws Hide

To find application logic vulnerabilities, a security assessment must go beyond simple pattern matching. It is necessary to map the application entirely, but you should concentrate your focused effort on specific special zones where there is high user interaction and complex processing.

1. Forms: Following the Data Flow

When analyzing forms, your approach shifts entirely from trying to inject something into the fields (the goal for XSS or SQLi) to simply trying to understand what is fundamentally happening with the data that is entered.

Ask yourself a series of questions to trace the data’s journey:

• Is the data processed immediately? If so, how?
• Is the data stored? Where, and in what format?
• Is the data used by an external service? Is this service internal (another part of the application) or external (like a third-party API)?
• Is it processed by other applications after the initial submission?

Understanding this complete data flow is crucial. A logic flaw might exist not in the initial submission, but in a secondary process that consumes the data without re-validating it.

2. User Registration and Account Management

Any section related to user management—registration, profile editing, and deletion—is a high-priority target for logic flaws.

• Registration Flow: Try to understand how the application registers the user and how it determines the user’s initial profile or authorization level. Can you manipulate a parameter entered during registration (or in the request) to get a higher privilege level? For example, is the application using a hidden parameter to identify users by groups (group_id=1 for admin) that you can change?
• External Services: Investigate whether the application is using an external service to register and authenticate the user, such as a Single Sign-On (SSO) solution or an Active Directory. Flaws often exist in the integration or the handling of redirects from these external services.
• Deletion Options: If available, thoroughly check the delete user options for flaws. Can you delete another user’s account by substituting their ID?

3. Password Recovery: The Authentication Weak Link

In many security assessments, the password recovery flow is one of the most valuable places to look for critical bugs—often leading to full account takeover.

Try to understand the exact mechanisms the application uses to help a user reset their credentials:

• Contact Method: How does the application contact the user? Does it send a password reset link, or does it send a new password directly to the user?
• Temporary Credentials: If a temporary password is created, investigate whether it uses predictable patterns or a defined, guessable structure.
• External Services: Does it use an external service, such as SMS messaging or an external email API? Flaws here can sometimes allow attackers to bypass the contact step.
• Authorization Check: Investigate the specific methods used to change the password once the user is validated (after clicking the reset link). Sometimes, you can find authorization opportunities where the application trusts the temporary token but fails to verify that the final password change request is indeed tied to the user who initiated the request.

4. Tokens, Hashes, and Information Shared Between Applications

Complex applications, especially e-commerce sites, constantly share information to control the flow and make decisions. For example, an online shop sends payment information to an external payment service (like PayPal or Stripe), receives a token or status, and then confirms your order.

• Identify Shared Data: Try to understand what exact information is shared between these services.
• Analyze Structure: Investigate the structure of the shared data (e.g., is it JSON, XML, or an encrypted string?).
• Verify Integrity: Crucially, understand how the application knows that it has the correct, un-tampered information. If the application relies on an easily predictable or modifiable parameter (like a price or quantity) returned from a service, you have a logic vulnerability.

The application itself often provides a bunch of possible attack vectors just by analyzing these tokens. It is often useful to look into the public documentation of major third-party services (like payment gateways) where the structure of the data being used is defined, giving you insight into what the application expects.

5. Web Services (APIs): Mapping Scalability Flaws

Currently, application design often relies on a web service-based (API) model. This means that each functionality consumes a separate service (or microservice) to work, making the applications more scalable. While this is good for architecture, it often creates new security gaps.

It is necessary to pay close attention to the implementation model of these APIs, as it is a common place to find logic vulnerabilities.

Consumption Logic: Understand how the services are consumed. Does the front-end application enforce access controls, or does it rely entirely on the service layer? Often, a service may allow a user to query or modify data belonging to another user if the service lacks proper authorization checks for the requested ID.

Map All Services: Try to map all of the web services used by the application, even those not explicitly documented.

Entry Points: Note the exact entry points and the parameters they accept.

Key Analysis Techniques for Logic Flaws

Assessing an application from the bug bounty hunter’s perspective demands extensive manual analysis, especially when hunting for subtle application logic bugs. Since automated tools fail here, your systematic and creative human approach is the only way to succeed.

Here are the critical points to keep in mind and execute during your analysis:

1. Exhaustive User Input Mapping

The first step in manual analysis is to meticulously identify every single point where information is submitted to the application, whether intentionally (via a form) or unintentionally (via a background process). You must treat all incoming data as potentially malicious, regardless of its source.

Key areas to identify and test include:

• URLs: Information submitted through GET requests (query strings).
• Request Bodies: Parameters within POST requests.
• Hidden State Mechanisms: Data stored in Cookies, environmental variables (if visible), hashes, and tokens.
• Third-Party Resources: Data sent to or received from external APIs.
• HTTP Headers: Review headers like Referer, User-Agent, and custom headers, as they can sometimes contain exploitable session or state information.

2. Reviewing Out-of-Band (OOB) Channels

As emphasized, interactions between applications are fertile ground for logic flaws. These interactions often occur over out-of-band (OOB) channels, meaning they happen outside of the primary HTTP request/response stream, making them easy for developers to overlook.

It is necessary to review all these interactions, looking for potential vectors:

• Email Services: Used for notifications, password resets, or account verification. Check for injection or sequencing flaws.
• SMS Services: Used for notifications, Two-Factor Authentication (2FA) codes, or recovery features. Check for rate limiting and code brute-forcing.
• HTTP Redirects: Look for the specific parameters used in redirects between services, as these can be manipulated to redirect users to malicious sites.
• Central Services: Information shared between applications due to the consumption of central services (e.g., shared user authentication databases).
• Shared Data Storage: Review how different parts of the application access and modify shared databases or caches.
• APIs: Thoroughly analyze all internal and external API calls and their specific parameters.

3. Analyzing Naming Conventions (Keywords)

Developers use specific words to identify features, parameters, and methods. By analyzing the names used in requests, responses, and file paths, you can often uncover hidden or sensitive key features that were not intended to be publicly exposed.

Look for keywords in the requests and file paths that suggest a sensitive action:

• Database Actions: database, connect, update_, sql_, query.
• File Operations: update, create, new, delete, upload.
• Administrative Functions: admin, manage, internal, debug, test, secret.
• Authentication/Authorization: auth, login, access, privilege, role, user_id.

A path like /api/v1/user/admin_update_privilege is a massive signal that warrants immediate investigation.

4. Identifying Technology Keywords

If you are having trouble understanding the underlying architecture, you can often identify the technology being used by simply observing HTTP headers (banner-grabbing) or by looking for specific keywords in the application’s URLs and code. Knowing the technology helps you target known framework weaknesses and common logical flaws associated with that platform.

Look for the following technology-related keywords in URLs, headers, and file extensions:

Analyzing Network Traffic

The most important skill used to assess a web application is analyzing the network traffic. This is how you truly understand how an application works—not just what it looks like, but the data it receives and sends. This essential task is why the HTTP proxy (like Burp Suite) is the most useful tool for any bug bounty hunter focused on web applications.

What an HTTP Request Tells You

A single HTTP request can tell you a lot about the application’s inner workings. For instance, analyzing a request reveals:

• The Host: The target server’s address (Host: header).
• Security Mechanisms: The use of security tokens (e.g., _csrf_token) to avoid attacks like Cross-Site Request Forgery (CSRF).
• Data Structure: The presence and naming of variables and parameters in the URL or body.

Even if you don’t immediately know how specific variables work, you can determine their purpose by analyzing subsequent requests and seeing how their values change or are processed. You must review each request to build a comprehensive internal map of the application.

Hunting for Framework Bypasses

When analyzing traffic, be sure to look for requests that reveal the application’s internal structure and function. Most modern applications are developed using a framework (e.g., Rails, Django, Laravel), which provides built-in security features. However, developers sometimes avoid the framework’s recommended methods and implement their own custom functions.

These custom methods, developed outside the hardened framework structure, can easily lead to logic vulnerabilities. Detecting these custom calls in the requests is a strong signal that a logical flaw might exist.

Application Logic Vulnerabilities

To illustrate the high impact of logic flaws, let’s examine a critical vulnerability where authentication logic failed.

Bypassing the Shopify Admin Authentication

On September 28th, 2017, bug bounty hunter uzsunny reported a critical logic vulnerability on Shopify that allowed for admin access bypass.

The vulnerability arose from a flaw in how Shopify handled user accounts that shared the same email address across different profile types.

1. The Setup: The attacker created two distinct user accounts that both used the same email address.
2. The Target Profile: Shopify had a specialized user profile called collaborator, which granted significant privileges, particularly access to client sites.
3. The Exploit: The first account (let’s call it Account A) requested the collaborator profile. When the application granted collaboration status to Account A, the other account (Account B), which was a different user ID but shared the same email address, automatically received the same privileges.
4. The Result: Account B gained access to the sites controlled by Account A, effectively achieving unauthorized access and privilege escalation.

This vulnerability demonstrates how assumptions about unique email addresses and authorization across different systems (or sub-systems) can lead to a critical flaw.

The Developer’s Blind Spot

These kinds of logic problems are more common than you might think. From the developer’s perspective, correctly implementing complex user management and authorization modules is difficult. Developers often create an access matrix that defines which user profiles can access which application sections.

However, when an application begins sharing information or needs with more than one authorization matrix (e.g., standard users vs. partner collaborators), developers often make assumptions. In this case, the developer likely never thought that the same email address could be linked to two different accounts in a way that would confuse the authorization logic.

Tip for Finding Logic Flaws

To find this type of vulnerability, we highly recommend testing all the sections you find using your spidering tool with all the different users you control.

• Test Multiple Accounts: In bounty programs, you are usually provided at least two users of each access level. If not, create multiple users—some with different emails and some with the same email address if the platform allows it.
• Cross-Reference Access: If you detect strange behavior in a restricted section when testing with a lower-privileged user, ask the program owners for permission to test further, explaining your thought process. It’s often possible they will grant you access to confirm a logic bug.

The Timing Attack: Exploiting Race Conditions

Our final deep dive into application logic vulnerabilities focuses on a rare but highly critical flaw: the Race Condition. This type of vulnerability exploits issues related to timing and concurrent (simultaneous) processes, often leading to unauthorized financial gain or privilege escalation.

Understanding Race Conditions

In computer science, a Race Condition occurs when two or more processes (or requests) attempt to access and modify a shared resource (like a database value, memory variable, or environmental setting) at the exact same time.

If the application logic does not properly serialize (enforce one process at a time) access to that shared resource, the simultaneous access can lead to unexpected and critical results. The final outcome depends entirely on which process “wins” the race to complete its operation—often resulting in a bug.

Starbucks: The Free Coffee Exploit

On May 21st, 2015, researchers from the Sakurity Group published a bug detailing a race condition flaw found in Starbucks’ payment module. This vulnerability allowed a user to gain extra credit on their Starbucks cards.

The Setup:

The researchers registered three Starbucks cards on the web application. The application had a feature that allowed users to transfer money between their own cards.

The Flawed Logic:

The researchers analyzed the money transfer request and found that the process was controlled by two POST requests:

1. Preparation (Step 1): Take the values of the origin account, the destination account, and the user’s active session.
2. Confirmation (Step 2): After the money was moved, the application’s only mechanism to avoid multiple transfers was to clear the session.

The Exploit:

The researchers realized that if they could prevent the application from clearing the session before a second, simultaneous request could be initiated, they could transfer the same funds multiple times.

The key insight was realizing that the developers always expected the transfer to be made by a standard web browser, which inherently processes requests sequentially.

By using command-line tools, the researchers avoided the browser’s sequential nature and forced concurrent access:

# 1. Prepare two different, concurrent sessions (session1 & session2)
curl starbucks/step1 -H "Cookie: session=session1" --data "amount=1&from=wallet1&to=wallet2"
curl starbucks/step1 -H "Cookie: session=session2" --data "amount=1&from=wallet1&to=wallet2"

# 2. Send the confirmation request simultaneously using both sessions
# The '&' symbol forces the command to run in the background concurrently
curl starbucks/step2?confirm -H "Cookie: session=session1" & 
curl starbucks/step2?confirm -H "Cookie: session=session2" &

# 1. Prepare two different, concurrent sessions (session1 & session2)
curl starbucks/step1 -H "Cookie: session=session1" --data "amount=1&from=wallet1&to=wallet2"
curl starbucks/step1 -H "Cookie: session=session2" --data "amount=1&from=wallet1&to=wallet2"

# 2. Send the confirmation request simultaneously using both sessions
# The '&' symbol forces the command to run in the background concurrently
curl starbucks/step2?confirm -H "Cookie: session=session1" & 
curl starbucks/step2?confirm -H "Cookie: session=session2" &

The Result: Before the first request could clear the session, the second request was already initiated, using the original available fund balance. This allowed the user to effectively send two dollars while only having one dollar debited, leading to unauthorized, free credit on the cards.

This scenario, where a user avoided the use of the browser and made the request directly to the application, was never considered by the developers, creating the race condition vulnerability.

How to Find Race Condition Vulnerabilities

Finding vulnerabilities such as this requires the use of specialized tools that can bypass the browser’s typical sequential flow and send concurrent requests.

Using the Repeater Tool for Analysis

The best way to test for potential race conditions and other logic flaws is by using the Repeater tool available in most HTTP proxies, like Burp Suite. This tool allows you to modify an application’s request parameters and analyze the response with little effort, making it ideal for fast, repetitive testing.

1. Intercept the Request: In your proxy tool (e.g., Burp Suite), stop a normal request flow by making sure the Intercept is on in the Proxy tool.
2. Send to Repeater: Use the secondary button (right-click) on the intercepted request to show the context menu, and then select Send to Repeater.
3. Test and Modify: The next time you want to send the same request to see how the application responds to specific modifications (e.g., changing the amount, skipping a step, or changing a user ID), you don’t need to follow the entire application flow. You can simply make your modification in the Repeater tab and click Send repeatedly.

The Power of CURL for Proof of Concept

For this particular vulnerability, the researchers used CURL to make their proof of concept.

CURL is a powerful command-line tool used to make requests (HTTP, FTP, etc.) directly from the console to an application. It is often used to automate requests in a script, making it a powerful utility for bug bounty hunters and developers alike.

To learn more about CURL and its ability to automate and sequence requests, you can type the following from the command line in any UNIX-like system:

man curl 

man curl 

By combining the manual analysis of request structure (using the Repeater) with the ability to execute high-speed, concurrent requests (using tools like CURL or the Intruder tool in Burp Suite), security researchers can successfully uncover these rare and high-impact race condition flaws.

Binary.com — Stealing a User’s Money

On November 14th, 2015, bug bounty hunter Mahmoud G. published details of a critical vulnerability in Binary.com that allowed him to steal money from user accounts by modifying a single parameter in a payment request.

The Exploit:

Mahmoud G. set up two different accounts (Account A and Account B) and logged into them in two separate web browsers.

1. Initiating Deposit: Using the first browser (Account A), he began the process of depositing money, which generated a specific transaction call.
2. The Flaw: The key request included a PIN parameter that was used by the application to identify the user who would receive the deposit.
3. The Attack: In the second browser, Mahmoud G. intercepted the transaction request and simply modified the PIN parameter to the value associated with Account B.

The application’s logic failed to perform a simple authorization check: it trusted the PIN parameter to define the destination account, regardless of the user who initiated the transaction. The result was that the money deposited by Account A was received by Account B (the attacker’s account), allowing for unauthorized fund transfer.

Tip for Identifying Parameter-Based Flaws

To identify this type of critical vulnerability, you need to be systematic:

• Test with Multiple Users: Analyze each application feature using at least two users of each authorization level that the application supports.
• Parameter Scrutiny: Analyze all requests using an HTTP proxy and attempt to determine the function of every single parameter. Pay special attention to variables that look like control flow variables (user_id, PIN, account_number, is_admin) and try swapping their values between your different accounts.

HackerOne — Signal Manipulation (Reputation Flaw)

This is one of the easiest bugs ever reported, demonstrating that high-impact logic flaws don’t always require advanced technical skills.

On January 6th, 2016, a bug bounty hunter named Ashish Padelkar published a bug related to the HackerOne platform itself.

The Flaw:

In a bug bounty platform like HackerOne, a researcher’s reputation (signal) is crucial, as it grants access to better-paying private programs and ensures quick report responses.

Ashish Padelkar found that if a user created a new security report and then immediately closed it themselves, their reputation score would unexpectedly increase. This was a clear, unintended flaw in the development process: the logic for granting “signal” was triggered by the creation/closure event, even though the report was never accepted or acted upon by a security team.

Tip for Identifying Simple Logic Flaws

Offering a specific, technical tip to identify these types of vulnerabilities is difficult because they defy pattern. The only recommendation here is to have a comprehensive and creative mindset: test every single feature you find in the application’s interface (and behind the scenes) and note any unexpected behavior. Perform a manual map to find all possible flaws, no matter how simple or low-impact they seem initially.

Shopify — S3 Buckets Open (Configuration Flaw)

On February 23rd, 2016, a bug bounty hunter named Simon Brakhane found that some of Shopify’s storage buckets, created in the Amazon S3 service, were openly accessible.

The Flaw:

The vulnerability was due to a misconfiguration: the buckets were open because of an overly permissive “any authenticated AWS user” rule. This vulnerability provides full read/write access to any user who simply has an active AWS account, even if they are not associated with Shopify.

This vulnerability, while reported as an application logic vulnerability, is also related to the configuration management category.

Automated Tools for Finding Configuration Flaws

Vulnerabilities like the Shopify S3 misconfiguration can often be detected by automated tools that perform vulnerability assessments on infrastructure.

Nessus is one of the most popular tools in this category, developed by Tenable. These kinds of tools perform automated vulnerability assessments, mostly by using signatures, to detect potential weaknesses in network services, infrastructure, and configuration.

Using Nessus for Vulnerability Assessment

Nessus is focused on infrastructure vulnerabilities but includes web security policies for frameworks and CMS platforms.

1. New Scan: Start by going to Scans and clicking New Scan.
2. Policy Selection: You can choose a preconfigured policy, or, for maximum coverage, select Advanced Scan to select each policy by group.
3. Target and Aggression: In the next view, you define the targets (IP addresses or domain names).
   • Private/Aggressive Programs: If you are in a private program with a network exception, we recommend using an Advanced Scan with all policies selected. This scan will be aggressive, generating a lot of traffic.
   • Open/Sensitive Programs: If you are in an open program, configure the scan to be the least aggressive one possible to avoid being blocked by network security controls (like an Intrusion Prevention System or Load Balancer).
4. Plugins: In the Plugins section, select the policies based on the information you have (e.g., skip Windows policies if the server is confirmed to be Linux). The more personalized the set of plugins, the better the result.
5. Review the Report: After the scan finishes, the vulnerabilities are displayed in the report. Click on them for details, which sometimes include whether an exploit is available.

It is crucially important to clarify that all the vulnerabilities detected by Nessus or other vulnerability analysis tools are potential, and not manually confirmed. Even if a tool confirms the vulnerability by a clue (fingerprint or banner grabbing), you must confirm each vulnerability manually, as these tools only try to verify by behavior and may report false positives.

HackerOne — S3 Buckets Open (Configuration Logic)

On March 29th, 2017, bug bounty hunter InjectorPCA reported gaining unauthorized access to Amazon S3 storage buckets used by the HackerOne platform itself.

The Flaw and the Lesson:

This bug was structurally similar to the previous Shopify S3 error, stemming from a misconfigured Access Control List (ACL) that allowed unintended access. The core lesson here is critical for all bug hunters:

• Reproduce Previous Flaws: Try to reproduce the previous, publicly known vulnerabilities (especially configuration errors) on the application you are assessing. There’s no need to reinvent the wheel; common infrastructure and logic flaws are often copied across different services.
• Automated Scanning: It’s highly recommended to launch an automated vulnerability scan to all targets included in the bounty at the beginning of your assessment. You should also launch a port scan and service detector using a specific tool like Nmap to accurately map the infrastructure and services running, regardless of what the general vulnerability assessment tools do.
• Impact Evidence is Key: When reporting such a configuration flaw, you must be clear in your evidence about the impact. InjectorPCA demonstrated the consequence of having access to HackerOne’s buckets by showing a list of directories and proving he could upload and delete files, validating full access.

GitLab — Bypassing 2FA Authentication

In 2016, a bug bounty hunter named José Torres published a critical logic vulnerability that allowed him to sign in to a GitLab account without knowing the user’s password, effectively bypassing Two-Factor Authentication (2FA).

Understanding Two-Factor Authentication (2FA)

Traditionally, applications use a single factor (username/password) to grant access. 2FA enhances security by requiring a second, independent factor—something the user has (like a phone or physical token) or is (like a fingerprint). The basic idea is that the user signs in with their password (first factor), and then the application asks for extra data (the second factor, like an SMS code or a token).

The GitLab 2FA Bypass

José Torres found that GitLab’s sign-in module, when processing 2FA, relied on a parameter that could be manipulated.

He intercepted the request sent to the application after entering the password:

POST /users/sign_in HTTP/1.1
Host: 159.xxx.xxx.xxx
...
Content-Disposition: form-data; name="user[otp_attempt]"
212421
...

The application logic associated the otp_attempt (the one-time password) with the current session. José Torres modified the request by adding a hidden field to the form data:

POST /users/sign_in HTTP/1.1
Host: 159.xxx.xxx.xxx
...
Content-Disposition: form-data; name="user[otp_attempt]"
212421
----------1881604860
Content-Disposition: form-data; name="user[login]"
212231
----------1881604860--

By adding the victim’s login ID (212231) and sending the request, the application’s faulty logic associated the current session’s valid 2FA code with the different login ID of the victim. The attacker could then log in with the victim’s ID, even without having the victim’s password.

Tips for Identifying Authentication Flaws

The core vulnerability was that the application decoupled the session ID from the user being authenticated in the second factor. The tips to identify these kinds of vulnerabilities are:

• Analyze and Map Every Parameter: Analyze each request and try to understand the function of every value and parameter sent. Even if they are hidden parameters, they are sometimes more important than visible ones, as they control internal application flow.
• Test with Different Values: Don’t just enter testing strings (for XSS/SQLi). Check what happens if entered data has a valid structure but different values. For example, try substituting your own valid 2FA code for a different user’s ID. These parameters are often in charge of controlling the application’s flow and can be manipulated for logic bypass.

Yahoo: PHP Info Disclosure

In 2014, bug bounty hunter Patrik Fehrenbach found a file showing the phpinfo() result on a Yahoo server. This is a common issue arising from development or testing files being left exposed on a production server. The phpinfo() function displays extensive information about the PHP environment, including server configurations, paths, environment variables, modules, and sometimes even database credentials. This is a goldmine for an attacker.

The tips to detect these kinds of issues primarily involve file enumeration (also known as fuzzing or directory busting).

Method 1: File Enumeration with Burp Intruder

You can use a proxy tool’s fuzzer, such as Burp Intruder, to automatically test an extended list of common sensitive file names and paths against an application:

1. Load Payloads: In the Intruder tool’s window, navigate to the Payloads tab. Load a file containing your list of common sensitive files (e.g., phpinfo.php, test.php, .env, backup.zip, admin/).
2. Set Positions (Fuzzing the Path): Navigate to the Positions tab. Normally, you select variables to test, but here, you will launch the Intruder attack against the file path. You create an imaginary variable (or placeholder) in the path portion of the request (e.g., GET /FUZZ/index.html) to select the exact position where your file names will be inserted.
3. Launch and Analyze: Launch the attack. Analyze the results, specifically looking for an HTTP 200 OK error code. A 200 code means the file exists and was successfully retrieved. This is a simple and relatively quiet way to detect “juicy” files and paths without generating excessive traffic that could be flagged by security controls.

Method 2: Automated Web Application Scanners (Acunetix)

Another method to detect this type of issue is by using a vulnerability scanner focused on applications, rather than an infrastructure scanner like Nessus. Acunetix is a popular example, and most application scanners follow a similar basic flow:

1. Enter Target: Use the wizard to enter the target (IP address or domain name).
2. Select Profile: Select a profile, which is the set of rules to scan the application. You can be selective to avoid triggering security controls or to focus on specific vulnerability types (e.g., only sensitive file checks).
3. Technology Detection: The tool may configure improvements to the scan by first detecting the technology used in the application.
4. Launch and Review: Launch the scan. Acunetix will show findings, including sensible files and paths, as well as common flaws like XSS and SQLi.

Crucial Reminder: Remember that no automated tool can detect application logic vulnerabilities by itself; human intervention is always necessary to understand and exploit the underlying design flaws. Automated scanners are best used for finding common patterns and configuration errors that may then lead a human researcher to a logic flaw.

Summary: Mastering Application Logic Vulnerabilities

Application logic vulnerabilities are the most valuable bugs for a bug bounty hunter. Although they are hard to find, they have the greatest potential impact on an application’s core functions, and you are significantly less likely to get a duplicate when reporting them.

To summarize the essential information from this chapter on successfully hunting logic flaws:

Think Outside the Box: Avoid the developer’s thought paradigm. Challenge every assumption and test scenarios that the original design was not intended to handle.

Understand the Flow: Always use an HTTP proxy to meticulously analyze network traffic, focusing on variables and parameters that could be used to control or manipulate the application’s intended flow.

Automate Reconnaissance: Launch automated tools (like Nmap, Nessus, and application scanners) for port scanning, vulnerability assessments, and configuration management issues at the beginning of your assessment.

Replicate Known Flaws: Be sure to replicate previous, publicly known configuration and logic vulnerabilities on the application you are currently assessing.