carlos / platform Public

plan: the one tagging route IAM cannot close, and it is the common one

Discussion #19. Third finding in the same property, and the worst.

A POST-policy form upload — the browser-direct pattern, where an app
signs a policy and the browser POSTs a multipart form straight to S3
without the bytes passing through the app — carries its tags in a form
FIELD. Against MinIO, with the s3:RequestObjectTagKeys Deny in place
that closes every other route, an upload carrying carlos-scan=clean
SUCCEEDS. 204. The control in the same run passes, so the route works
and the Deny simply does not fire: the gateway does not populate that
condition key for the handler.

So an app marks its own uploads clean at the moment it stores them, the
sweep finds a version-matching clean tag and never scans the object, and
the status door reports clean forever.

This is the worst of the three because it is not an exotic call an
attacker reaches for. It is the standard way to take a file from a user
— which is exactly the workload object-storage scanning exists for.

IAM DOES NOT REACH IT. There is no condition key describing "this is a
form upload", and a bucket policy uses the same keys. The fix is to make
the tag unforgeable rather than unwritable: a signed fourth tag,
HMAC(deployment key, bucket|key|version|verdict|at), verified in
readTag, so a tag that does not verify is treated as no tag and the
object gets scanned — failing in the safe direction. That closes every
route at once, including the ones nobody has thought of yet, and demotes
the IAM Denys to defence in depth, which is the right job for them.

It needs a key the console does not have. By deliberate design it holds
only CARLOS_SECRETS_PUBKEY — apiconfig.go says so in as many words — so
this is a new deployment secret, the same machinery §6.3 introduces for
callback signing. That is a design decision, not a patch, and it should
be decided once and used for both. Not something to invent at one in the
morning.

THE TEST IS NOT COMMITTED, and that is deliberate. AGENTS.md requires
the suite clean before a commit lands, and a red assertion on the branch
is the known-failing test this repo has just spent a night paying for
once. The full reproduction — both subtests and the hand-rolled SigV4
POST-policy helper, since the AWS SDK for Go has no presigner for it —
is in #19 and drops straight back in when the fix lands. Nothing is lost
but the red.

It gates THE FIRST MEMBER GRANT, not the first deploy. Rollout steps 1-4
are inert. The moment a member's store is granted and swept, a clean
verdict is being reported, and this is the route by which it can be
false.

Also recorded: the two routes that turned out to be already closed —
multipart and copy-with-REPLACE — are done and pinned, and the version-
tagging actions are in.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PEkJh1ESqiA84quAHJV4K6