S3错误处理url参数有多危险 [英] how dangerous are the S3 error handling url parameters

查看:412
本文介绍了S3错误处理url参数有多危险的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

一个网站具有可以提交文件的表格,这是一个错误,当您在上载文件之前尝试访问该文件时,会从S3获得此后备,那么您认为此错误的严重性是多少?在路径上传递参数有多危险?

a website has this form where you can submit a file, there's an error in which when u try to access the file before uploading it, you get this fallback from S3, of what severity would you consider this error? how dangerous are the parameters passed on the path?

示例图片

推荐答案

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

The information in the XML error message is not sensitive.

以下是所有含义的细分:

Here's a breakdown of what it all means:

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

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

<Message>The specified key does not exist.</Message> is the human friendly description you'd see if you were accessing this resource using a library like one of the AWS SDKs.

<Key>是对象键,这是S3所称的路径,减去前导斜杠.

The <Key> is the object key, which is what S3 calls the path, minus the leading slash.

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

The <RequestId> can used for troubleshooting and tracing by the bucket owner -- it appears in the S3 access logs for the bucket, and together with the <HostId> it provides information that AWS Support can use for tracing and troubleshooting the request inside S3, if something unexpected is happening and the bucket owner doesn't understand S3's behavior.

每当由于Amazon S3中遇到错误或意外行为而需要联系AWS支持时,您将需要获取与失败的操作相关联的请求ID.获取这些请求ID后,AWS Support可以帮助您解决遇到的问题.请求ID成对出现,在Amazon S3处理的每个响应(甚至是错误的响应)中返回,并且可以通过详细日志进行访问.获取请求ID的方法有很多.

Whenever you need to contact AWS Support due to encountering errors or unexpected behavior in Amazon S3, you will need to get the request IDs associated with the failed action. Getting these request IDs enables AWS Support to help you resolve the problems you're experiencing. Request IDs come in pairs, are returned in every response that Amazon S3 processes (even the erroneous ones), and can be accessed through verbose logs. There are a number of common methods for getting your request IDs.

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

(请注意,详细日志"是指SDK提供的客户端日志,而不是服务器端.)

(Note that "verbose logs" refers to client-side logging provided by the SDKs, not server-side.)

这两个值(随每个请求而变化)也可以在HTTP响应标头中找到,如x-amz-request-idx-amz-id-2(即使在成功的请求上).它们一起在S3内部唯一地标识一个请求.从外部看,它们没有任何意义,也没有可利用的价值.

These two values -- which change with every request -- can also be found in the HTTP response headers as x-amz-request-id and x-amz-id-2 (even on successful requests). Together, they uniquely identify a request inside S3. Externally, they have no meaning and no exploitable value.

这篇关于S3错误处理url参数有多危险的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