You cannot simply publicly access private secure links, can you? • Hacker News Board

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

#161

Post by bigiain » Thu, Mar 07, 2024, 11:48 PM UTC

zer00eyz wrote: post #144

tsimionescu wrote: post #133

Earlier quoted context omitted.

Actually, there are cases where this is more or less unavoidable. For example, if you want a web socket server that is accessible from a browser, you need authentication, and can't rely on cookies, the only option is to encode the Auth information in the URL (since browsers don't allow custom headers in the initial HTTP request for negotiating a web socket).

Authentication: Identify yourself Authorization: Can you use this service. Access Control/Tokenization: How long can this service be used for. I swipe my badge on the card reader. The lock unlocks. Should we leave a handy door stopper or 2x4 there, so you can just leave it propped open? Or should we have tokens that expire in a reasonable time frame.. say a block of ice (in our door metaphor) so it disappears at some…

> Or should we have tokens that expire in a reasonable time frame.

And that are single-use.

(Your password reset "magic link" should expire quickly, but needs a long enough window to allow for slow mail transport. But once it's used the first time, it should be revoked so it cannot be used again even inside that timeout window.)

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

#162

Post by andix » Thu, Mar 07, 2024, 11:49 PM UTC

sbr464 wrote: post #28

All media/photos you upload to a private airtable.com app are public links. No authentication required if you know the url.

There is a dilemma for web developers with images loaded from CDNs or APIs. Regular tags can't set an Authorization header with a token for the request, like you can do with fetch() for API requests. The only possibility is adding a token to the URL or by using cookie authentication.

Cookie auth only works if the CDN is on the same domain, even a subdomain can be problematic in many cases.

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

#163

Post by getcrunk » Thu, Mar 07, 2024, 11:50 PM UTC

What’s wrong with using signed urls and encrypting the object with a unique per user key. It’s adds some cpu time but if it’s encrypted it’s encrypted.

* this obviously assumes the objects have a 1-1 mapping with users

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

#164

Post by hnlmorg » Thu, Mar 07, 2024, 11:57 PM UTC

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.

As you said, short lived codes. And the codes don’t contain any PII. So even if the link does get indexed, it’s meaningless and useless.

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

#165

Post by fiddlerwoaroof » Fri, Mar 08, 2024, 12:02 AM UTC

maxcoder4 wrote: post #147

fiddlerwoaroof wrote: post #66

Earlier quoted context omitted.

Yeah, I’ve always hated this saying because all security involves something that is kept secret, or “obscure”. Also, obscurity is a valid element of a defense in depth strategy

The idea behind "security thorough obscurity" is that even if the adversary knows everything about your setup *except the secret keys*, you should be secure. Security through obscurity is any method of protection other than the secret key, like for example: * serving ssh on a random high port * using a custom secret encryption algorithm * hosting an unauthenticated service on a secret subdomain in hope nobody will fi…

But, this is just relying on the obscurity of the key: all security comes down to some form of secret knowledge. It’s just better to use a space that’s hard to enumerate than a low-cardinality space: if we had 1024 bits of port numbers, picking a random port would be as hard to crack as a 1024 bit encryption key.

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

#166

Post by bachmeier » Fri, Mar 08, 2024, 12:07 AM UTC

7952 wrote: post #71

bachmeier wrote: post #43

Earlier quoted context omitted.

> The fundamental issue is that links without any form of access control are presumed private, simply because there is no public index of the available identifiers. Is there a difference between a private link containing a password and a link taking you to a site where you input the password? Bitwarden Send gives a link that you can hand out to others. It has # followed by a long random string. I'd like to know if th…

There is a difference in that people intuitively know that entering passwords gives access. Also, it may be different legally as the user could reasonably be expected to know that they are not supposed to access something.

> There is a difference in that people intuitively know that entering passwords gives access.

This is a valid argument. However, I'd say that there are two standard practices with links that are a big advantage: giving them a short life, and generating extremely hard to guess URLs. I was a Lastpass customer before their security problems came out. I had many passwords that I made years ago but don't use the service any longer. I moved more into the URL camp at that time. Who knows how many passwords I made 15 or 20 years ago that today are no longer secure.

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

#167

Post by autoexec » Fri, Mar 08, 2024, 12:07 AM UTC

amanda99 wrote: post #69

kube-system wrote: post #39

Earlier quoted context omitted.

CF doesn't sell it or use it for marketing, but the entire way they even got the addresses was because APNIC wanted to study the garbage traffic to 1.1.1.1.

> CF doesn't sell it or use it for marketing Any source for this? Do you work there? I checked their docs and they say they don't "mine user data", so I wouldn't trust anything they say, at least outside legal documents.

> so I wouldn't trust anything they say, at least outside legal documents

I wouldn't trust them even if it were in legal docs. Companies have a long history of being perfectly fine with breaking the law when doing so is profitable, especially when they're likely to get little more than a slap on the wrist when caught, and the odds of being caught in the first place are slim.

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

#168

Post by couchand » Fri, Mar 08, 2024, 12:38 AM UTC

vin10 wrote: post #85

albert_e wrote: post #68

Earlier quoted context omitted.

"presigned" URLs[1] are a pretty standard and recommended way of providing users access to upload/download content to Amazon S3 buckets without needing other forms of authentication like IAM credential pair, or STS token, etc Web Applications do utilize this pattern very frequently But as noted i previous comment these do have short expiry times (configurable) so that there is no permanent or long-term risk on the li…

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.

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

#169

Post by vmfunction » Fri, Mar 08, 2024, 12:49 AM UTC

andersa wrote: post #99

layer8 wrote: post #96

Earlier quoted context omitted.

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

You could send the user a code that they must copy paste onto the page rather than sending them a link.

Hopefully using POST not GET. The GET links get logged in the HTTP server most of time. Just another great way to store your 'security credential' in plain text. Logs gets zipped and archive. Good luck with any security measure.

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

#170

Post by andersa » Fri, Mar 08, 2024, 1:04 AM UTC

vmfunction wrote: post #169

andersa wrote: post #99

Earlier quoted context omitted.

You could send the user a code that they must copy paste onto the page rather than sending them a link.

Hopefully using POST not GET. The GET links get logged in the HTTP server most of time. Just another great way to store your 'security credential' in plain text. Logs gets zipped and archive. Good luck with any security measure.

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.