Reputation: 13
GCS Signed Urls enable you to simply make objects available temporarily public by a signed url. https://cloud.google.com/storage/docs/access-control/signed-urls
As I understand it, you need to calculate a signature based on several parameters, and then you get access to the object without any other security layer.
Unfortunately the documentation is not completely clear if an object gets explicitly activated by the GCS service for that and gets a flag "signature XYZ valid for XX minutes on object ABC" or if GCS serves all files all time, as long as the signature is correct.
If any object can be made available with a proper signature, then all files in GCS are de facto accessible public, if the signature gets guessed right (brute force).
Is this right?
Is there any information on the level of security, that protect url-signing?
Is there a way to disable the url-signing?
Do the VPC Service Perimeters apply to signed urls?
These are some points that I need find out due to compliance evaulations and they are more theoretical questions, than some concrete security doubts I have with this service.
Thanks for your comments.
Upvotes: 1
Views: 2036
Reputation: 38379
Unfortunately the documentation is not completely clear if an object gets explicitly activated by the GCS service for that and gets a flag "signature XYZ valid for XX minutes on object ABC" or if GCS serves all files all time, as long as the signature is correct.
The signed URL contains a timestamp after which the signed URL is no longer valid. The timestamp is part of what the signature signs, which means it can't be changed without invalidating the signature. The signatures themselves are generated entirely on the client with no change in server state.
If any object can be made available with a proper signature, then all files in GCS are de facto accessible public, if the signature gets guessed right (brute force). Is this right?
Yes, this is true. Anyone who knows the name of a service account permitted to read the file, the bucket name, and the object name, and who correctly guesses which of the 2256 possible hashes is correct could indeed view your file. Mind you, 2256 is a fairly large number. If an attacker could make one trillion guesses per nanosecond, we would expect that on average they would discover the correct hash in about 3.6x1044 years, which is about 2.7x1034 times the age of the universe.
Is there any information on the level of security, that protect url-signing?
Certainly. GCS uses GCS uses a common signed URL pattern identical to S3's "AWS Signature Version 4." The exact signing process is described on both service's websites. The signature itself is an HMAC SHA-256, which is a type of SHA-2 hash, a well-studied algorithm whose strengths and weaknesses are widely discussed. https://en.wikipedia.org/wiki/SHA-2.
Is there a way to disable the url-signing?
VPC service controls are the simplest way. They can prevent any user outside of your project from accessing the data regardless of credentials.
Do the VPC Service Perimeters apply to signed urls?
Yes, signed URLs would only work from within the configured security perimeter.
Upvotes: 7
Reputation: 2140
Looking at the library code, the signed URLs are created using your service account private key without cooperation from GCP.
Regarding the brute-force, each Signed URL has a credential attached, which is linked to the signer. This signer account needs to have permissions you want the user to have on the object. In case the URL is stolen, it can then be revoked by revoking permissions of the signer (you'll revoke all Signed URLs for that signer tho). To minimize risks, you could create a SA that would have access only to specific objects in the bucket.
To decrease the possibility of brute-force attacks, you can also rotate the Service Account key by creating a new one and deleting the previous.
Regarding the question: Can Signed URLs be fully disabled? You could "disable" this feature by not granting project-wide storage permissions to any Service Account for which you have generated a Private Key.
Upvotes: 0