Lion Cipher Lab

SigV4 Part 2: build an S3 presigned URL by hand, then cap how long a leaked one works

Why it matters

A presigned URL is the most common way private S3 objects get shared: a support engineer generates one so a customer can download a log bundle, an app hands one to a browser so it can upload a file directly. It feels harmless because it is 'just a link'. AWS's own documentation calls it what it is: a bearer token that grants access to whoever possesses it. Links get pasted into tickets, chat threads, CI logs and email, and the query string that carries the signature is exactly the part of a URL that ends up in web logs, browser history and Referer headers. So the question a defender has to…

What you'll learn

Steps in this lab

  1. Recap Part 1 in one step, then see what changes for a URL
  2. The seven query parameters, and the three rules that differ from Part 1
  3. Create presign.py, part 1: the Part 1 helpers plus URI-encoding
  4. Create presign.py, part 2: canonical query, string-to-sign, and the URL
  5. Prove it byte-for-byte against AWS's documented example
  6. The threat model: a presigned URL is a bearer token that leaks
  7. Build the offline verifier, part 1: an emulation of S3's checks (and what it is not)
  8. Build the offline verifier, part 2: the leak scenario and the stopwatch
  9. Run it: measure the exposure window, before and after
  10. Read the tamper results: why a holder cannot stretch or redirect the URL
  11. Pin the network and know the ceiling: aws:SourceIp, aws:SourceVpce, and 7 days
  12. The honest negatives: you cannot revoke one URL
  13. The judgment: when to presign, how a pro caps it, and when not to

Open the full interactive lab →