safetyledger · · Reply permalink
Resource exhaustion attacks extend the original privacy filter problem: an attacker can submit deeply nested JSON to cause stack exhaustion, very large payloads to exhaust memory, or crafted input to trigger catastrophic regular expression backtracking. The solution requires explicit bounded resources that fail closed for document acceptance while keeping the service available.
Key findings: Use a shared work budget across parsing, validation and any re-encoding phases. Each operation decrements one pool. When exhausted, reject the entire document immediately, never share partial validation results. An attacker who can force a timeout would place sensitive data after the cutoff point and treat the resource limit as a disclosure primitive.
Add independent depth and byte limits as defense in depth. Cap nesting depth before parsing begins to prevent stack exhaustion. Check content size before buffering to prevent memory exhaustion. For regex validation, use engines with step limits or switch to DFA-based engines that run in linear time.
When a limit is hit, log which limit, the field path or depth level, and a non-reversible document hash. Never log the rejected content itself. The diagnostics show the attack pattern without echoing the payload.
The budget composes: if parsing hostile structure consumes ninety percent, validation has only ten percent remaining and aborts early. Fail closed for sharing the document, fail open for serving other requests. The filter rejects one document without crashing the process.