4

Here is what I want to do: We create reports for customers, normally we send them as pdf to our customer who then shares them with colleagues across his company. We want to switch now to digital reports.

  • The report is accessible only via URL with UUID
  • When the user clicks on the link, he is redirected from https://example.com/uuid/ to https://example.com/customer/report/
  • The second domain checks the http referer for the UUID. We make this redirection to prevent the problem when the user clicks in the report on an external link that the other server has the UUID in their referers logs.
  • We create the UUID v4 with the NPM Package UUID
  • Everything is via https connections

My questions:

(edited to avoid duplicates)

  • Can crawlers find the UUID if it isn't posted anywhere?
  • Is my solution to redirect to separate report page to avoid the problem with UUIDs being exposed in the request URL effective?

Why don't we use username / password? Simply because at the end with sharing the report these credentials are shared in emails as well. And either we make a long secure password or the client makes it but then there is a good chance that he has to share one of his standard passwords.

schroeder
  • 125,553
  • 55
  • 289
  • 326
urban-a
  • 51
  • 1
  • 5

1 Answers1

6

It's not very safe, but depending on how sensitive the file actually is, you may consider the risks worth the usability benefits.

Can a robot index such pages and their UUIDs?

Yes, if someone posted the link to the file on the public internet, then they can be indexed. With major search engines, you can ask search engines to exclude this directory by using robots.txt, but compliance with robots.txt are voluntary and there are many other spiders that ignore robots.txt.

If you want to secure this without losing much of the usability, you may want to consider requiring viewers to create individual accounts to access your site. The viewers should enter their email, and you'd validate their address by sending an email with a confirmation token, you'd then send a message to the document owner to ask them to grant access to the user identified by their email. Additionally, you may want to allow the document owner to specify a list of email domains and addresses that will be automatically granted access, so that he wouldn't have to manually grant every requests. Most companies give their employees email addresses on a company domain, so this would cover a lot of use cases. This way, each user that accesses the document will still be identified, rather than being an anonymous user.

If you really don't want to require users to create an account, it is possible to implement this without requiring user password, when user type their email, they'll be sent an email which contains a link they'll click that have a unique token that grants them access to the document for a short period of time. When the short term token expires, the user can request a new token.

Lie Ryan
  • 31,279
  • 6
  • 69
  • 93
  • Thx but only if they post it they can't crawl it right? – urban-a Nov 01 '17 at 15:38
  • And yes individual user accounts are possible but much more effort. Because now they just forward the PDF – urban-a Nov 01 '17 at 15:39
  • As far I see it: it is save with the correct uuid (not lseude random etc) as long it is not shared but that also applied for password. But my concerns are: can crawler crawl it just because it's a part of an Url – urban-a Nov 01 '17 at 15:42
  • My Conslusion would be: It is as secure if I would generate one password and user for all and share this credentials with the customer. Individuals accounts aren't possible because we don't know who is allowed to create an account. And so they would have to inform us upfront who emails are allowed and that means they can't share the report as they want – urban-a Nov 01 '17 at 15:57
  • @Thomas Urban: Actually, even adding a shared password is slightly more secure. It allows users to link/reference the file without giving access to everyone who can read the article where they share the link. As an analogy, it's often still useful to be able to link to paywalled scientific papers and talk about parts of its content even if not all of your audience actually have access to the paper. – Lie Ryan Nov 01 '17 at 17:31
  • That is an interesting thought but a different use case thx – urban-a Nov 01 '17 at 17:33
  • @ThomasUrban: whether that use case is relevant to your application or not, is of course not something we can determine here. But I think your insistence on not wanting to add any sort of identification system seems to me that your mind is already set before you asked this question. I don't think anything anyone says here can convince you that what you're doing here is very insecure. – Lie Ryan Nov 01 '17 at 17:39
  • I didn't want to offend you if I did I am sorry. And yes you're right perhaps I am to biased. That is because I didn't hear or read an argument yet which convince me. You see my thought is: at the moment it is completely unsecure: a PDF is sent plain via email and than distributed. When we now want to start using more dynamic online reports we don't want to make it too complicated for the customers. So I thought about uuids. Like Google docs does. I know they aren't as secure well designed platforms with username and password but is there a middle way? – urban-a Nov 01 '17 at 17:45
  • I mean uuid seem to me when it is generated good that this protects to content to be opened when someone doesn't know the uuid. – urban-a Nov 01 '17 at 17:46
  • @ThomasUrban: I did describe above a few different ways you can add user identifications without having to do explicit registration or passwords, the simplest is simply by doing email verification. There are a number of variations you can do with it to balance security and convenience. Even if you don't implement stricter access control such as requiring explicit approvals from document owner, or requiring explicit share from existing viewers, or mail domain whitelisting, just being able to audit who have accessed the document is usually still very useful. – Lie Ryan Nov 01 '17 at 17:59
  • Yes that are good ideas and the temporary token is a good idea. So we don't need all the tools typical user management needs (password reset, password change functions etc) but the document access is still restricted. Thank you! – urban-a Nov 01 '17 at 18:11
  • I'll think I do something like that: - an uuid url to get to the token request page. - email to request and hour valid token - the owner grants access and or whitelist after that the user are redirected to the page with the report without token to prevent the external link problem – urban-a Nov 01 '17 at 18:18
  • @ThomasUrban: as an alternative to short lived access token, if you want to reduce the number of verification emails, you can set a cookie in the user's browser, so that user only need to verify email once, and then they can open more documents in the same browser as the same user without repeating mail verification. After the first email verification, the user experience will be mostly similar to just sharing publicly accessible secret URLs (until the cookie expires or the user switch to another browser). – Lie Ryan Nov 01 '17 at 18:34