Can secret GET requests be brute forced? [duplicate]

Question

Say, I have on my server a page or folder which I want to be secret.

example.com/fdsafdsafdsfdsfdsafdrewrew.html

or

 example.com/fdsafdsafdsfdsfdsafdrewrewaa34532543432/admin/index.html

If the secret part of the path is quite long, can I assume that it's safe to have such a secret page or area, and it'll be hard to guess or brute force it?

What are the issues with this approach in general?

Note that I'm not asking how to do this right, but what could the issues with this approach be, if any.

Answer 1

You are essentially asking if it is safe to pass secret parameters in a GET request. This is actually classified as a vulnerability. It is not feasible to brute force a sufficiently long pseudorandom string, assuming the server simply returns a static 404 response whenever an invalid path is specified, but there are numerous other security issues in practice that make this a dangerous technique:

• Logging software often logs GET requests in plaintext, but not POST.

• Using GET makes CSRF trivial^* when processing active content.

• Referer headers may leak secret values to other websites.

• Browser history will retain secrets passed in GET requests.

Your second example has /admin/ in it. This implies to me that knowledge of this path alone would be sufficient to authenticate to the server in an administrator context. This is very insecure and should not be done anymore than /?password=hunter2, a major web security faux pas.

Instead, secrets should be sent in a POST request. If this is not possible to do or if your threat model is exclusively to prevent brute force of the URL (for example, password reset links which are promptly invalidated after they are used), then it should be safe if done carefully. I am not aware of any side-channel attacks that would provide a method to obtain the string faster than brute force.

_{* Avoiding parameterized GET requests does not prevent CSRF attacks, which is a common misconception as there are various ways to similarly abuse POST (fake forms, etc), but passing secrets in GET does make CSRF easier.}

Answer 2

This is a common approach to share public things restricted to the ones who know the URL. An example is Google Docs:

The second option, "Anyone with the link", creates a link similar to yours. Same for Google Photos, Dropbox, ...

• The advantage is that the diffusion of the content is somewhat limited.
• The drawback is that this somewhat depends with whom you share the link, where it is published, etc.

One thing you should consider is the possibility to invalidate it easily (by changing/regenerating the link to your data)

Answer 3

Bad idea. A number of times I have seen a "secret" URL very quickly getting search engine crawler hits, and then discoverable by web search. Once I even saw someone set up a copy of a reputable website in a subfolder of his domain, share it with one person, and soon he was emailed a notice warning him that his domain may have been compromised for phishing purposes.

How did this happen? In the latter case, the web browser had a built in anti-phishing feature which sent visited URLs to fraud detection services. In the other cases, perhaps the browser was collecting browsing data and sending it to a search engine to collect user habits.

If you do this, make sure your robots.txt (or headers/meta tags) is set up to tell search engines not to index the content.

The internet is a wonderful way of bringing the world closer together, but unfortunately it gives everyone potentially permanent access to anything you happen to sneeze out.

Answer 4

If the secret part of the path is quite long [...] it'll be hard to guess or brute force it?

Yes. An attacker would have to guess the whole thing to discover it. Since there are many possibilities it would take an infeasible amount of time.

What are the issues with this approach in general?

The problem with this is that URLs are not considered secret, so they will be stored in the browser, in logs and by any intermediate proxies. That way, your "secret" URL may be exposed.

Using GET makes CSRF trivial when processing active content.

No. In a CSRF attack, the attacker forges a specific request. When using a secret in the URL, the attacker does not even know the correct URL to forge the request to. This means that CSRF is impossible as long as the URL is secret.

Answer 5

As others have stated, this isn't a good idea. Such "secret" links that are used to unsubscribe or similar one-off purposes are typically relatively short-lived, and of no use once they've been used once.

My initial thought when I read this question was that the url would not stay secret for long. I thought that perhaps Chrome (or any other modern web browser) would use the data from the address line to initialize a crawl. It turns out that they don't. However, the researchers discovered that plugins might still trigger a crawl:

The results are pretty simple: Googlebot never came to visit either page in the test.

As it turns out, two people in the test did not actually disable their extensions, and this resulted in visits from Open Site Explorer (someone had the Mozbar installed and enabled) and Yandex (due to a different person, though I’m not clear on what extension they had installed and enabled).

This means that once a link is used, it may be compromised by browser extensions. And then there's no need for brute forcing anything.

What is the purpose behind making these links? What are you, OP, trying to achieve? I'm certain that there are other ways to get there...

Answer 6

It'd be hard to guess/bruteforce but other ways to obtain the paths may be possible

For example, the url may be indexed by services such as google, bing, etc. This would make your "secret" url appear when an user searches your page in google. It can be solved configuring the robots.txt file, but remember that indexers may ignore it

Links in the application may redirect to the hidden path

In addition, machines in the same network as the user accessing the "secret" page or the web server can see the url, also every intermediary proxy and the user's ISP (Or VPN if he uses one)

Finally, the url may be persisted in the browser's cache and/or history and in the logs on the webserver and proxies

Answer 7

Can secret GET requests be brute forced?

Yes, they can. As much as any type of request without proper security measures.

If the secret part of the path is quite long, can I assume that it's safe to have such a secret page or area, and it'll be hard to guess or brute force it?

No, it's not safe to have such secret page or area. Yes, it will be hard to guess or brute force it.

What are the issues with this approach in general?

Unlike POST requests, GET requests can be easily found in the web browser history.

Answer 8

I think that it will better to implement an automatic or manual (so you'll decide who can access to the page) OTP One Time Password to send via email.

In a manual scenario:
- you receive the request from [email protected]
- you grant access to [email protected]
- the script create the link with the OTP
- the link will be mailed to [email protected]
- when the user [email protected] will visit the page the OPT will be flagged and nobody else can reuse that link

of course this system require a database where store the authorized email, OPT and flag field