Oracle Classes

parlov is designed around six oracle classes. Each class targets a distinct category of information leakage, with its own probe strategy, signal analysis, and sample requirements.

Existence Oracle

Detects: Whether a server reveals resource existence to unauthorized clients.

Method: Request known-valid and known-invalid resource IDs against the same endpoint. Compare the full response surface — status code, headers, body, timing.

Classic signal: 403 Forbidden (baseline) vs. 404 Not Found (probe). The server returns a different status code depending on whether the resource exists, confirming existence to any caller who can observe the difference.

Sample requirements: 1–3 per side (adaptive — short-circuits on first sample if no differential detected).

Vectors

The existence oracle uses multiple detection vectors — distinct methods of observing the differential. Vectors define what you measure, independent of what you send.

Status-Code-Diff: The direct comparison — does the server return different status codes for existing vs. nonexistent resources? This is the primary vector and covers the majority of existence oracle patterns: 403/404, 200/404, 409/201, 422/404, 410/404, and dozens of others across all HTTP methods.

Cache-Probing: Leveraging conditional request mechanisms — validators (If-None-Match, If-Modified-Since), preconditions (If-Match, If-Unmodified-Since), and range requests (Range, If-Range) — to provoke RFC-mandated responses that differ based on resource existence. A 304 Not Modified response to a conditional GET can only occur if the server found and evaluated an existing representation. A 412 Precondition Failed can only occur if the server reached the precondition evaluation stage. A 416 Range Not Satisfiable can only occur if the server found a representation and attempted to evaluate the range against it. Each of these requires the resource to exist, creating a differential against 404.

Cache-probing is organized in three stages:

• RFC-defined representation evaluation — differentials that are mandated by protocol specifications (304/404, 412/404, 206/404, 416/404).
• Elicitation techniques — specific request manipulations that trigger those RFC-defined differentials (e.g., sending If-None-Match: * to force a 304/404 split).
• Implementation-defined cache behavior — signals created by deployment choices (CDN behavior, negative caching asymmetry, cache-state headers) rather than by protocol specifications.

Future vectors include body-diff (comparing response body content), header-diff (comparing header sets), and timing analysis (measuring response latency distributions). The analysis pipeline is designed so that all vectors run against every probe pair regardless of which strategy generated it — a probe designed for status-code-diff may also surface cache-probing signals or header-diff signals from the same response.

Authentication Oracle

Detects: Whether a server reveals valid usernames through error message differentiation on login, registration, and password reset flows.

Method: Submit authentication requests with valid and invalid usernames. Compare response bodies, status codes, and timing across failure modes.

Classic signal: "Invalid password" (valid username) vs. "Account not found" (invalid username). Even subtle differences — varying Content-Length, different JSON key ordering, distinct error codes — are signals.

Sample requirements: 1–30+ depending on signal type (body diff requires fewer samples; timing requires statistical power).

Timing Oracle

Detects: Statistically significant response time differences revealing server-side code path branching.

Method: Repeated requests (N samples) with valid and invalid inputs. Statistical hypothesis testing (Mann-Whitney U) to determine whether the time difference is real or noise.

Classic signal: Password hashing takes measurably longer for valid usernames (the server reaches the bcrypt/argon2 comparison path) than for invalid ones (the server short-circuits before hashing).

Sample requirements: 30–100+ (adaptive — starts with a minimum batch, computes preliminary p-value, extends sampling when borderline).

Verification Oracle

Detects: Cryptographic validation state leakage through error granularity — whether the server returns distinct error messages for different failure modes (expired signature vs. invalid signature vs. wrong algorithm).

Method: Submit requests with malformed signatures, expired certificates, wrong algorithms, and truncated credentials. Map the error message space.

Classic signal: "Token expired" vs. "Invalid signature" vs. "Unsupported algorithm" — each distinct error message reveals how far the server progressed through its validation pipeline.

Sample requirements: 1–3 per failure mode.

Token Validation Oracle

Detects: JWT/OAuth claim-level state leakage through WWW-Authenticate parameter variations and error message differentiation.

Method: Submit expired, wrong-audience, wrong-issuer, and malformed tokens. Diff the WWW-Authenticate header parameters and error responses across failure modes.

Classic signal: RFC 6750 allows error, error_description, and error_uri in bearer token error responses. Different parameters per failure mode (invalid_token with "token expired" vs. "invalid audience") directly leak the validation stage the server reached.

Sample requirements: 1–3 per token manipulation.

State Oracle

Detects: Whether HTTP metadata reveals session, rate-limit, or authentication state.

Method: Send identical requests across authentication contexts (unauthenticated, low-privilege, high-privilege, expired session). Compare the full header set.

Classic signal: Rate-limit headers (X-RateLimit-Remaining, Retry-After) that only appear for authenticated requests. Cache-Control: private, no-store on authenticated responses vs. public, max-age=3600 on unauthenticated ones. CSRF tokens that only appear when a session exists.

Sample requirements: 1–3 per authentication context.