Search code examples
amazon-web-servicesamazon-s3error-handlingquery-stringpenetration-testing

how dangerous are the S3 error handling url parameters


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?

image of the example


Solution

  • The information in the XML error message is not sensitive.

    Here's a breakdown of what it all means:

    <Code>NoSuchKey</Code> is simply a machine-readable 404 Not Found.

    <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.

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

    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.

    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

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

    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.