is there a way to limit access to s3 presigned url - amazon-web-services

I have a use case of allowing users to access remote file present in s3. Currently I am sending the pre-signed url in an email and allowing access. But I have a use case that is not met with this solution.
That being, in case the email containing the pre-signed url is forwarded to someone unintended, the forward recipient should not be able to access the file. Is there a way of authenticating an s3 presigned url by means of id/password. I am also open to a different solution using other AWS services as well to meet the use case.

Pre-signed URLs aren't particularly good for emails.
The intention with a pre-signed URL is that a user would authenticate to an application, then request access to some private content. The application would verify that they are permitted access, then provide a pre-signed URL to grant time-limited access to the content. Such access would normally be for up to 5-10 minutes.
As demonstrated by your scenario, there is an issue if somebody forwards a pre-signed URL to somebody else. This is normally not a problem because access time is limited. However, if a pre-signed URL is generated that has access for hours or days, it becomes more of a security issue.
Solution: Provide a link to your application. Users should authenticate, then be provided with a short-duration (eg 5-minute) pre-signed URL. This lowers the chance that other people can use the link.

By default you can't limit who can use the pre-sign url. The entire purpose of pre-signed S3 urls is to enable access to your object to anyone who has them for a limited time:
Anyone who receives the presigned URL can then access the object.
If this does not suit you, you have few choices:
don't use pre-signed urls, but instead create an IAM user which just the permissions to download the object. This will require login to the AWS by your recipients.
use password protected 7zip or rar files that contain your objects. So instead of downloading objects directly, you provide pre-signed urls to password-protected archives.
use encryption and share encrypted files. You clients will need to decrypt them.
and many others
But ultimately they will be as save as your users' passwords, encryption keys or other types of protection you will implement.

Related

AWS S3 Per Bucket Permission for non-AWS accounts

