1

I use a pre-signed URL approach for uploading files to a private S3 bucket. A CloudFront distribution is configured to use this bucket as the source.

The upload process is only available to authenticate users and is done in two steps:

  1. Client requests for the pre-signed URL, my server generates the URL using AWS credentials and return the URL.

  2. Client uses this URL to issue a PUT request to S3 and completes the upload.

So far, my server simply generates the signed URL using client-provided filename and does not perform any business logic check for the upload (e.g. whether a requested upload is valid). The argument for doing it this way is to have a generic upload service that is independent from others parts of the API that may be related to different kinds of file uploads (e.g. PDFs, photos, audios, etc).

In addition, at the moment there is no explicit verification/confirmation of a successful upload. After the client receives the pre-signed URL, it has 5 mins to complete the upload before the URL expires, but there is no explicit check whether the file is indeed uploaded.

I wonder if there is any serious security flaw in the process above.

MLister
  • 171
  • 1
  • 4
  • Is access between the client and server protected by TLS/SSL? – Gerald Davis Jul 06 '15 at 23:11
  • @GeraldDavis, connections between clients and my server are protected, but connections to AWS S3/CF may not be. – MLister Jul 06 '15 at 23:40
  • In that case it would be possible for an attacker to MITM the connection between client and S3 wait for the client to attempt and upload and then upload the attacker's file instead. If the connection between client and S3/CF is protected by TLS/SSL I don't see any other attack vector but I would wait for other answers. – Gerald Davis Jul 06 '15 at 23:48

0 Answers0