AWS AmazonS3 documentation change
Summary
Updated presigned URL documentation with checksum algorithm support details, credential expiration clarifications, and added FAQ section addressing common errors
Security assessment
The changes clarify checksum algorithm support (improving data integrity guidance) and add security-focused FAQs about credential expiration and error troubleshooting. While these enhance security awareness, there's no evidence they address a specific active vulnerability.
Diff
diff --git a/AmazonS3/latest/userguide/using-presigned-url.md b/AmazonS3/latest/userguide/using-presigned-url.md index 4163b49f6..d5c6b1818 100644 --- a//AmazonS3/latest/userguide/using-presigned-url.md +++ b//AmazonS3/latest/userguide/using-presigned-url.md @@ -5 +5 @@ -Who can create a presigned URLExpiration time for presigned URLsLimiting presigned URL capabilities +Who can create a presigned URLExpiration time for presigned URLsLimiting presigned URL capabilitiesFrequently asked questions for presigned URLs @@ -28 +28 @@ When you create a presigned URL, you must provide your security credentials, and -Currently, Amazon S3 presigned URLs don't support using the following data-integrity checksum algorithms (CRC32, CRC32C, SHA-1, SHA-256) when you upload objects. To verify the integrity of your object after uploading, you can provide an MD5 digest of the object when you upload it with a presigned URL. For more information about object integrity, see [Checking object integrity in Amazon S3](./checking-object-integrity.html). +When using presigned URLs to upload objects, you can verify object integrity using checksums. While presigned URLs created with AWS Signature Version 2 only support MD5 checksums, presigned URLs created with AWS Signature Version 4 support additional checksum algorithms including CRC-64/NVME, CRC32, CRC32C, SHA-1, and SHA-256. To use these additional checksum algorithms, ensure you're using AWS Signature Version 4 and include the appropriate checksum header in your upload request. For more information about object integrity, see [Checking object integrity in Amazon S3](./checking-object-integrity.html). @@ -37,0 +38,2 @@ Currently, Amazon S3 presigned URLs don't support using the following data-integ + * Frequently asked questions for presigned URLs + @@ -51,4 +52,0 @@ The following are the types of credentials that you can use to create a presigne - * **IAM instance profile** – Valid up to 6 hours. - - * **AWS Security Token Service** – Valid up to maximum 36 hours when signed with long-term security credentials or the duration of the temporary credential, whichever ends first. - @@ -58,0 +57,8 @@ To create a presigned URL that's valid for up to 7 days, first delegate IAM user + * **Temporary security credentials** – Can't be valid for longer than the credentials themselves. These credentials include: + + * **IAM role credentials** – The presigned URL expires when the role session expires, even if you specify a longer expiration time. + + * **IAM role credentials used by Amazon EC2 instances** – Valid for the duration of the role credentials (typically 6 hours). + + * **AWS Security Token Service credentials** – Valid only for the duration of the temporary credentials. + @@ -133,0 +140,18 @@ The following IAM policy statement requires the principal to access AWS only fro +## Frequently asked questions for presigned URLs + +###### Q: Why do my presigned URLs expire earlier than the configured expiration time? + +remain valid only while their underlying credentials are valid. A presigned URL expires at either its configured expiration time or when its associated credentials expire, whichever occurs first. For Amazon Elastic Container Service tasks or containers, role credentials typically rotate every 1-6 hours. When using AWS Security Token Service (AWS STS) AssumeRole, the presigned URL expires when the role session ends, which by default is 1 hour. For Amazon EC2 instance profiles, metadata credentials rotate periodically with a maximum validity period of approximately 6 hours. + +###### Q: Why am I getting a 403 Forbidden error when accessing a presigned URL? + +Before generating a presigned URL, verify that you have the correct permissions configured. The IAM user or role generating the URL must have the required permissions, such as `s3:GetObject`, for the specific operation. Additionally, check that the Amazon S3 bucket policy doesn't explicitly deny access to the object. + +###### Q: I'm getting `SignatureDoesNotMatch` errors. How do I fix this? + +If you encounter `SignatureDoesNotMatch` errors when using Amazon S3 presigned URLs, consider several common causes. First, ensure that your system clock is synchronized with a Network Time Protocol (NTP) server, as even small time drifts can invalidate signatures. Next, be aware that some corporate proxies might modify headers or query strings, potentially causing signature mismatches. To troubleshoot, try testing without the proxy. Finally, verify that all request parameters—including the HTTP method, headers, and query string—match exactly between URL generation and usage. Addressing these issues can often resolve `SignatureDoesNotMatch` errors. + +###### Q: I'm getting `ExpiredToken` errors. What should I do? + +When you receive `ExpiredToken` errors while using presigned URLs, it indicates that the AWS credentials used to generate the URL are no longer valid. To resolve this issue, refresh your AWS credentials before generating new presigned URLs. For long-running applications, we recommend implementing credential refresh logic to maintain continuous access. Where appropriate, you can use longer-lived credentials or implement token refresh mechanisms. If you're using AWS Security Token Service (AWS STS) AssumeRole, verify that your configured session duration meets your use case requirements. Remember that presigned URLs remain valid only for the duration of their underlying credentials, so implementing proper credential management is essential. +