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.<p>Just last month, a story with a premise of discovering AWS account ids via buckets[0] did quite well on HN. The consensus established in the comments is that if you are relying on your account identifier being private as some form of security by obscurity, you are doing it wrong. The same concept applies here. This isn’t a novel security issue, this is just another method of dorking.<p>[0]: <a href="https://news.ycombinator.com/item?id=39512896">https://news.ycombinator.com/item?id=39512896</a>
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.<p>Ex. When links.com?token=<secret> is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare.<p>Ex. When links.com#<secret> is visited, the hash portion will not leave the browser.<p><i>Note: It's often nice to work with data in the hash portion by encoding it as a URL Safe Base64 string. (aka. JS Object ↔ JSON String ↔ URL Safe Base 64 String).</i>
Links that are not part of a fast redirect loop will be copied and pasted to be shared because that's what URLs are for, they're universal, they facilitate access to a resource available on a protocol.<p>Access control on anything that is not short-lived must be done outside of the url.<p>When you share links on any channel that is not e2ee, the first agent to access that url is not the person you're sending it to, it is the channel's service, it can be legitimate like Bitwarden looking for favicons to enhance UX, or malicious like FB Messenger crawler that wants to know more about what you are sharing in private messages.<p>Tools like these scanners won't get better UX, because if you explicitly tell users that the scans are public, some of them will think twice about using the service, and this is bad for business, wether they're using it for free or paying a pro license.
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".<p>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 directly shown to the user (although they can probably see them in the browser debug view).
When it comes to the internet if something like this is not protected by anything more than a random string in a URL then they aren't really private. Same story with all the internet connected web cams you can find if you go looking. I thought we knew this already. Why doesn't the "Who is responsible" section even mention this?
A workaround for this "email-based authentication" problem (without going to a full "make an account with a password" step) is to use temporary one-time codes, so that it doesn't matter if the URL gets accidentally shared.<p>1. User visits "private" link (Or even a public link where they re-enter their e-mail.)<p>2. Site e-mails user <i>again</i> with time-limited single-use code.<p>3. User enters temporary code to confirm ownership of e-mail.<p>4. Flow proceeds (e.g. with HTTP cookies/session data) with reasonable certainty that the e-mail account owner is involved.
Off topic: but that links to cloudflare radar which apparently mines data from 1.1.1.1. I was under the impression that 1.1.1.1 did not use user data for any purposes?
Can someone smarter explain to me what is different between?<p>1) domain.com/login user: John password: 5 char random password<p>2) domain.com/12 char random url<p>If we assume both either have the same bruteforce/rate limiting protection (or none at all). Why is 1 more safe than 2?
Zoom meeting links often have the password appended as a query parameter. Is this link a "private secure" link? Is the link without the password "private secure"?
Outlook.com leaks links to bing. At work it's a constant attack surface that I have to block by looking at the user agent string. Thankfully they are honest in the user agent!
"private secure links" are indistinguishable from any other link.<p>With HTTP auth links you know the password is a password, so these tools would know which part to hide from public display:<p>> <a href="https://username:password@example.com/page" rel="nofollow">https://username:password@example.com/page</a>
A while ago I started to only send password protected links via email. Just with the plaintext password inside the email. This might seem absurd and unsafe on the first glance, but those kind of attacks it can safely prevent. Adding an expiration time is also a good idea, even if it is as long as a few months.
There's a clear UX problem here. If you submit a scan it doesn't tell you it is public.<p>There can be a helpful fix: make clear that the scan is public! When submitting a scan it isn't clear, as the article shows. But you have the opportunity to also tell the user that it is public during the scan, which takes time. You also have the opportunity to tell them AFTER the scan is done. There should be a clear button to delist.<p>urlscan.io does a bit better but the language is not quite clear that it means the scan is visible to the public. And the colors just blend in. If something isn't catching to your eye, it might as well be treated as invisible. If there is a way to easily misinterpret language, it will always be misinterpreted. if you have to scroll to find something, it'll never be found.
A classic one that has a business built on this is pidgeonhole - literally private links for events with people hosting internal company events and users posing private sometimes confidential information. And even banks sign on to these platforms!
Tried it with the local alternative to Google Disk.
Oh my... Immediately found lots of private data, including photos of credit cars (with security codes), scans of IDs, passports...
How do you report a site?
I'm surprised no one has mentioned creating a standard that allows a these sites to check whether it's a private link or not.<p>For example, either a special HTTP header returned when making a HEAD request for the URL, or downloading a file similar to robots.txt that defines globs which are public/private.<p>At least this would (mostly) avoid these links becoming publicly available on the internetz.
Sure, you can!<p>This is the part where IP filtering by country and subnet can keep your ports hidden.<p>Also stateful firewall can be crafted to only let certain IP thru after sending a specially-crafted TOTP into a ICMP packet just to get into opening the firewall for your IP.
Over at pico.sh we are experimenting with an entirely new type of private link by leveraging ssh local forward tunnels: <a href="https://pgs.sh/" rel="nofollow">https://pgs.sh/</a><p>We are just getting started but so far we are loving the ergonomics.
Well this is interesting. Even quickly searching "docs.google.com" on urlscan.io gets me some spreadsheets with lists of people's names, emails, telephone numbers, and other personal information.
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.<p>* this obviously assumes the objects have a 1-1 mapping with users
Reminds me how some would search for bitcoin wallets via google and kazaa.<p>On a side note, can someome remind me what was the name of the file, I think I have some tiny fraction of a bicoin on an old computer