4

I am planning to use CloudFront as the server cache for my site, secured by singed URLs. The reason for using signed URLs is to allow access to the content only to authenticated users.

My webapp, however, also needs to use the caching on the client side. Now since the signed URL will only be valid for a short time and then a new one will be generated, this will break the caching on the client side. Although the client will receive the same resource, it will have a new signed URL and the client browser will not be able to get it from the cache.

One of the reasons why I want to use signed URLs with short validity for long existing resources is having control over the transmitted data. In the best case these resources are cached at the client. If not, they are cached on CloudFront and CF will deliver them and spare the resources of my web app server. But I want to prevent an attacker to download the resource huge number of times from CF and cause me additional costs.

Is there a way to secure access to CloudFront resources using some other means than signed URLs? For example a good thing would be a signed cookie. The client would ask for a resource on a webapp URL and the webapp would return a redirect to a long-term CF URL for that resource but retrieving the resource would be only possible with a signed cookie with a short validity. The client would still see the long URL and could cache the resource but the resource would only be available short time for the download. I do not want to mess with IP addresses since they are unreliable, often there could be many users behind one IP etc.

Is there something like that to overcome the local caching limitation of the signed URLs?

TomFT
  • 133
  • 1
  • 13
  • Can you control caching behavior on the client side? You could have it ignore the signature portion of the URL when storing/accessing the cache, so that it _can_ cache locally. (This assumes the contents of a request does not change on subsequent calls.) – John Rotenstein Jul 25 '18 at 21:32
  • Thanks for the idea but I cant. Anyways signed cookies are the correct answer for me, from some mysterious reason I could not google it out myself before asking. – TomFT Jul 30 '18 at 09:07
  • It's worth noting that, for a given file and expire date as input, the signed URL function will always return the same URL, and so the files *will* get cached. So you may want to use an absolute expire date rather than the usual time() + X seconds. – Fabien Snauwaert Nov 15 '18 at 21:11
  • I see. But time + X seconds is exactly what I want. I want to keep the URL valid only for a few seconds so that an attacker does not keep downloading the file many times and so he could incur big cost for me through CF. – TomFT Nov 17 '18 at 07:37

1 Answers1

2

If there is nothing really confidential in the resources, i would probably not bother with signing them myself. But since you have that requirement, you can use signed cookies.

These can both be limited in time, but also in scope. So you can give access to at specific subset of URLs.

colde
  • 3,192
  • 1
  • 15
  • 26
  • 1
    Thanks, signed cookies is my answer, from some reason I did not find the info myself, not sure why ... – TomFT Jul 30 '18 at 09:08