TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

420 点作者 vin10大约 1 年前

26 条评论

internetter大约 1 年前
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:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39512896">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39512896</a>
评论 #39631305 未加载
评论 #39631377 未加载
评论 #39631905 未加载
评论 #39635591 未加载
评论 #39632212 未加载
评论 #39635373 未加载
r2b2大约 1 年前
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=&lt;secret&gt; is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare.<p>Ex. When links.com#&lt;secret&gt; is visited, the hash portion will not leave the browser.<p><i>Note: It&#x27;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>
评论 #39634499 未加载
评论 #39634882 未加载
评论 #39634192 未加载
评论 #39633861 未加载
评论 #39634530 未加载
评论 #39634556 未加载
评论 #39633416 未加载
rpigab大约 1 年前
Links that are not part of a fast redirect loop will be copied and pasted to be shared because that&#x27;s what URLs are for, they&#x27;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&#x27;re sending it to, it is the channel&#x27;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&#x27;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&#x27;re using it for free or paying a pro license.
QuercusMax大约 1 年前
I&#x27;ve always been a bit suspicious of infinite-use &quot;private&quot; links. It&#x27;s just security thru obscurity. At least when you share a Google doc or something there&#x27;s an option that explicitly says &quot;anyone with the URL can access this&quot;.<p>Any systems I&#x27;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&#x27;s not directly shown to the user (although they can probably see them in the browser debug view).
评论 #39631773 未加载
评论 #39633420 未加载
scblock大约 1 年前
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&#x27;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&#x27;t the &quot;Who is responsible&quot; section even mention this?
评论 #39631574 未加载
Terr_大约 1 年前
A workaround for this &quot;email-based authentication&quot; problem (without going to a full &quot;make an account with a password&quot; step) is to use temporary one-time codes, so that it doesn&#x27;t matter if the URL gets accidentally shared.<p>1. User visits &quot;private&quot; 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&#x2F;session data) with reasonable certainty that the e-mail account owner is involved.
amanda99大约 1 年前
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?
评论 #39632068 未加载
victorbjorklund大约 1 年前
Can someone smarter explain to me what is different between?<p>1) domain.com&#x2F;login user: John password: 5 char random password<p>2) domain.com&#x2F;12 char random url<p>If we assume both either have the same bruteforce&#x2F;rate limiting protection (or none at all). Why is 1 more safe than 2?
评论 #39631814 未加载
评论 #39632264 未加载
评论 #39631646 未加载
评论 #39632308 未加载
评论 #39634581 未加载
评论 #39632753 未加载
评论 #39631687 未加载
评论 #39631992 未加载
评论 #39634040 未加载
评论 #39631628 未加载
sbr464大约 1 年前
All media&#x2F;photos you upload to a private airtable.com app are public links. No authentication required if you know the url.
评论 #39636058 未加载
评论 #39631867 未加载
ttymck大约 1 年前
Zoom meeting links often have the password appended as a query parameter. Is this link a &quot;private secure&quot; link? Is the link without the password &quot;private secure&quot;?
评论 #39632722 未加载
boxed大约 1 年前
Outlook.com leaks links to bing. At work it&#x27;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!
snthd大约 1 年前
&quot;private secure links&quot; 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>&gt; <a href="https:&#x2F;&#x2F;username:password@example.com&#x2F;page" rel="nofollow">https:&#x2F;&#x2F;username:password@example.com&#x2F;page</a>
评论 #39638669 未加载
andix大约 1 年前
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.
godelski大约 1 年前
There&#x27;s a clear UX problem here. If you submit a scan it doesn&#x27;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&#x27;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&#x27;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&#x27;ll never be found.
评论 #39633979 未加载
dav43大约 1 年前
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!
kgeist大约 1 年前
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?
JensRantil大约 1 年前
I&#x27;m surprised no one has mentioned creating a standard that allows a these sites to check whether it&#x27;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&#x2F;private.<p>At least this would (mostly) avoid these links becoming publicly available on the internetz.
egberts1大约 1 年前
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.
qudat大约 1 年前
Over at pico.sh we are experimenting with an entirely new type of private link by leveraging ssh local forward tunnels: <a href="https:&#x2F;&#x2F;pgs.sh&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pgs.sh&#x2F;</a><p>We are just getting started but so far we are loving the ergonomics.
65大约 1 年前
Well this is interesting. Even quickly searching &quot;docs.google.com&quot; on urlscan.io gets me some spreadsheets with lists of people&#x27;s names, emails, telephone numbers, and other personal information.
getcrunk大约 1 年前
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
rvba大约 1 年前
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
figers大约 1 年前
We have done one time use query string codes at the end of a URL sent to a user email address or as a text message to allow for this...
overstay8930大约 1 年前
Breaking news: Security by obscurity isn&#x27;t actually security
评论 #39634508 未加载
评论 #39632401 未加载
zzz999大约 1 年前
You can if you use E2EE and not CAs
BobbyTables2大约 1 年前
What happened to REST design principles?<p>A GET isn’t supposed to modify server state. That is reserved for POST, PUT, PATCH…