2

I am using a web service (call it X) which allows files to be uploaded to AWS S3.

The way it works is that an initial call is made to X which then returns a list of file descriptors and also meta information which should be injected into the web form as hidden fields that the user is presented with to choose a file to upload. One of these hidden fields is the url of the S3 bucket where the file will be uploaded to.

When the user chooses a file and clicks submit the file is sent as byte streams to the S3 location.

I see two security concerns here:

  1. The url which is returned from calling X and then set as a hidden field in the form could be hijacked and substituted for another url of the hacker's choosing
  2. I am not sure if this is possible but the byte stream from the user's browser to the S3 bucket could be diverted?

Is this paranoia or actual real security concerns?

3
  • Old question, but: as written, it doesn't make sense. Returning file descriptors to a web browser is meaningless; FDs are just numbers. You say the file is streamed from the browser to S3, but never explain how it gets to the browser (local file picker on the client? Then why send any file-related data to the client?). You talk about changing the URL or redirecting the upload stream, but any attacker that can do that can just copy the file for their own use. You give the client the upload URL, so presumably you don't care what they upload? Most obvious threat seems to be abuse of the URL.
    – CBHacking
    Commented Aug 13, 2021 at 10:31
  • If a malicious user got a hold of the S3 bucket URL (not hard to do using browser dev tools), what could they do with it? Could they flood it with a huge number of large files resulting in DoS or excessive cost? Could they read and not only write to it?
    – bob
    Commented yesterday
  • This question is missing critical context and the question itself is not very clear.
    – schroeder
    Commented yesterday

4 Answers 4

1

if the security measures were taken in both client side and server side there shouldn't be any problem. all web services should implement these things:

  • the connection should be secure via SSL.
  • if you are posting data to server there should be CSRF tokens in your form fields so untrusted users can't send data to server
  • on the server never trust entered data by users and do data validation

so if you are using third party service just check it's documentation or ask directly from its developers.

please note that setting a filed hidden in the form is not a security measure, it is just for UI so the user don't see unnecessary input field when entering data.

0

actual real security concerns?

This depends on whether or not the application is properly secured.

  • Is the url served via a secure connection (HTTPS)?
  • Are all common security headers set, especially strict-transport-security?
  • ...and other important headers, like X-Frame-Options to prevent clickjacking?
  • Does the web application have a proper CORS policy/configuration=
  • Is the web page secured against XSS (no vulnerable javascript frameworks used, X-XSS-Protection header properly set)?
  • Is the form submitted via a secure connection (HTTPS)?
  • Is "Service X" trustworthy?

When all of the above is true, and/or set up correctly, I don't see why this shouldn't be less or more secure than having the url already pre-set in the web application.

It would be preferable if service X was under the same control of the owner of the web application itself, since things like "trustworthyness" may change over time.

Just make sure that the application doesn't allow arbitrary upload urls for assets. I've seen that before, that webpage APIs allowed the user to specify the upload-url path, making it possible to create signed upload- and even download-links.

7
  • Yes all those criteria are met. The only way I can see the url that is returned by service X being hacked is for someone to have temporary access to the person's compute w/o them knowing and modifying the form so that the URL is of the hacker's choosing. Person then comes back and submits the form and the file goes to the hacker's location.
    – Mojo
    Commented Feb 19, 2020 at 12:51
  • @Mojo is the service that sends you back the url not under the control of the same service of the entire web application? Commented Feb 19, 2020 at 13:00
  • No it isn't. It's a bit weird: the situation is as follows: there is a web service A which requires a user to upload a file to AWS S3. In order to do that it needs to call service X which I described in the post to get the information (file descriptors) to upload the file to S3. One of those descriptors is the URL of the S3 bucket. When Service A receives those descriptors, it constructs the web form with those details in hidden fields.
    – Mojo
    Commented Feb 19, 2020 at 14:20
  • Then it depends entirely on how much you can trust 'service X'. Commented Feb 19, 2020 at 15:13
  • Service X is an internal service so I can assume reasonably it is trustworthy. Based on that what is your re-evaluation?
    – Mojo
    Commented Feb 19, 2020 at 15:42
0

So if I understand you correctly, we have the following scenario: The client makes a call to X, and in return recievs a URL to a S3 bucket. The client then uploads a file to that bucket.

Someone in control of the client (the actual user, or an attacker using a XSS vulnerability or something similar) could upload the file to another S3 bucket, yes. I'm not sure I would consider that a security vulnerability, though. I'm not sure where the file comes from in this scenario, but if it passes the client then the client can do whatever it wants with it. If that is a vulnerability or not depeonds on the situation, I guess.

As for "diverting the byte stream", that is why you should use HTTPS. It protects you against man in the middle attackes.

What makes me curious is how the authentication to the S3 bucket works here. If the client uploads the file, it must be given some sort of credentials from X. What can one do with those, one wounders?

0

If a malicious user got ahold of the S3 bucket URL (not hard to do using browser dev tools), then depending on how the bucket is secured (and since the client is uploading to the bucket, it’s not presumably as locked down as if the server were doing the upload) there are a number of potential security risks:

  • They could flood it with a huge number of large files resulting in DoS or excessive costs for you or your employer.
  • Assuming the URL isn’t super short-lived they could post the URL somewhere resulting in MANY people flooding it with tons of files.
  • If they can they read from the URL too they could steal data uploaded by others or use your S3 bucket for free as an illicit file share. Depending on your jurisdiction this could possibly result in legal headaches for you or your employer (IANAL).

If it were me I’d be inclined to make upload a two step process, with the client sending the file data to server and then on the server side uploading that data to the S3 bucket. It’s more work but prevents you from having to expose the S3 bucket endpoint to users while allowing you to lock the S3 bucket down so only the server can use it.

New contributor
bob is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Not the answer you're looking for? Browse other questions tagged .