13

  1. 是X-Amz-Expires必需的标头/参数吗？官方文档不一致，在某些示例中使用它，而在其他示例中则没有。

  2. 如果不需要，签名请求的默认过期值是多少？它是否等于X-Amz-Expires参数的最大可能值，即604800（7 天）？

  3. 文档（请参阅上面的链接）X-Amz-Expires仅在查询字符串中传递签名参数的上下文中讨论参数。如果X-Amz-Expires需要参数，是否只需要在查询字符串中传递签名参数（而不是通过授权标头传递它们）？

更新：

AWS 安全流程简介论文，第 17 页说

请求必须在请求时间戳的 15 分钟内到达 AWS。否则，AWS 会拒绝该请求。

现在我们在这里谈论什么时间戳？我的猜测是X-Amz-Date。如果我是对的，那么就会出现另一个问题：

  1. X-Amz-Date和参数如何X-Amz-Expires相互关联？对我来说，如果不存在，这听起来像是请求过期算法从X-Amz-Date时间戳回落到 15 分钟。X-Amz-Expire
4

1 回答 1

16

是X-Amz-Expires必需的标头/参数吗？

X-Amz-Expires仅与查询字符串身份验证一起使用，而不与Authorization:标头一起使用。

查询字符串身份验证没有默认值。它是必需参数，如果X-Amz-Algorithm=AWS4-HMAC-SHA256查询字符串中存在但X-Amz-Expires=...不存在，服务将拒绝请求。

<Error>
  <Code>AuthorizationQueryParametersError</Code>
...

现在我们在这里谈论什么时间戳？

这是指X-Amz-Date:与Authorization:标题一起使用时。因为X-Amz-Date:是签名算法输入的一部分，所以日期或时间的更改也会更改签名。早于或晚 1 秒签名的其他相同请求具有完全不同的签名。AWS 本质上允许您的服务器时钟最多出错 15 分钟，而不会破坏您对请求进行身份验证的能力。它不是后备或默认设置。这是一个固定的窗口。

AWS将X-Amz-Date:基于Authorization:标头的请求与其系统时间进行比较，系统时间当然与 UTC 同步，如果在请求到达时该值与 UTC 偏差超过 15 分钟，则请求将被拒绝。在时间检查之前不会发生与身份验证相关的其他验证。

Query String 身份验证过期的验证涉及不同的逻辑：

  • X-Amz-Expires不得为大于 604800 或小于 0 的值；否则，请求将立即被拒绝，无需进一步处理，包括类似于上述消息的消息。
  • X-Amz-Date根据 AWS 系统时钟，未来不得超过 15 分钟。错误是Request is not yet valid。
  • X-Amz-Date相对于 AWS 系统时钟，不得超过X-Amz-Expires过去的秒数，并且不适用 15 分钟的容差。错误是Request has expired。

如果出现任何这些情况，则不会对签名进行进一步验证，因此这些消息不会根据签名的有效性而改变。这是首先检查的。

此外，您最左边的 8 个字符必须与标题组件的X-Amz-Date:日期部分匹配。日期本身对凭证的差异零容忍（因此，在签名时，不要两次读取系统时间，否则您可能会在 UTC 午夜前后偶尔生成无效签名）。CredentialAuthorization:

最后，请求在处理过程中不会过期。如果您使用任一签名方法发送请求，该请求在到达时被视为有效，但此后很快就会过期，则始终允许它运行到完成——例如，大型 S3 下载或 EBS 快照创建请求将不会启动，然后无法继续，因为在 AWS 端已经开始请求时到期计时器已触发。如果该操作在请求时被授权，则它会继续并正常成功。

于 2016-09-18T06:21:27.203 回答