Boolean-based auth flaw

Why This Matters

Authentication logic flaws caused by improper boolean handling are among the most subtle yet critical vulnerabilities in web applications. PHP's loose comparison operator has been responsible for widespread authentication bypasses: CVE-2014-2238 in MantisBT and multiple WordPress plugin CVEs involved == type coercion where "0" == false and 0 == "anystring" evaluate as true. More recently, JSON body parameter injection has allowed attackers to change the type of a field from string to boolean, bypassing server-side checks that expect a string. These flaws are often invisible in black-box testing without deliberate type-manipulation probing.

Core Concept

A boolean-based authentication logic flaw arises when server-side code evaluates authentication or authorisation conditions using a boolean expression that can be manipulated by the attacker to produce an unintended true result. Unlike SQL injection, this attack does not target the database query; it targets the application's own programming logic.

Server-side boolean parameter tampering occurs when an access control decision is derived from a request parameter rather than an authoritative server-side source. A vulnerable implementation might check if ($request->get('isAdmin') == true) rather than looking up the user's role from the database session. By adding isAdmin=true or role=admin to the POST body, query string, or JSON payload, the attacker injects the desired privilege directly into the access check.

PHP loose comparison type coercion (== vs ===) creates a class of bypasses unique to PHP's type juggling rules. The == operator converts operands to a common type before comparing: 0 == "admin" is true in PHP because the string "admin" is cast to integer 0, and 0 == 0 is true. An authentication function that compares a numeric user ID to a string token, or that uses == false to detect empty values, may accept unexpected inputs as valid. The strict equality operator === compares both value and type, making these coercions impossible.

Truthy/falsy mishandling appears in multiple languages: in JavaScript, null, undefined, 0, "", and NaN are all falsy; in Python, empty strings, zero, None, and empty collections are falsy. Code that uses if user: or if token: instead of explicitly comparing against an expected type and value can be bypassed by supplying inputs that coerce to the expected truthiness.

JSON body parameter injection targets API endpoints that accept JSON. Changing {"password": "wrong"} to {"password": true} or {"password": null} can bypass type-strict validation if the server's authentication routine uses loose equality or truthy checks rather than strict string comparison.

Technical Deep-Dive

Testing parameter injection in a POST body:

POST /api/login HTTP/1.1
Host: target.example.com
Content-Type: application/json

{"username": "[email protected]", "password": "wrong", "isAdmin": true}

PHP type coercion bypass — the vulnerable code pattern:

<?php
// Vulnerable: uses loose comparison ==
function verify_token($user_token, $stored_hash) {
    // If $user_token is the integer 0, PHP casts $stored_hash to int
    // Any non-numeric hash string becomes 0
    // So 0 == "a3f2..." evaluates to TRUE
    if ($user_token == $stored_hash) {
        return true;
    }
    return false;
}

// Attack: supply token value "0" or integer 0
// verify_token(0, "a3f2c1d9...") → true (bypassed!)

// Secure: use strict comparison ===
function verify_token_safe($user_token, $stored_hash) {
    return ($user_token === $stored_hash);
}
?>

Testing JSON type manipulation with Burp Suite:

-- Original request
POST /api/authenticate HTTP/1.1
Content-Type: application/json
{"username": "admin", "password": "wrongpassword"}

-- Type manipulation variants to test:
{"username": "admin", "password": true}
{"username": "admin", "password": null}
{"username": "admin", "password": 0}
{"username": "admin", "password": []}
{"username": "admin", "password": {}}
{"username": ["admin"], "password": "anything"}

Python falsy bypass example:

# Vulnerable pattern
def check_auth(provided_token, expected_token):
    if not provided_token:   # empty string, None, 0 all bypass this check
        return False
    if provided_token == expected_token:  # reached only if truthy
        return True
    return False

# Attack: supply token = "" → not "" is True → returns False (correct)
# But: supply token = None AND expected_token = None → None == None → True!
# Or if expected_token lookup fails and returns None:
# check_auth(None, None) → True (logic flaw)

Security Assessment Methodology

1. Identify JSON and form-encoded authentication endpoints — For each, note the parameter names and their expected types. Any boolean or role-related parameter name (isAdmin, role, admin, verified) is a high-priority test target.
2. Inject boolean parameters — In Burp Repeater, add isAdmin=true, admin=1, role=administrator to POST bodies and query strings. For JSON endpoints, change string fields to true, false, null, 0, and [].
3. Test PHP-style type coercion — For authentication endpoints that compare tokens or hashes, try submitting the value 0 (integer zero in JSON, or the string "0" in form data). A bypass here indicates loose == comparison.
4. Test array and object injection — For JSON endpoints, change string fields to arrays (["admin"]) and objects ({}). Some frameworks extract the first element of an array when a string is expected, which can produce unexpected comparison results.
5. Compare responses carefully — A boolean-logic bypass may not produce an obvious "Welcome, admin!" response. Look for subtle indicators: a 200 vs 403 status, a redirect to a different path, the presence of additional response fields, or a session cookie being set.
6. Probe authorisation checks separately from authentication — Test privilege escalation in authenticated context by modifying role or isAdmin in subsequent API requests, not just during the initial login flow.

Defensive Countermeasure — Use strict type-safe comparison operators (=== in PHP, is for identity in Python) and explicitly validate the type, not just the value, of all authentication parameters; define an allowlist of accepted types per field in the API schema and reject any request whose parameter types do not match the schema before executing any authentication logic.

Common Assessment Errors

• Testing only string payloads — Testers who never change parameter types miss the entire category of type-coercion and JSON-type-injection bypasses. Always test boolean, null, integer, array, and object variants.
• Assuming JSON endpoints are immune to parameter injection — Form-encoded parameter injection is well known, but JSON type injection is often overlooked. Test both content types if the endpoint supports them.
• Missing the authorisation context — Boolean parameter injection can affect not just login but any post-authentication access control check. Test role parameters in all API endpoints, not just the login form.
• Not testing with PHP magic hash values — Several MD5 and SHA1 hashes begin with 0e followed entirely by digits. PHP's loose comparison treats these as scientific notation (0 × 10^N = 0), so two such hashes compare equal. Supply 0e hashes as token values to test this specific PHP quirk.
• Overlooking null injection — Supplying null for an expected token value can trigger equality with an uninitialised server-side variable or a failed database lookup that returns NULL.
• Not verifying persistent access — Confirm that a session cookie issued via the bypass grants real access to protected resources in subsequent requests, not just a misleading success response on the login endpoint itself.

NICE Framework Alignment

Further Reading

• PHP Type Juggling Vulnerabilities — OWASP AppSec Research (conference presentation)
• OWASP Testing Guide v4.2, OTG-AUTHN-006: Testing for Bypassing Authentication Schema — OWASP Foundation
• The Web Application Hacker's Handbook, 2nd Edition — Stuttard & Pinto (Wiley)