pre-signed-url · L3

server 端驗證流程

server 端怎麼驗簽章

一句話：server 不「解密」簽章——它照同一套 SigV4 重算一次，再跟網址帶來的 X-Amz-Signature 比對。相等就是真的，不等就拒。

驗三件事

(1) 重算簽章比對：用網址裡的參數（除了 X-Amz-Signature），照 canonical request → String to Sign → Signature 再算一遍。它靠 X-Amz-Credential 裡的 access key ID，查出自己存的 secret key、長出同一把 Signing Key。算出結果跟 X-Amz-Signature 不符 → 回 SignatureDoesNotMatch。
(2) 判斷過期：用 X-Amz-Date + X-Amz-Expires，在「請求當下」看是否還在有效窗口。過了 → AccessDenied（Request has expired）。
(3) 檢查權限：那組憑證此刻是否仍有效、仍有權做這件事——撤銷/停用/STS session 過期，都會讓沒到期的 URL 也失效（Level 1 的「第二層檢查」）。

為什麼「改 URL 任一被簽參數、簽章就失效」

因為 server 重算時，會把改過的參數當輸入。輸入變了 → canonical request 變了 → 算出的簽章就跟原本那段對不上。所以你不能偷偷把 X-Amz-Expires 改大、或換個物件 key——一改，簽章立刻不合。

為什麼攻擊者補不出正確簽章

攻擊者拿得到整條 URL（它是 bearer token、攤在網址上），但他算不出「改過之後」該有的新簽章——因為算正確簽章要有正確的 Signing Key，而 Signing Key 要用 secret key 才長得出來，secret key 只在 server 和簽署者手上，不在網址裡。這就是整套機制的安全根基：驗證靠重算比對，偽造靠 secret key，而 secret key 從不外流。

一張圖收尾

收到請求
  │
  ├─ 用參數重算簽章 → 跟 X-Amz-Signature 比  ──不符→ SignatureDoesNotMatch
  ├─ 看 X-Amz-Date + X-Amz-Expires 是否過期  ──過期→ AccessDenied (expired)
  └─ 查該憑證此刻是否仍有效/有權            ──無權→ AccessDenied
        │全過
        ▼  放行

參考來源