Decode-Path Attack Surface

## The grammar allows what the data model does not define A self-describing text encoding defines two separate things, and conflating them is what makes this question interesting. The **grammar** says which byte sequences are a document: an object is an opening brace, zero or more `name: value` members separated by commas, a closing brace. The **data model** says what a document *means*: an object denotes a mapping, and a mapping holds one value per name. Nothing in the grammar prevents a document from spelling the same name twice. JSON's own text says member names **should** be unique and warns that behaviour is unpredictable when they are not — that is guidance to whoever writes the document, not an obligation the decoder is required to enforce. So `{"role": "user", "role": "admin"}` is syntactically valid and semantically undefined. Undefined does not mean nothing happens: a decoder still has to hand something back to its caller, so it resolves the repeat in whatever way its implementation makes natural. ## The resolutions you actually meet | Resolution | What the caller receives | How it arises | |---|---|---| | Last occurrence wins | the final value | build a map, assign on each member, overwrite silently | | First occurrence wins | the earliest value | insert only when the name is not already present | | Reject the document | a decode error | a strict mode that tracks the names it has seen | | Keep every occurrence | a list, or two callbacks | an order-preserving structure, or an event-streaming decoder | A fifth shape appears in decoders that bind a document straight into a typed structure: the repeat hits one field twice, and whether the second assignment overwrites the first, is ignored, or raises an error is a property of the binder, not of the format. Configuration matters as much as the implementation — the same decoder often has a strict switch that changes which row of the table applies. Every row is a defensible reading of an under-specified input. The vulnerability is not in any one of them. ## Two decoders in one path The shape that turns this into a finding is a request body parsed twice by different code: 1. A filtering proxy reads the body, decodes it with its own decoder, and evaluates a policy against the result — say, the request may proceed only when `role` is `user`. 2. The proxy approves and forwards **the bytes it received**, unchanged. 3. The service behind it decodes those same bytes with a different decoder and acts on *its* resolution. If the proxy keeps the first occurrence and the service keeps the last, `{"role": "user", "role": "admin"}` is approved as a user request and executed as an administrative one. Swap the two resolutions and the attacker simply swaps the order of the members. Neither component is misbehaving by its own specification; the security property lived in the gap between them. The sentence worth carrying out of this: **a check binds to an interpretation, but only bytes travel.** Anything that re-derives meaning downstream is free to derive a different one. ## Variations of the same shape - **Audit divergence.** A logging or audit component decodes the body one way and records `role: user`, while the actor decodes it the other way. The trail then faithfully records a value that was never applied, which is worse than no trail. - **Two decoders in one process.** A schema validator and an object binder are often different pieces of code over the same bytes. The validator may see one resolution and the binder another, so the validated document is not the constructed one. - **Nesting.** The repeat can sit several levels down, inside a member the outer component never inspects because it only reads the fields its policy mentions. ## What to propose - **Decode once and forward what you decoded.** Re-encode the document the proxy accepted, or pass a structured form onward, so no second interpretation exists. The cost is byte fidelity: anything downstream that authenticates the client's exact bytes has to be reworked. - **Fail closed on the ambiguity itself.** Configure strict decoding that rejects a repeated member name outright, at the boundary, so the undefined case never enters the system. This is cheap and does not break byte-level signatures. - **Do not authorise on a field someone re-parses.** Where a decision has been made, forward the decision — not the bytes it was made from — so the downstream component has nothing to reinterpret. ## The general rule Wherever a grammar permits an input that the data model leaves undefined, two independent implementations may diverge on it, and any pair of them in one request path is a candidate bypass. Repeated member names are the most reliable example because the divergence is total: the two decoders return different values, with no error anywhere to notice.