7 ms·

Is there really any way to securely host static assets in a cloud bucket? If you host profile images, etc... locally you can easily give or deny access to stati

Is there really any way to securely host static assets in a cloud bucket? If you host profile images, etc... locally you can easily give or deny access to static assets without having to obfuscate the file path. From what I read here, the dating app was using UUIDs in the URL paths of the images to obfuscate their identity (I’ve done this sort of thing before but afaik it’s not considered secure?). Is it possible to set up ACLs for bucket objects though? From my limited experience with Google Cloud Buckets are object can be simply public or private.

winrid 6y ago
You can serve them from the application layer and use authentication there. It's just slower.
- kart23 6y ago
  Yeah, a lot slower and more expensive as well. It adds up quick. I think pretty much every social media & dating site stores images publicly.
  - winrid 6y ago
    FaceBook has authentication around their images.
klohto 6y ago
1) Long UUID are generally considered safe if you don’t allow parties to list the contents of the bucket 2) You can encrypt the asset and include the key with the asset URL (mentioned in the article) 3) Use pre-signed URL (infra load, but smaller than you serving it) 4) Implement your logic in Lambda@Edge (AWS) and link it with CloudFront distribution. You can deny or allow access based on that (Auth, Tokens, etc.) 4) I would say is the best and the safest solution at really low cost. Followed by 1) at price/value ratio.
- heavenlyblue 6y ago
  What is a “short” UUID?
  - jsjohnst 6y ago
    I don’t think GP intended to signify there’s long and short UUIDs, just used “long” to additionally describe UUIDs. I could be wrong, but site guidelines say to assume best intent in your replies.
    - klohto 6y ago
      Pretty much :) I don't know how would I classify a short UUID, but they should follow the same precautions as if it was a password composed only of lowercase alphanumeric chars. The longer you can afford, the better.
  - henryfjordan 6y ago
    There are variants of uuids that encode a MAC address and timestamp, reducing the randomness quite a bit. If you knew that info, generating a collision would be a lot easier (still impractical). Maybe that's what GP meant?
0xcoffee 6y ago
In Azure at least it's possible to set the blobs to private, then generate time limited tokens which can be appended to the URL which will grant access.
- rantwasp 6y ago
  you can do this with s3. it’s called presigned urls
- __s 6y ago
  SAS Tokens
scrollaway 6y ago
Not really in the way you're describing. But S3 supports (and most S3-compatible alternatives as well) signing URLs with the secret key, and with a user-set expiry. The problem is that it means the requests can't really be cached, so for static assets it's not ideal. S3 supports etags though but I've never touched that so I don't know how well it all works; I personally don't use signed URLs for stuff I want cacheable.
z3t4 6y ago
The problem was most likely that the image server had directory listing turned on!? Another problem is if the random image id is leaked.
actuator 6y ago
It depends on the data you are storing, using unique UUIDs for something like profile image(avatar?) is good enough, as I commented here the probability of a collision is so low that you can assume them to be not iterable for practical purposes. Just be sure to not enable list APIs for public use in your bucket. The other solutions you have where you authenticate the path as such, which should ideally be used for more sensitive assets: - Proxy asset requests through application server, let it authenticate the user access. You can even generate short lived S3 urls this way, and your objects don't have to be public. - Proxy asset requests through a reverse proxy like Nginx, authenticate there, you have a lot of options here like using something like JWT to authenticate the resource access. - Proxy asset requests through your reverse proxy CDN like Cloudflare, authenticate there, like in case of Cloudflare JWT is supported.
abofh 6y ago
Short term signatures are the generally recommended approach, especially if you control the client and producer. You give the client a 1/5/60 minute signature, and consumers you authorized can get it. Protecting from MITM is a separate (important) concern for that approach to be valid though, and it's not 100%. If you use an integrated cloud+cdn solution, the problem is largely solved for you, assuming you pick up the best practices and run with them

winrid 6y ago

You can serve them from the application layer and use authentication there. It's just slower.

kart23 6y ago
Yeah, a lot slower and more expensive as well. It adds up quick. I think pretty much every social media & dating site stores images publicly.
- winrid 6y ago
  FaceBook has authentication around their images.

klohto 6y ago

1) Long UUID are generally considered safe if you don’t allow parties to list the contents of the bucket 2) You can encrypt the asset and include the key with the asset URL (mentioned in the article) 3) Use pre-signed URL (infra load, but smaller than you serving it) 4) Implement your logic in Lambda@Edge (AWS) and link it with CloudFront distribution. You can deny or allow access based on that (Auth, Tokens, etc.) 4) I would say is the best and the safest solution at really low cost. Followed by 1) at price/value ratio.

heavenlyblue 6y ago
What is a “short” UUID?
- jsjohnst 6y ago
  I don’t think GP intended to signify there’s long and short UUIDs, just used “long” to additionally describe UUIDs. I could be wrong, but site guidelines say to assume best intent in your replies.
  - klohto 6y ago
    Pretty much :) I don't know how would I classify a short UUID, but they should follow the same precautions as if it was a password composed only of lowercase alphanumeric chars. The longer you can afford, the better.
- henryfjordan 6y ago
  There are variants of uuids that encode a MAC address and timestamp, reducing the randomness quite a bit. If you knew that info, generating a collision would be a lot easier (still impractical). Maybe that's what GP meant?

0xcoffee 6y ago

In Azure at least it's possible to set the blobs to private, then generate time limited tokens which can be appended to the URL which will grant access.

rantwasp 6y ago
you can do this with s3. it’s called presigned urls
__s 6y ago
SAS Tokens

scrollaway 6y ago

Not really in the way you're describing. But S3 supports (and most S3-compatible alternatives as well) signing URLs with the secret key, and with a user-set expiry. The problem is that it means the requests can't really be cached, so for static assets it's not ideal. S3 supports etags though but I've never touched that so I don't know how well it all works; I personally don't use signed URLs for stuff I want cacheable.

z3t4 6y ago

The problem was most likely that the image server had directory listing turned on!? Another problem is if the random image id is leaked.

actuator 6y ago

It depends on the data you are storing, using unique UUIDs for something like profile image(avatar?) is good enough, as I commented here the probability of a collision is so low that you can assume them to be not iterable for practical purposes. Just be sure to not enable list APIs for public use in your bucket. The other solutions you have where you authenticate the path as such, which should ideally be used for more sensitive assets: - Proxy asset requests through application server, let it authenticate the user access. You can even generate short lived S3 urls this way, and your objects don't have to be public. - Proxy asset requests through a reverse proxy like Nginx, authenticate there, you have a lot of options here like using something like JWT to authenticate the resource access. - Proxy asset requests through your reverse proxy CDN like Cloudflare, authenticate there, like in case of Cloudflare JWT is supported.

abofh 6y ago

Short term signatures are the generally recommended approach, especially if you control the client and producer. You give the client a 1/5/60 minute signature, and consumers you authorized can get it. Protecting from MITM is a separate (important) concern for that approach to be valid though, and it's not 100%. If you use an integrated cloud+cdn solution, the problem is largely solved for you, assuming you pick up the best practices and run with them