BBC Ch 17: Application Logic Errors and Broken Access Control

Source: Bug Bounty Bootcamp by Vickie Li

Unlike injection vulnerabilities, logic errors and broken access control are triggered by perfectly valid HTTP requests. No illegal characters or malformed input are needed – the attacker simply uses the application in an unintended way.

Application logic errors (business logic vulnerabilities) exploit the legitimate flow of an application to cause unintended outcomes.

A three-step login (password → MFA code → security questions) may redirect users to step 3 after step 2, but not verify that step 2 was actually completed. An attacker can navigate directly to https://example.com/security_questions/ and skip MFA entirely.

An online shop verifies credit cards only when a new card is used. It determines whether a card is new by checking for the presence of a saved_card parameter. Submit saved_card=1 alongside a fake card number to bypass card verification and order items without payment:

POST /new_order
item_id=123&quantity=1&saved_card=1&card_number=0000-0000-0000-0000

Admin panels may be hidden at obscure URLs but accessible without authentication:

• https://example.com/YWRtaW4/admin.php (base64 of “admin”)
• https://example.com/wp-admin/admin.php (WordPress default)

Common bypasses:

• Sending requests from a trusted internal IP (via SSRF)
• Adding a cookie: admin=1
• Browsing directly to the post-login page (e.g., /dashboard.php) without going through the login step

If a file parameter is passed directly to a file-read operation without sanitization:

http://example.com/upload?file=../../../../../etc/shadow

The ../ sequence escapes the uploads directory and traverses to the filesystem root. Target files: /etc/shadow (hashed passwords), config files, log files, source code.

• Verify each step in multi-step flows independently – don't assume steps were completed in order
• Implement access control at every endpoint, not just entry points
• Make access control consistent across all access methods (mobile, API, desktop)
• Sanitize file path parameters; use an allowlist of permitted files
• Audit access control code for bypasses; conduct penetration tests

Browse the application as a normal user. Read engineering blogs, documentation, and release notes. New features are often the least tested. Learn business rules: what actions should be allowed for which user roles?

Proxy all traffic. Note every request involved in:

• Payment and checkout flows
• Authentication and MFA steps
• Role-based feature access
• File access and download

For each request, identify parameters that control:

• Payment amount or type
• Current authentication step
• User identity or role
• File paths

Try these common manipulations:

• Remove or skip steps in a multi-step flow (directly navigate to later URLs)
• Add admin=1 or role=admin to cookies or parameters
• Change payment amount to 0 or 0.01
• Switch payment type from credit card to gift card with an invalid gift card ID
• Access admin endpoints like /wp-admin/ or /admin/dashboard without logging in
• Use ../ sequences in file parameters to read outside the intended directory
• Add a user_id parameter to endpoints that normally identify users via session cookie

• Admin panel with code execution → RCE
• Config file access → find database credentials, API keys, CVE-applicable software versions
• Credential files → lateral movement to other systems on the network
• Logic error combined with another vulnerability → greater impact

1. Learn the application: business rules, user roles, authentication flows, payment logic.
2. Intercept and catalog every sensitive request with a proxy.
3. Attempt to skip steps in multi-step flows, access post-login pages directly, or add admin cookies.
4. Try directory traversal on file parameters; check for exposed admin panels.
5. Escalate findings; draft report explaining the business impact and how the flaw can be exploited.