parlov docs

Cross-Method Patterns

Oracles that exploit request-level validation and apply across multiple HTTP methods under the Error Message Granularity class.

Implemented

Oracles that exploit request-level validation and apply across multiple HTTP methods under the Error Message Granularity class.

Application vs Server 404

Vector

Route-level existence oracle. Application-generated 404s differ from web server default 404s in content type, body structure, headers, and response size — revealing whether a URL pattern was routed to application code.

Example

GET /api/users/999 HTTP/1.1
Host: target.com

HTTP/1.1 404 Not Found
X-Request-Id: req_abc123
Content-Type: application/json
Content-Length: 27
{"error":"user not found"}

---

GET /api/zzz/999 HTTP/1.1
Host: target.com

HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 1245
<html><body><h1>404 Not Found</h1>...</body></html>

Leaking Response / Methodology

  • What leaks: First 404 (JSON, X-Request-Id, small payload) was generated by the application — confirming /api/users/:id is a valid route. Second 404 (HTML, large payload, no X-Request-Id) is the web server's default — confirming /api/zzz is not a valid route.
  • Detection method: Cluster 404 responses by Content-Type, Content-Length, header set, and response time.

Verbose Error Messages (CWE-209)

Vector

Stack traces, database schema details, or explicit system error messages.

  • {"error": "SQL error: incorrect syntax near 'uuid'"}
  • {"error": "NullPointerException at UserSerializer.java:142"}

These explicitly confirm the resource was resolved and triggered a specific downstream error, creating a high-fidelity existence oracle and potentially exposing internal architecture.


Elicitation: Response Clustering & Diffing

Mechanism: The core analysis methodology for diffing error payloads returned by the above elicitation techniques. When testing route definitions, infrastructure-level 404s differ from application-level 404s in structure.

Oracle Signal: Structured JSON 404 with application headers (valid route namespace) vs HTML 404 with server default headers (invalid route).

GET — Valid Route Namespace (Application 404)

GET /api/users/9999 HTTP/1.1
Host: target.com
HTTP/1.1 404 Not Found
X-Request-Id: req_abc123
Content-Type: application/json
Content-Length: 27

{"error":"user not found"}

GET — Invalid Route Namespace (Server Default 404)

GET /api/zzz/9999 HTTP/1.1
Host: target.com
HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 1245

<html><body><h1>404 Not Found</h1>...</body></html>

Mitigation: Configure web servers and reverse proxies to return normalized, generic JSON payloads that exactly match the application framework's 404 responses for missing routes.

On this page