Anonymous Visitor Can Silently Modify Any Customer's Insurance Quote

The Vulnerability

The car-quote storage endpoint accepted a write that contained a target customer number in its body. The server merged the incoming fields into the existing stored record for that customer number and returned success. It did not check whether the calling session owned the target customer number. It did not bind the session to a customer. It did not validate that the brand on the calling token matched the brand on the target record.

A bootstrap token mint endpoint allowed anyone to obtain a valid bearer with no authentication and no challenge. A single anonymous bearer minted under any one of the five sibling brands wrote into the same shared storage namespace as every other brand.

The Attack

Two independent anonymous browser windows were used to prove the cross-session write. The victim browser bootstrapped a normal quote and owned a real customer number. The attacker browser was a completely separate window with its own challenge cookie and its own anonymous bearer, with no relationship to the victim browser.

Victim sets up a normal quote

The victim browser minted an anonymous bearer, created a quote, and wrote legitimate state into the quote-store, including a flag indicating that the car had modifications. A readback confirmed the legitimate state.

Attacker writes into the victim's customer number

The attacker browser minted its own anonymous bearer and called the same quote-store endpoint, supplying the victim's customer number in the body. The server returned 200 and merged the attacker's fields into the victim's record. The attacker had no cookie, token, or session relationship to the victim.

Victim reads back and sees attacker fields

The victim browser then read its own quote-store with its own token. The disclosure flag had flipped from "true" to "false", a marker field the attacker injected was present, and the victim's other legitimate fields were preserved by the server's merge-on-write behaviour. That preservation is exactly what makes the attack invisible to the victim mid-quote.

Cross-brand reach

A second test minted tokens for all five sibling brands and wrote into the same target record. All five returned 200 against the same single-brand storage record. One global namespace; one endpoint; five brands affected.

Persistence

Re-reading the victim record after intervening cross-brand traffic returned identical content. Saving the application's normal fields back over the top of the record did not clear the attacker-controlled fields. Only insurer-side admin tooling could purge them.

The Impact

• Persistent storage poisoning of any in-flight quote across the insurer's five sibling brands.
• Underwriting-disclosure flags can be flipped silently. The customer's downstream policy could be issued against state the customer did not declare.
• Combined with the previously accepted quote-number enumeration oracle on the same target, every customer in the insurer's customer base is reachable as a target.
• Regulatory exposure under the Australian Privacy Act (operational state tampering on insurance customers).
• Customer cannot clear the attacker's fields by completing the quote normally. Only insurer-side admin tooling can purge poisoned fields.

Remediation

• Bind the calling session to a specific customer number at session-creation. Reject writes whose target customer number does not match the session's bound customer.
• Anonymous bearer tokens should not be able to address arbitrary customer records by identifier in the request body.
• Replace merge-on-write semantics with explicit field-by-field updates inside a documented schema. Reject unknown fields.
• Brand boundaries must be enforced. A token minted under one brand should not write into another brand's records, and the storage namespace should be partitioned per brand.
• Audit all stored quote records for unexpected fields and for disclosure-flag changes that did not originate from the customer's own session.