6

I have service like tiny URL to shorten www.example.com/[6chars] URLs. However it includes person specified sensitive information.

How can I protect the URL bruteforce scanners to the detect if URL has response. Or anyway it is possible?

UPDATE:17.09.2015

I will send the shortened link as SMS or E-Mail so i do not have any session information. I guess i can not solve the vulnerability. I have to cancel shortener service.

engincancan
  • 163
  • 6
  • Please read the edited answer. – Saehun Sean Oh Sep 17 '15 at 20:09
  • 1
    Why would your URL shortening service need to put personal, sensitive info in the URL? And how would you even keep it short with that info AND the url you want to shortern? – David says Reinstate Monica Sep 17 '15 at 22:10
  • I think the question is how to ensure the URL space can't be brute forced, given that some URLs redirect to pages with sensitive information (i.e. the threat model is an adversary that scrapes all possible URLs for sensitive data). – puzzlepalace Sep 17 '15 at 22:40
  • Think something like order track link. When your order completed I'll send an SMS to client that can track and update their order. Site does not force user to register so login screen may fail – engincancan Sep 18 '15 at 06:23
  • @engincancan You could either give just the general status of the package (something like a progression from _processing_ to _shipped_ to _in transit_ to _out for delivery_), and nonspecific timings (as of _this afternoon_, as of _yesterday evening_); or you could forgo the short URIs in favor of long, randomly-selected ones that would be hard to guess. – Blacklight Shining Sep 18 '15 at 20:42

3 Answers3

7

Well Simple answer.

DO NOT EVER INCLUDE ANY KIND OF PERSONAL INFORMATION INTO URL.

URL is extremely easy to get from outside (e.g. javascript, screenshot, etc etc) and it should never, ever include personal information. It's like using a Social Security Number as your license plate number.

You technically can block bruteforce scanners by adding checks like if the user is in the current session and reject connection if anyone is trying to access to the URL without session information, but it's still not great approach because it will still give you some sort of response from server. (for example, if you just check session and echo that you have no permission, it will give you 200 response code, and the attacker will be able to notice that there is SOMETHING)

Please find other ways to provide your service without using personal information on URL.

As suggested below, if you decide to hash the personal information, please use longer & more character set.

If you use only 6 alphabet characters, it will take about ~9 hours with Class A brute force attack, and Class F can crack it instantly.

Please take a look at this website and make sure you hash it correctly. But then again, hashing should not be the ultimate solution.

EDIT:

If you are not displaying personal information on URL, that might be fine. You can simply generate a personal link and send it to your user via SMS or email with authentication.

That means, once user clicks the link, it will take the user to the login screen. The URL should not mean anything in this case of course.

Saehun Sean Oh
  • 206
  • 1
  • 4
1

OWASP guide recommands two methods (How to protect sensitive data in URL's):

  1. Hashing the senstive data

  2. Encrypting the sensitive data using symetric encryption

0

If the personal information is on the page where the URL is pointing at, you could implement the following measures:

  • Add some kind of shared secret or authentication before the user can access the data. (As far as I understand this is not what you want to do since with full authentication you wouldn't need shortened URLs at all)
  • If authentication is inappropriate, add a secure CAPTACHA before the user can access the data.
  • Monitor the accessing IP addresses and user agents and enforce lockouts or throttling after a few connection tries.
  • Add an expiration time and/or threshold so that the page with the data gets deleted after a short time and/or a certain amount of visits. (Don't forget blacklisting used IDs to prevent collisions)
  • Increase the entropy of the ID by increasing the number of used characters (Case sensitive letters, numbers, slashes, other special characters)
Noir
  • 2,523
  • 13
  • 23