This question is in the same line of thought than Is it possible to give token access to link to amazon s3 storage?.
Basically, we are building an app where groups of users can save pictures, that should be visible only to their own group.
We are thinking of using either a folder per user group, or it could even be an independent S3 bucket per user group.
The rules are very simple:
Any member of Group A should be able to add a picture to the Group A folder (or bucket)
Any member of Group A should be able to read all pictures of the Group A folder (or bucket)
No member of Group A should not have access to any of the pictures
However, the solution used by the post mentioned above (temporary pre-signed URLs) is not usable, as we need the client to be able to write files on his bucket as well as read the files on his bucket, without having any access to any other bucket. The file write part is the difficulty here and the reason why we cannot use pre-signed URLs.
Additionally, the solution from various AWS security posts that we read (for example https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/) do not apply because they show how to control accesses for IAM groups of for other AWS accounts. In our case, a group of users does not have an IAM account...
The only solutions that we see so far are either insecure or wasteful
Open buckets to everybody and rely on obfuscating the folder / bucket names (lots of security issues, including the ability to brute force and read / overwrite anybody's files)
Have a back-end that acts as a facade between the app and S3, validating the accesses. S3 has no public access, the bucket is only opened to an IAM role that the back-end has. However this is a big waste of bandwidth, since all the data would transit on the EC2 instance(s) of that back-end
Any better solution?
Is this kind of customized access doable with S3?
The correct way to achieve your goal is to use Amazon S3 pre-signed URLs, which are time-limited URLs that provides temporary access to a private object.
You can also Upload objects using presigned URLs - Amazon Simple Storage Service.
The flow is basically:
Users authenticate to your back-end app
When a user wants to access a private object, the back-end verifies that they are permitted to access the object (using your own business logic, such as the Groups you mention). If they are allowed to access the object, the back-end generates a pre-signed URL.
The pre-signed URL is returned to the user's browser, such as putting it in a <img src="..."> tag.
When the user's browser requests the object, S3 verifies the signature in the pre-signed URL. If it is valid and the time period has not expired, S3 provides the requested object. (Otherwise, it returns Access Denied.)
A similar process is used when users upload objects:
Users authenticate to your back-end app
They request the opportunity to upload a file
Your back-end app generates an S3 Pre-signed URL that is included in the HTML page for upload
Your back-end should track the object in a database so it knows who performed the upload and keeps track of who is permitted to access the object (eg particular users or groups)
Your back-end app is fully responsible for deciding whether particular users can upload/download objects. It then hands-off the actual upload/download process to S3 via the pre-signed URLs. This reduces load on your server because all uploads/downloads go direct to/from S3.

How to make sure a S3 presigned GetObject URL can only be accessed from an authorized device?

I want to provide a presigned s3 url for authenticated users to download files. I have a JWT based authentication on my backend and the URL can be generated on my backend based on the token. So if a user is authenticated on a device, they can click on a button and it opens a new tab pointing at the presigned url. My question is, how to prevent the user to copy the url on to an unauthenticated device and access the file from there? I referred to AWS S3 authenticated user access using presigned URLs? this, but it doesn't solve my problem.
Generally no, that is not possible, a pre-signed URL is valid from any browser and any device. You cannot prevent a user from copying and sharing the link.
The only thing you could do is reduce the duration for which the presigned url is valid, if you open the link in a new tab and set the duration of the presigned url only be e.g. 5 seconds you massively reduce the chance or the effect of the user being able to share the link in time.

AWS S3 - secure URL

Trying to find a best practice to securely download contents from s3 on a SPA? Presigned URL seems to be one of the options. But whoever can get hold of that URL can access the contents. Is there a way to protect the presigned URL with an extra layer of security? Like to ensure the right person is accessing the files. Just a note, we use a third party IDP and not cognito.

How can I allow a 3rd party file upload to a private S3 bucket without using IAM?

Can I allow a 3rd party file upload to an S3 bucket without using IAM? I would like to avoid the hassle of sending them credentials for an AWS account, but still take advantage of the S3 UI. I have only found solutions for one or the other.
The pre-signed url option sounded great but appears to only work with their SDKs and I'm not about to tell my client to install python on their computer to upload a file.
The browser based upload requires me to make my own front end html form and run in on a server just to upload (lol).
Can I not simply create a pre-signed url which navigates the user to the S3 console and allows them to upload before expiration time? Of course, making the bucket public is not an option either. Why is this so complicated!
Management Console
The Amazon S3 management console will only display S3 buckets that are associated with the AWS account of the user. Also, it is not possible to limit the buckets displayed (it will display all buckets in the account, even if the user cannot access them).
Thus, you certainly don't want to give them access to your AWS management console.
Pre-Signed URL
Your user does not require the AWS SDK to use a pre-signed URL. Rather, you must run your own system that generates the pre-signed URL and makes it available to the user (eg through a web page or API call).
Web page
You can host a static upload page on Amazon S3, but it will not be able to authenticate the user. Since you only wish to provide access to specific people, you'll need some code running on the back-end to authenticate them.
Generate...
You ask: "Can I not simply create a pre-signed url which navigates the user to the S3 console and allows them to upload before expiration time?"
Yes and no. Yes, you can generate a pre-signed URL. However, it cannot be used with the S3 console (see above).
Why is this so complicated?
Because security is important.
So, what to do?
A few options:
Make a bucket publicly writable, but not publicly readable. Tell your customer how to upload. The downside is that anyone could upload to the bucket (if they know about it), so it is only security by obscurity. But, it might be a simple solution for you.
Generate a very long-lived pre-signed URL. You can create a URL that works for months or years. Provide this to them, and they can upload (eg via a static HTML page that you give them).
Generate some IAM User credentials for them, then have them use a utility like the AWS Command-Line Interface (CLI) or Cloudberry. Give them just enough credentials for upload access. This assumes you only have a few customers that need access.
Bottom line: Security is important. Yet, you wish to "avoid the hassle of sending them credentials", nor do you wish to run a system to perform the authentication checks. You can't have security without doing some work, and the cost of poor security will be much more than the cost of implementing good security.
you could deploy a lambda function to call "signed URL" then use that URL to upload the file. here is an example
https://aws.amazon.com/blogs/compute/uploading-to-amazon-s3-directly-from-a-web-or-mobile-application/

How to prevent brute force file downloading on S3?

I'm storing user images on S3 which are readable by default.
I need to access the images directly from the web as well.
However, I'd like to prevent hackers from brute forcing the URL and downloading my images.
For example, my S3 image url is at http://s3.aws.com/test.png
They can brute force test and download all the contents?
I cannot set the items inside my buckets to be private because I need to access directly from the web.
Any idea how to prevent it?
Using good security does not impact your ability to "access directly from the web". All content in Amazon S3 can be accessed from the web if appropriate permissions are used.
By default, all content in Amazon S3 is private.
Permissions to access content can then be assigned in several ways:
Directly on the object (eg make an object 'public')
Via a Bucket Policy (eg permit access to a subdirectory if accessed from a specific range of IP addresses, during a particular time of day, but only via HTTPS)
Via a policy assigned to an IAM User (which requires the user to authenticate when accessing Amazon S3)
Via a time-limited Pre-signed URL
The most interesting is the Pre-Signed URL. This is a calculated URL that permits access to an Amazon S3 object for a limited period of time. Applications can generate a Pre-signed URL and include the link in a web page (eg as part of a <img> tag). That way, your application determines whether a user is permitted to access an object and can limit the time duration that the link will work.
You should keep your content secure, and use Pre-signed URLs to allow access only for authorized visitors to your web site. You do have to write some code to make it work, but it's secure.