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

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

#221

Post by albert_e » Sun, Mar 10, 2024, 4:35 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…

Aha. That is an interesting issue indeed.

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

#222

Post by BlueTemplar » Sun, Mar 10, 2024, 12:31 PM 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.

This condemnation comes to mind :

https://arstechnica.com/tech-policy/2014/02/french-journalis...

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

#223

Post by kube-system » Sun, Mar 10, 2024, 8:00 PM UTC

nullc wrote: post #217

kube-system wrote: post #81

Earlier quoted context omitted.

https://1.1.1.1/dns/ > We will never sell your data or use it to target ads. https://developers.cloudflare.com/1.1.1.1/privacy/public-dns... > Cloudflare will not sell or share Public Resolver users’ personal data with third parties or use personal data from the Public Resolver to target any user with advertisements. There's a lot of transparency on that page in particular, down to the lists of the fields in the logs…

Ads are among the most benign things someone could use your private information to do. With your personal information: * Parties can engage in price discrimination against you. (You don't shop around? you've got some extra spending money? double prices! Looking up risky activities? high insurance rates!) * Parties can engage in lawfare and blackmail * Parties can influence elections (without advertising, e.g. by gerr…

I agree, but it is not really in CF's interest to engage in any of those activities.

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

#224

Post by FrustratedMonky » Mon, Mar 11, 2024, 12:05 PM UTC

pixl97 wrote: post #198

FrustratedMonky wrote: post #129

Earlier quoted context omitted.

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

"" Imagine a journalist finds a folder on a park bench, opens it, and sees a telephone number inside. She dials the number. A famous rapper answers and spews a racist rant. If no one gave her permission to open the folder and the rapper’s telephone number was unlisted, should the reporter go to jail for publishing what she heard?

If that sounds ridiculous, it’s because it is. And yet, add in a computer and the Internet, and that’s basically what a newly unsealed federal indictment accuses Florida journalist Tim Burke of doing when he found and disseminated outtakes of Tucker Carlson’s Fox News interview with Ye, the artist formerly known as Kanye West, going on the first of many antisemitic diatribes.""

https://arstechnica.com/tech-policy/2024/03/charges-against-...

"According to Burke, the video of Carlson’s interview with Ye was streamed via a publicly available, unencrypted URL that anyone could access by typing the address into your browser."

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

#225

Post by mbrumlow » Mon, Mar 11, 2024, 2:39 PM UTC

1231232131231 wrote: post #203

ummonk wrote: post #154

Earlier quoted context omitted.

The same can almost as easily happen with user-submitted passwords.

Passwords usually don't show up in server logs if submitted correctly.

Love your qualifier. “If submitted correctly”.

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

#226

Post by couchand » Tue, Mar 12, 2024, 12:33 PM UTC

fragmede wrote: post #220

couchand wrote: post #213

Earlier quoted context omitted.

If anybody but the intended recipient gets the magic URL first there's something more critical wrong with some assumption in your authentication scheme.

In the war against malware on the web, messenger services like Facebook messenger and google chat have been known to visit links passed through their service. the attacker hijacks an account, and then sends the malware link to all of that users contacts. coming from a trusted source, those contacts visit the link, and they get their account hijacked, and the cycle continues. in order to combat this, the platforms wil…

You describe a very real problem, but from what I can tell it's an entirely disjoint context. I'm honestly not clear what the scenario you're suggesting is. Your platform would send an authenticated URL to a verified user over a verified communications channel. There may be applications where the channel of choice is a social media service, but I'm having a hard time seeing why you support that but not support the bog standard OAuth flow for that provider?

Or are you just saying, sometimes a user will receive their authenticated URL on the verified channel and then self-leak it on another channel? In which case, it really doesn't matter what that other channel is...