[ANCHOR-1215]: Anchor Platform SEP-12 IDOR via unvalidated customer id allows cross-customer KYC disclosure and payout destination overwrite

[amandagonsalves]

Description

Before this change, `Sep12Service.validateGetOrPutRequest` enforced authorization on `request.account` and `request.memo` only. When a caller supplied `request.id` without `account`, the account check short-circuited entirely, allowing any valid SEP-10 session to `GET` or `PUT` any customer record by its `id` — regardless of who created it. The `id` was forwarded unmodified to the business-server callback, so any conforming business server would act on it.

The fix introduces a `sep12_customer_ownership` table. Every successful `PUT /sep12/customer` writes the caller's identity (`stellar_account`, `memo`) as the owner of the returned `customer_id`. Subsequent `GET` or `PUT` requests that supply `id` are checked against this table: if the stored owner does not match the token, the request is rejected with 403 before the business server is called. No business server contract changes are required.

Changes

• `Sep12CustomerOwnership` / `Sep12CustomerOwnershipStore`: new core interfaces defining the ownership record model and its storage contract.
• `JdbcSep12CustomerOwnership` / `JdbcSep12CustomerOwnershipRepo` / `JdbcSep12CustomerOwnershipStore`: platform JDBC implementation backed by the new `sep12_customer_ownership` table.
• `V29__add_sep12_customer_ownership.sql`: Flyway migration creating the table (`customer_id PK`, `stellar_account NOT NULL`, `memo`).
• `Sep12Service.putCustomer`: after every successful callback response, saves `(customer_id, token_account, token_memo)` to the ownership store, overwriting any prior record on update.
• `Sep12Service.validateGetOrPutRequest`: when `id` is present and `transactionId` is absent, looks up the ownership record. If a record exists and the token's identity does not match, returns 403 before reaching the business server. If no record exists (customer predates the fix or SEP-31 first-time access), the request is allowed through with the caller's account injected, preserving backward compatibility.
• `SepBeans` / `DataBeans`: wire `Sep12CustomerOwnershipStore` into the Spring context.
• `Sep12ServiceTest`: mocked `Sep12CustomerOwnershipStore`; updated existing id-path tests; added IDOR unit tests covering mismatched account rejection, mismatched memo rejection, no-record allow-through, ownership save on PUT (plain and muxed), transactionId path bypass, and forward-account-to-callback behaviour.
• `Sep12Tests`: added `test cross-account id access is rejected` integration test — registers a victim customer (ownership row written), attempts raw HTTP `GET` and `PUT` against that `id` from a different SEP-10 session, asserts 403 on both, and verifies the victim's record is unchanged.

Acceptance Criteria

• `GET /sep12/customer?id=` with a SEP-10 token that does not own that customer returns 403.
• `PUT /sep12/customer` with `{"id":"", ...}` from a different SEP-10 session returns 403.
• The same `GET` and `PUT` succeed when issued by the token that owns the customer record.
• No ownership record (first access or pre-existing customer) allows the request through with the caller's account injected.
• The `transactionId` path is unaffected.
• All existing `Sep12ServiceTest` tests pass.

Context

HackerOne #3735379

Testing

• Unit: `./gradlew :core:test --tests "org.stellar.anchor.sep12.Sep12ServiceTest"`
• Integration: `./gradlew runEssentialTests` — covers `test cross-account id access is rejected` in `Sep12Tests`

Documentation

N/A

Known limitations

Customers created before this migration has run have no ownership record. On their next `PUT /customer`, the record is written and all subsequent id-based requests are fully enforced. Until then, id-based access for those customers falls back to the caller's account being injected, relying on the business server's own id+account consistency check.

changes done

changes done

[JiahuiWho]

LGTM! Don't forget to squash merge