parlov docs

Elicitation

How probes are structured to maximize oracle signal — the probe definition format, key practices, and how required_samples drives the scheduler.

Implemented

An elicitation strategy is a method of generating probe requests designed to force a server into a state that reveals an oracle. Strategies define what to send. Vectors define what to observe. The analysis pipeline runs all vectors against every probe pair, regardless of which strategy generated it.

A strategy may be designed with one vector in mind, but any differential it produces is evaluated across all applicable vectors. A cache-probing strategy that sends If-None-Match: * targets the cache-probing vector, but the response pair also passes through the status-code-diff vector automatically. A strategy that sends a PUT with an invalid Content-Type primarily targets the status-code-diff vector (415/404), but any header differences in the responses are also captured.

Strategy Types

Strategies are organized by the type of request manipulation they employ:

Header-based — Manipulate HTTP headers to trigger server-side constraint failures. The core principle: many servers evaluate content negotiation and conditional request headers after resolving the target resource. When the resource exists, the server reaches the header-evaluation stage. When it doesn't, the server short-circuits to 404 before ever inspecting the headers.

  • Accept manipulation → 406/404 (content negotiation failure)
  • Content-Type manipulation → 415/404 (media type rejection)
  • If-None-Match / If-Modified-Since → 304/404 (conditional request)
  • If-Match / If-Unmodified-Since → 412/404 (precondition failure)
  • Range / If-Range → 206/404 or 416/404 (range evaluation)

Payload-based — Manipulate the request body to trigger schema validation or size-limit failures. Many servers parse and validate the body after resolving the resource, creating the differential.

  • Schema-invalid body → 422/404 (semantic validation failure)
  • Oversized body → 413/404 (content too large)

State-conflict — Trigger uniqueness constraint or state transition failures.

  • Duplicate creation → 409/201 (conflict on existing resource)
  • Invalid state transition → 409/404 (state-dependent rejection)

Auth/privilege — Vary credential scope to observe access-control differentials.

  • No credentials → 401/404
  • Insufficient credentials → 403/404
  • Under-scoped token → scope-dependent differential

Rate-limit — Observe whether rate limiting applies per-resource or per-route.

  • Sustained requests → 429/404 (resource-scoped throttling)

Routing/length — Observe redirect and URI-handling behavior.

  • Trailing-slash variance → 301/404 (canonical path redirect)
  • URI length boundary → 414/404 (URI too long, resource-dependent)

Risk Tiers

Every strategy carries a risk classification:

  • Safe — Read-only probes. No server state is modified. GET, HEAD, and conditional requests.
  • Method-destructive — Non-idempotent probes (POST, PATCH, PUT) that may have side-effects but avoid permanent data loss.
  • Operation-destructive — Irreversible probes (DELETE, resource exhaustion) that may cause permanent state changes.

The operator sets a risk ceiling. Only strategies at or below that ceiling are executed.

On this page