Search code examples
imagesecuritytokenimage-uploading

Shared key for authenticating file uploads in a separate server


In my current project I need to be able to upload images and save them in a store like S3 and perform some operations (resizing, etc) before saving the images. I'm still grasping how this should be done.

I was thinking of creating a separate server to make this image processing and uploads to lower the load on my main application server, I don't know if I should do this or maybe I should but I'm just solving an imaginary scalability problem.

Any way, I need a way to restrict the uploads to the image server. I was thinking since I don't need to distribute keys to create a shared secret between the application and the image server. This secret would be used to create tokens that would be provided to the clients to upload images for a limited amount of time.

If my endpoint in the image server receives the shared secret for authenticating and creating the upload token is it sufficient for security?

Is it enough to have both servers over https to ensure there is no way to steal the secret in a man in the middle attack?

I may have some misconceptions here about security and criptography but I would be really glad if someone could help me out or provide me with some reads that would be good for this case.

Thank you!


Solution

  • To my understanding, you want to allow users to upload images to your site and once uploaded you would like to process it in some way (resizing, etc..) If this is correct here is the workflow I suggest.

    Have your main application server create a pre-signed URL for the S3 upload. Send this pre-signed URL to the client. The client will be able to upload to S3. Once the upload is done do the processing in the background with a worker (fetch from S3-process-upload).

    This way, you can avoid having to deal with the token for the upload. S3 also supports time limits on the pre-signed URL.

    I was thinking of creating a separate server to make this image processing and uploads to lower the load on my main application server, I don't know if I should do this or maybe I should but I'm just solving an imaginary scalability problem.

    It makes sense to separate the logic in this case. I wouldn't create a new server, just a background process for image processing. If you need to scale you can always spin up multiple such background processes.

    If my endpoint in the image server receives the shared secret for authenticating and creating the upload token is it sufficient for security?

    As I suggested above, use S3 for receiving the image upload. Clients will upload to S3 directly, it'll deal with security for you.

    Is it enough to have both servers over https to ensure there is no way to steal the secret in a man in the middle attack?

    HTTPS provides confidentiality which is enough to prevent man-in-the-middle sniffing of your traffic. Using AWS's pre-signed URLs you also won't be sending the secret over but a so-called signature. Here is an intro to the topic and Amazon's own documentation for more info.