Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You cannot simply publicly access private secure links, can you?

vin01.github.io

Post reply on HN
Print view View original

191–200 of 226 posts

Re: You cannot simply publicly access private secure links, can you?

#191

Post by FrustratedMonky »

lmm wrote: post #160
FrustratedMonky wrote: post #143

Earlier quoted context omitted.

Isn't that the point of the post? There are URL's that are out there 'as-if' public, but really should be private. And some people argue they should be treated as private, even if it is just a plain URL and public.

You can't blame the search engine for indexing plain URLs. Listing a closed-but-unlocked door is a bad analogy.

Well. You also can't charge joe blow with a crime for browsing URL's, that happen to be private but accidentally made public.

Just by looking, you are guilty. That is wrong.

Re: You cannot simply publicly access private secure links, can you?

#192

Post by paulgb »

ta1243 wrote: post #189
thayne wrote: post #177

Earlier quoted context omitted.

That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. And sometimes it isn't practical to require a POST request or a cookie. And the risk of a url leaking can be greatly mitigated if the url is only valid for a short period of time.

> That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed. Technically you're right -- after all sending an authentication as a separate header doesn't make any difference. GET /endpoint/?Auth=token or GET /endpoint Auth: token Sends the same data over the wire. However software treats URLs differently to headers. They sit in browser histo…

For better or worse, basic auth in the URL isn't really an option any more, (e.g. see https://stackoverflow.com/a/57193064). I think the issue was that it reveals the secret to anyone who can see the URL bar, but the alternative we got still has that problem and also has the problem that the secret is no longer separable from the resource identifier.

Re: You cannot simply publicly access private secure links, can you?

#193

Post by rjmunro »

blueflow wrote: post #52
masom wrote: post #49

Earlier quoted context omitted.

You won't find a specific link, but at some point if you generate millions of urls the 1024 bits will start to return values pretty quick through bruteforce. The one link won't be found quickly, but a bunch of links will. You just need to fetch all possibilities and you'll get data.

1024 bits seems a bit too much for the birthday problem to be a thing. I looked at [1] to do the calculation but (2^1024)! is a number too large for any of my tools. If someone has a math shortcut to test this idea properly... [1] https://en.wikipedia.org/wiki/Birthday_problem#Calculating_t...

2^1024 ≈ 10^300. There's only ≈10^80 atoms in the whole known universe. And we haven't even done the factorial.

Re: You cannot simply publicly access private secure links, can you?

#194

Post by loginatnine »

shiomiru wrote: post #146
loginatnine wrote: post #114

Earlier quoted context omitted.

It's called a fragment FYI!

However, window.location calls it "hash". (Also, the query string is "search". I wonder why Netscape named them this way...)

Interesting, thanks for the additional info.

Re: You cannot simply publicly access private secure links, can you?

#195

Post by cxr »

empath-nirvana wrote: post #21
QuercusMax wrote: post #19

I've always been a bit suspicious of infinite-use "private" links. It's just security thru obscurity. At least when you share a Google doc or something there's an option that explicitly says "anyone with the URL can access this". Any systems I've built that need this type of thing have used Signed URLs with a short lifetime - usually only a few minutes. And the URLs are generally an implementation detail that's not d…

There's functionally no difference between a private link and a link protected by a username and password or an api key, as long as the key space is large enough.

> There's functionally no difference between a private link and a link protected by a username and password or an api key

You mean mathematically there is no difference. Functionally there is a very, very big difference.

Re: You cannot simply publicly access private secure links, can you?

#196

Post by SilasX »

loginatnine wrote: post #114
r2b2 wrote: post #56

To create private shareable links, store the private part in the hash of the URL. The hash is not transmitted in DNS queries or HTTP requests. Ex. When links.com?token= is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare. Ex. When links.com# is visited, the hash portion will not leave the browser. Note: It's often nice to work with data in th…

It's called a fragment FYI!

Yeah I was confused by it being referred to as the hash.

https://en.wikipedia.org/wiki/URI_fragment?useskin=vector

Re: You cannot simply publicly access private secure links, can you?

#197

Post by anonymouscaller »

mschuster91 wrote: post #135
jmholla wrote: post #111

Earlier quoted context omitted.

> Ex. When links.com?token= is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare. Note: When over HTTPS, the parameter string (and path) is encrypted so the intermediaries in question need to be able to decrypt your traffic to read that secret. Everything else is right. Just wanted to provide some nuance.

Cloudflare, Akamai, AWS Cloudfront are all legitimate intermediaries.

Yes, see "Cloudbleed"

Re: You cannot simply publicly access private secure links, can you?

#198

Post by pixl97 »

FrustratedMonky wrote: post #129
internetter wrote: post #5

Earlier quoted context omitted.

Dorking is the technique of using public search engine indexes to uncover information that is presumed to be private. It has been used to uncover webcams, credit card numbers, confidential documents, and even spies. The problem is the website administers who are encoding authentication tokens into URL state, not the naive crawlers that find them.

"public search engine indexes" Then it should be the search engine at fault. If you leave your house unlocked is one thing. If there is a company trying everyone's doors, then posting a sign in the yard "this house is unlocked", has to account for something.

You've been appropriately downvoted for a terrible take.

Imagine if you left your house unlocked it would be broken into seconds later. Even worse, the people that broke into it live in a different country with no extradition law and you'd never figure out who they are anyway.

In this case your insurance company would tell you lock your damned doors and the police may even charge you under public nuisance laws.

Re: You cannot simply publicly access private secure links, can you?

#199

Post by eadmund »

phyzome wrote: post #126
r2b2 wrote: post #56

To create private shareable links, store the private part in the hash of the URL. The hash is not transmitted in DNS queries or HTTP requests. Ex. When links.com?token= is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare. Ex. When links.com# is visited, the hash portion will not leave the browser. Note: It's often nice to work with data in th…

Huge qualifier: Even otherwise benign Javascript running on that page can pass the fragment anywhere on the internet. Putting stuff in the fragment helps, but it's not perfect. And I don't just mean this in an ideal sense -- I've actually seen private tokens leak from the fragment this way multiple times.

Which is yet another reason to disable Javascript by default: it can see everything on the page, and do anything with it, to include sending everything to some random server somewhere.

I am not completely opposed to scripting web pages (it’s a useful capability), but the vast majority of web pages are just styled text and images: Javascript adds nothing but vulnerability.

It would be awesome if something like HTMX were baked into browsers, and if enabling Javascript were something a user would have to do manually when visiting a page — just like Flash and Java applets back in the day.

Re: You cannot simply publicly access private secure links, can you?

#200

Post by 1231232131231 »

layer8 wrote: post #96
internetter wrote: post #90

Earlier quoted context omitted.

We already have a solution to this. It’s called not including authentication information within URLs Even if search engines knew to include it, would every insecure place a user put a link know it? Bad actors with their own indexes certainly wouldn’t care

How do you implement password-reset links otherwise? I mean, those should be short-lived, but still.

A short-lived link that's locked down to their user agent/IP would work as well.
Post reply on HN