I'm curious about the security implications of using overly permissive IAM permissions when generating S3 pre-signed URLs. Since these URLs are signed with the HTTP method in SigV4, can a user list objects in the bucket if their IAM role has that permission, besides just the get or put operations?
5 Answers
In terms of direct threats from the pre-signed URL, they essentially serve as temporary and limited credentials for the specific operation. However, if those credentials leak, or if someone gains access to the signing system, then they can do significantly more damage based on what the IAM permissions allow them to do.
It’s worth mentioning that pre-signed URLs can be used from anywhere. If shared through emails or texts, they can easily fall into the wrong hands. So, securing those is really important.
Essentially, a pre-signed URL is valid solely for the specific operation it grants access to. The IAM entity's permissions matter mainly when considering how secure the URL-generating program is. If it has limited permissions, even if you can trick it into generating a URL, it won’t work if access is denied for that resource. For example, if you category files, but an attacker can omit that category due to a logic flaw in your API, you might accidentally let them access sensitive files unless restricted directly.
Great point! This kind of attack falls under IDOR vulnerabilities. You’ve got to make sure your server checks permissions and validates all user inputs throughout the URL creation process.
If your IAM role only permits GetObject and PutObject, those pre-signed URLs cannot list bucket contents since listing requires ListBucket permission. It's essential to be wary of overly permissive IAM roles; if a role includes ListBucket permission, it could lead to enumerating bucket contents without needing pre-signed URLs.
Yep, this risk is present only if the same IAM role is used for actions other than just creating pre-signed URLs.
Pre-signed URLs only support get and put object operations, so if someone has a role with those permissions, they can create those URLs. The main security risk here is data exfiltration; an attacker with access could generate pre-signed get URLs to extract your data. These URLs are only valid for a set time (TTL), but once generated, they can't be revoked. Also, with pre-signed puts, a malicious actor could overwrite objects, causing various problems. Leaking the URL also poses a risk since anyone with it can use it until it expires.
Exactly! A pre-signed URL only allows the operation it was signed for. So, a pre-signed get URL can't be used to put a file. While you can't revoke the URL, you can remove permissions from the IAM role, invalidating all URLs from that key.
Right! If someone can generate pre-signed URLs, it means they either have your credentials, or there’s a flaw in your permissions setup.
Exactly! I once came across a bug bounty that exploited this before SigV4 was used, allowing users to list all objects. It's much better now with proper signing.