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

181–190 of 226 posts

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

#181

Post by Dylan16807 »

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...

This isn't the birthday problem. That would be the chance of two random links overlapping. The birthday problem scales with n^2, while trying to guess links scales with m * n, number of guesses multiplied by number of links.

(Well, before you apply the logistic taper to it. So you wanted an approximation? There you go. Until you get the chance of a hit to be quite high, it's basically equal to guesses * valid links / 2^1024.)

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

#182

Post by Dylan16807 »

vel0city wrote: post #30
empath-nirvana wrote: post #21

Earlier quoted context omitted.

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 one big functional difference. People don't normally have their username and password or API key directly in the URL. Example 1: Alice wants Bob to see CoolDocument. Alice generates a URL that has the snowflake in the URL and gives it to Bob. Eve manages to see the chat, and can now access the document. Example 2: Alice wants Bob to see CoolDocument. Alice clicks "Share with Bob" in the app, grabs the URL to…

Example 2 sounds like a pretty big pain if I can't go directly from Bob's chat account to his document account. Which is the case the vast majority of the time.

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

#183

Post by reaperman »

rkagerer wrote: post #180
fullspectrumdev wrote: post #174

Earlier quoted context omitted.

So there was an interesting vector a while back where some email firewalls would reliably click on any link sent to them that was abused by spammers. Spammers would sign up for services that required a click on a link using blabla@domainusingsuchservice The services bots to check phishing would reliably click on the link, rendering the account creation valid. One particularly exploitable vendor for getting such links…

SharkGate? Why coy about naming them?

Barracuda. And for plausible deniability so they don’t have as much of a chance of catching a libel suit. Not sure how necessary or effective that is, but I do understand the motivation.

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

#184

Post by rapind »

fullspectrumdev wrote: post #173
andersa wrote: post #170

Earlier quoted context omitted.

I mean of course the idea was to put it in a form that is sent using POST, but even then, it's a single-use reset code so once it shows in the log it's worthless.

This makes a large assumption about application logic that is often incorrect. t. security auditor/researcher.

It certainly does. Security usually comes at the cost of convenience and can incur confusion.

In this example, where best practice may be to use one time tokens, you will end up with users who click on the secure link again (from their email) in the future to access the secure site and they’ll be frustrated when they have to go through the secure link generation dance again.

Of course you can mitigate this with sessions / cookies, but that is also a security compromise and not device portable.

It’s easy to say that these are minor uxp concerns, but enforcing a high level of security may have a significant user cost depending on your demographic. I have a demographic that skews older and non technical and they are pretty loud when they complain about this stuff… meanwhile they are also more likely to reuse passwords and forward emails with secure links in them!

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

#185

Post by nmadden »

Sn0wCoder wrote: post #150
nmadden wrote: post #48

Earlier quoted context omitted.

I wrote about putting secrets in URLs a few years ago: https://neilmadden.blog/2019/01/16/can-you-ever-safely-inclu...

Question in the Waterken-Key flow with token in the URL fragment the URL looks like HTTPS www.example.com/APP/#mhbqcmmva5ja3 – but in the diagram its hitting example.com/API/#mhbqcmmva5ja3 Is this a type-o OR are we mapping APP to API with the proxy so the user thinks they are going to the APP with their Key. Or does the browser do us for us automatically when it sees app in the URL and then stores the key in window.…

Oops, that’s a typo.

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

#186

Post by jeroenhd »

snthd wrote: post #138

"private secure links" are indistinguishable from any other link. With HTTP auth links you know the password is a password, so these tools would know which part to hide from public display: > https://username:password@example.com/page

I think it's quite funny that the URL spec has a section dedicated to authentication, only for web devs to invent ways to pass authentication data in any way but using the built-in security mechanism.

I know there are valid reasons (the "are you sure you want to log in as usernam on example.com?" prompt for example) but this is just one of the many ways web dev has built hacks upon hacks where implementing standards would've sufficed. See also: S3 vs WebDAV.

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

#187

Post by conductr »

rapind wrote: post #184
fullspectrumdev wrote: post #173

Earlier quoted context omitted.

This makes a large assumption about application logic that is often incorrect. t. security auditor/researcher.

It certainly does. Security usually comes at the cost of convenience and can incur confusion. In this example, where best practice may be to use one time tokens, you will end up with users who click on the secure link again (from their email) in the future to access the secure site and they’ll be frustrated when they have to go through the secure link generation dance again. Of course you can mitigate this with sessi…

Some people will always find something to complain about. I feel like it’s completely reasonable to give a “sorry this link was only valid for 5 minutes and is now expired, request a new code here” message. State it in the email that originally contained the link and state it again on the page when they click it afterwards. This is incredibly common practice and very unlikely to be the first time someone has seen this workflow. If they want to complain further, direct them to a password manager and remind them there’s probably one built into their browser already

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

#188

Post by ta1243 »

Dylan16807 wrote: post #181
blueflow wrote: post #52

Earlier quoted context omitted.

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...

This isn't the birthday problem. That would be the chance of two random links overlapping. The birthday problem scales with n^2, while trying to guess links scales with m * n, number of guesses multiplied by number of links. (Well, before you apply the logistic taper to it. So you wanted an approximation? There you go. Until you get the chance of a hit to be quite high, it's basically equal to guesses * valid links /…

The chance is less than guessing a random 128 bit username and random 128 bit password. And then guessing a completely different username and password on the very next go.

You'd get far more return on investment breaking bitcoin wallets.

2^1024 is 10^308

Lets say there are 12 billion links per person, and 8 billion people. That's 100 billion billion, or 10^20 links.

10^20 / 10^308 is zero.

Lets say you can test 10 trillion links a second, and started when the big bang happened, you'll have tested 10^30 links so far.

The number of links you'll have found so far is zero.

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

#189

Post by ta1243 »

thayne wrote: post #177
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.

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 histories, server logs, get parsed by MITM firewalls, mined by browser extensions, etc

using https://user:pass@site.com/endpoint or https://auth:token@site.com/endpoint

Would be better than

https://site.com/endpoint/user/pass or https://site.com/endpoint/?auth=token

As the former is less likely to be stored, either on the client or on the server. I don't do front end (or backend authentication -- I just rely on x509 client certs or oidc and the web server passes the validated username)

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

#190

Post by ta1243 »

couchand wrote: post #168
vin10 wrote: post #85

Earlier quoted context omitted.

You are right about short expiry times but another catch here is that if pre-signed URLs are being leaked in an automated fashion, these services also keep the downloaded content from these URLs around. I found various such examples where links no longer work, but PDFs downloaded from pre-signed URLs were still stored by scanning services. From https://urlscan.io/blog/2022/07/11/urlscan-pro-product-updat... > In the…

Indeed, the only valid operation with the magic URL is exchanging the URL-based token with something else (your PDF, a session token, etc.) and then expiring the URL, so by the time the scanner gets around to it the original URL is invalid.

That seems ripe for race condition class problems.
Post reply on HN