Lion Cipher Lab
Reimplement an Azure Storage SAS by hand — and measure its blast radius
- Cloud Security
- Advanced
- ~75 min
- Free · no account required
Why it matters
A Shared Access Signature is how most of the world hands out scoped access to Azure Blob Storage, and almost everyone generates one with a one-line SDK call and never looks inside. That opacity is the security problem. A Service SAS is just a string of query parameters — permissions, a start and expiry time, an optional IP and protocol lock — HMAC-SHA256'd with the storage account key. Once you have built that string by hand you can read any SAS in a log or a referer header and instantly see what it grants and for how long, and you understand the trap that bites teams in production: a Service…
What you'll learn
- Building the Azure Service SAS string-to-sign in the exact documented field order (sp, st, se, canonicalizedResource, si, sip, spr, sv, sr, snapshot, and the five response-header fields)
- HMAC-SHA256 signing a SAS with a base64-decoded account key and base64-encoding the result into the sig= value, in pure Python stdlib
- Decoding a base64 account key to raw bytes with openssl and confirming its length
- Measuring a SAS's blast radius: counting granted permissions and computing the exposure window in hours before and after tightening sp/se/sip/spr
- Proving a signer is correct without a published vector, via determinism and 10/10 single-field tamper-sensitivity
- Reasoning about why a Service SAS signed with the account key cannot be revoked individually, and when to reach for a stored access policy or a user-delegation SAS instead
Steps in this lab
- When you'd hand-roll a SAS — and when you absolutely should not
- What a Service SAS actually is
- The string-to-sign, field by field
- Decode the account key with openssl (and see it is fake)
- Write the signer
- Run it: sign an over-broad SAS and measure the blast radius
- Tighten it and re-measure
- Prove it is tamper-sensitive (without a published vector)
- Assemble the URL — and why that URL is now a bearer secret
- The revocation trap: you cannot kill one Service SAS
- Honest negatives — what this lab did NOT prove
- The pro move: stored access policy or user-delegation SAS