1

I have noticed that my private Google Drive resources, for example, although it is impossible to "guess" their hash-key and get it (eg tbEB6fQTqQcFAoRBXYvnpNVq9F3PUr_cs), however the server requires authentication to access the resource.

On the other hand, in ICloud I saw that while there is an "external" link that represents each resource, it is private, but the real address (by which the client-side goes the resource) is without any authentication .

I think that makes sense, that there is no way for an attacker to obtain the key in Query String, because it is encryped by SSL.

The question is whether there is any fear of it and therefore to implement validation as Google does. I'm talking about an application where resources are not exposed in any way to an unauthentication user.

dovid
  • 113
  • 5
  • Sorry - are you suggesting iCloud will return a private document to an unauthenticated user if they posses the correct URL? Additionally you use the phrase hash-key. Resource IDs are very rarely hashes because the content and metadata can change. Its normally a randomly generated ID. – Hector Nov 08 '17 at 14:18
  • @Hector, a. this is reality, you can check. the url starts with "https://cvws.icloud-content.com/B". b. you right. i dot now how call random resource-id. – dovid Nov 08 '17 at 14:29
  • I don't use iCloud but I would be surprised by this. Are you sure the document in question hasn't set to be externally available via a direct link? In theory an ID like that should be impossible to guess - so it *should* be secure. But there are several ways for them to be leaked. – Hector Nov 08 '17 at 14:43
  • you can open an account. I just made a test: https://cvws.icloud-content.com/B/AW2cWT2PxzWixMKuuNMTHJ8CJ3sHAcBOOs1S1QUjNLVXJdCMntONS5Eb/testICloud.txt?o=AjuAJEmGLwd5kdLaA9iIOMaLbX5pmRE4BU6dFBzhSdIQ&v=1&x=3&a=Bdwzy8HVh4lZAz8IPw&e=1510156688&k=4a3vfOX9PkhJJyX-rnSZsQ&fl=&r=a22a4997-5241-441b-b59c-0870e43d6b71-1&ckc=com.apple.clouddocs&ckz=com.apple.CloudDocs&p=25&s=RqlC24JNRQ5XZNVS8cNaJeKMR-U. – dovid Nov 08 '17 at 15:46
  • 1
    See also [Is random URL token secure enough for file attachments and other user content?](https://security.stackexchange.com/questions/112021/is-random-url-token-secure-enough-for-file-attachments-and-other-user-content) – Sjoerd Nov 08 '17 at 15:50
  • 1
    That URL contains numerous query parameters which if modified or removed lead to a bad request. It isn't just using the id. I expect one (probably o) is an authentication token. e to me looks likely to be a unix timestamp meaning that link will likely expire in a few minutes (11/08/2017 @ 3:58pm UTC). I also expect s is a signature so the link parameters cannot be modified. – Hector Nov 08 '17 at 15:54
  • 1
    @lomed - Yep - Loading the link now results in 410 "Gone" – Hector Nov 08 '17 at 15:59

1 Answers1

1

As pointed out in the comments by @Sjoerd simply using a URL to protect a resource in theory can be secure but comes with several potential problems. If this is your question then it is a duplicate of Is random URL token secure enough for file attachments and other user content?.

As per my comments it appears iCloud does not simply use a URL. The link provided contained several query parameters including a session token, (relatively short) expiry and signature.

Hector
  • 10,923
  • 3
  • 41
  • 44