I found several strange requests in my Google App Engine log:

2620:0:1000:3001:1c2f:1188:9a2a:f8d8 - - [26/Oct/2015:16:29:55 -0700] "HEAD /an/object/path HTTP/1.1" 404 - - "curl/7.35.0" "xxx.appspot.com" ms=2 cpu_ms=0 cpm_usd=0 instance=- app_engine_release=1.9.27 trace_id=-

where /an/object/path is the path of an object in the Google Cloud Storage default bucket, which should be unknown to the user.

I have tried listing the bucket content using another account with:

gsutil ls gs://xxx.appspot.com

which gives "AccessDeniedException: 403 Forbidden", and


which shows nothing.

gsutil acl get gs://xxx.appspot.com/...


    "entity": "project-owners-1096471376163",
    "projectTeam": {
      "projectNumber": "1096471376163",
      "team": "owners"
    "role": "OWNER"
    "entity": "project-editors-1096471376163",
    "projectTeam": {
      "projectNumber": "1096471376163",
      "team": "editors"
    "role": "OWNER"
    "entity": "project-viewers-1096471376163",
    "projectTeam": {
      "projectNumber": "1096471376163",
      "team": "viewers"
    "role": "READER"
    "entity": "user-00b4903a978e00507e97b8a0898de74c6896e15ea3bf3e4c4fcdcbc4eb209c8f",
    "entityId": "00b4903a978e00507e97b8a0898de74c6896e15ea3bf3e4c4fcdcbc4eb209c8f",
    "role": "OWNER"

So I suspect that either

  1. my account is hacked, and/or
  2. permission of the bucket/objects is set wrongly, and/or
  3. there are some buggy APIs which may be possible to list/query the bucket content.

Suppose that my account is hacked, the hacker can get the bucket objects directly, he/she does not really need to send requests to the GAE, so the chances of 2 and 3 are also high.

So I want to ask what tool/command can I use to check whether my bucket is really safe against public access.

For case 3, maybe, many other accounts are affected too.

  • Just use curl or wget from the command-line. – EEAA Oct 27 '15 at 2:27
  • I have tried "gsutil ls gs://xxx.appspot.com" with another account, which gives "AccessDeniedException: 403 Forbidden". I have also tried "storage.cloud.google.com/xxx.appspot.com" which shows nothing. So I suspect that either my account is hacked or there are some other APIs which may be possible to list the bucket content. – Shing Oct 27 '15 at 3:48

As explained in the docs, you can do it with gsutil.

Something like :

gsutil acl get gs://«path-to-object»

From what I can read from your updated question, looking back to the same documentation I just linked up, you can see that the return means the following :

the project owners ALSO have ownership of the object,

the project editors ALSO have ownership of the object,

the project viewers ALSO have READ access to the object,

and the guy who first uploaded the object has ownership over it.

  • Edited the question to include the output of the command. No idea how the hacker can find out the name of the object. – Shing Oct 28 '15 at 1:52
  • Edited to include more information about what you updated. Normally though, it would be better to open a NEW question, since your original question was answered – Patrice Oct 28 '15 at 14:05
  • The project has one owner. It has no editor/viewer. The object should be created by the application, and is NOT uploaded by a guy. Actually, the bucket and all objects have the same ACL as mentioned in the question. The bucket is the default bucket created via the GAE Admin Console by the owner. Does the entityId refer to the owner then? Or does the entityId refer to the hacker? How can I check this? – Shing Oct 29 '15 at 3:15
  • Again, this should be a separate question in itself. Anyway, from the docs I've linked, you can see the following cloud.google.com/storage/docs/… which explains what the entityID is. It's very possible that the application uploaded these, in which case the "user" will be the project. Considering you're using the default bucket, it's easy to guess the name of it (it's the same as your appID). But if he's getting 404, means he's hitting a file that doesn't exist, which means he can't know what's in your bucket, he's blindly flailing around – Patrice Oct 29 '15 at 14:24
  • The files the hacker tried to get are some internal data files created by the application. The files actually exist in the bucket. The 404 responses are for xxx.appspot.com/an/object/path, NOT storage.googleapis.com/xxx.appspot.com/an/object/path. That is, the hacker could find out the names of some objects due to unknown reason, and he/she might fail to get the object via storage.googleapis.com, so he/she might then try to see whether it is exposed in xxx.appspot.com. – Shing Oct 29 '15 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.