This isn't about exposed credentials though. It would be like an autmatic image uploder that could pick an image hosting site such as imgur and upload the image for you and give you a link. Services are offering the ability to host images for you. You aren't stealing imgur's s3 credentials. They just let any user upload images for free despite the fact it technically costs them money to host the file for you. Similarly there are sites offering the ability to serve LLM requests for you for free.
Yes, the trusted party could always upload the image to imgur instead of copy and pasting the URL to an untrustworthy party. Imagine a URL that contains the entire image data and passing that around, for example.
b) person 1 guessed the URL, like a password since it's usually a long url with a GUID of some type.
But is that acceptable for some reason? Easier development?
Because otherwise you need to:
a) issue one time/short lived token for accessing an image on S3 for instance, for all the images that will be shown on a
page when a page loads for an authenticated user.
or
b) proxy the image requests by making an api endpoint for image names, authenticate those requests, fetch the image from a place only the server has access to and stream the image data back.
Free beats cheap. Imgur and its comeptitors are also straightforward. You don't really need an API for a single upload. The ownership and control argument is great in theory, but this is now an image on the internet. Anyone can link to it which will cost you money. Anyone can download it and upload to somewhere else. That means all appearances of control are artificial. I don't see much benefit here.
I don't disagree with your overall point, but there is definitely a difference between being able to save an image from a webpage and being able to share the URL that image was loaded from and having it work for un-authenticated users.
The [imgur](https://github.com/kaimallea/node-imgur) API lets you upload an image (anonymously) and responds with a URL. I promisify'd that and the result is super straightforward. You don't even need to auth.
I understand this isn't a big privacy leak. It looked awkward to me at first instance. I am trying to find what the general industry practice is in this and what could be the ideal solution as we are trying to build some image hosting for our product. Your answer is very insightful indeed.
I think it's pretty safe as long as no one without the permissions can find (or guess/extrapolate) that URL. The images are probably just hosted by a CDN and serving up the files with authentication might slow it down or complicate the setup.
Would an arbitrary image upload alone allow exploitation of this, or would it require an operation on the host along the lines of a 'docker cp' as well?
Because many people hotlink directly from the site. And If I'm going to host the images myself and eat the cost of bandwidth I might as well derive some value from it.
I provide a link to where the original images was taken from, so if anyone is interested in the image without the watermark they can get it from there.
You can responsibly link to an image on someone else's server without embedding it directly on your site. The web is no longer just hypertext, and the potential inequity in resources and scalability between servers matters. Why should I be expected to suffer and pay for anyone who decides they like a particular image on my site and want to use it in their forum avi? They can just as easily copy it locally and use it.
Once you have the full URL to the image, you can share that too - authorization checks dont happen when fetching the image.. from googleusercontent.com as far as I can tell..
But really - once you share an image to some one, there is no stopping them from downloading the image and sharing it out somewhere else anyways.. So I'm not sure the point of this.
> Having user A upload a malicious_file.png and then user B download it
You will usually want the profile image of user A to be shown to user B. Same for videos and other files - users likely upload them so that others can download them / consume them in some way, right?
I think where you need to start is doing some threat analysis, and proceed from there. Hosting user content can be built out from "very small" to "very big", depending on the particular threat scenario/use cases/your particular userbase. With the description that you are giving, I would say you are more at risk of building an overcomplicated ("oversecured") solution which might compromise UX for the sake of some protection that is not necessarily needed.
If you are a small team, likely you could use an image resizing / video thumbnailing proxy server such as https://www.imgix.com/https://imgproxy.net/ etc. You generate a signed URL to it and then the service picks up the file from S3 and does $thing to it. https://www.thumbor.org/ is another such tool. There are quite a few.
Re. uploads and downloads - you have quite some options with S3. You can generate the presigned upload URL on the server (in fact: you should do just that), make it time limited and add the Content-Length of the upload to the signed headers - this way the server may restrict the size of the upload. Similarly, access to display the images can be done via a CDN or using low-TTL signed URLs... plenty of things to do.
reply