amazon-web-services - S3 错误处理 url 参数有多危险

Question

一个网站有这个表单，你可以在其中提交文件，当你在上传文件之前尝试访问文件时，你会从 S3 得到这个后备，你会认为这个错误有多严重？路径上传递的参数有多危险？

示例的图像

标签： amazon-web-servicesamazon-s3error-handlingquery-parameterspenetration-testing

Answer 1

XML 错误消息中的信息不敏感。

以下是所有含义的细分：

<Code>NoSuchKey</Code>只是一个机器可读的404 Not Found.

<Message>The specified key does not exist.</Message>是您在使用 AWS 开发工具包之一之类的库访问此资源时会看到的人性化描述。

是<Key>对象键，也就是 S3 所说的路径，减去前导斜杠。

<RequestId>用于由存储桶所有者进行故障排除和跟踪的容器 - 它出现在存储桶的S3访问日志中，并与<HostId>它一起提供 AWS Support 可用于跟踪和排除 S3 内的请求的信息，如果发生意外情况并且存储桶所有者不了解 S3 的行为。

每当您因在 Amazon S3 中遇到错误或意外行为而需要联系 AWS Support 时，您都需要获取与失败操作关联的请求 ID。获取这些请求 ID 可以让 AWS Support 帮助您解决遇到的问题。请求 ID 成对出现，在 Amazon S3 处理的每个响应（甚至是错误的响应）中都会返回，并且可以通过详细日志进行访问。获取请求 ID 的常用方法有很多。

https://docs.aws.amazon.com/AmazonS3/latest/dev/troubleshooting.html#get-request-ids

（请注意，“详细日志”是指 SDK 提供的客户端日志记录，而不是服务器端。）

这两个值 - 随每个请求而变化 - 也可以在 HTTP 响应标头中找到x-amz-request-id（x-amz-id-2即使在成功的请求中）。它们一起唯一地标识了 S3 中的请求。从外部看，它们没有意义，也没有可利用的价值。