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!
You cannot simply publicly access private secure links, can you?
171–180 of 226 posts
Re: You cannot simply publicly access private secure links, can you?
#172Earlier quoted context omitted.
If it doesn't leave the browser, how would the server know to serve the private content?
Client web app makes POST request. It leaves browser, but not in URL
That only works if you can run JavaScript. If you want to download a file with curl for example it fails.
Re: You cannot simply publicly access private secure links, can you?
#173Earlier quoted context omitted.
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.
This makes a large assumption about application logic that is often incorrect.
t. security auditor/researcher.
Re: You cannot simply publicly access private secure links, can you?
#174Earlier 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
Also, it would allow bad actors to just opt out of malware scans - the main vector whereby these insecure URLs were leaked.
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 clicked was one that shares the name with a predatory fish that also has a song about it :)
Re: You cannot simply publicly access private secure links, can you?
#175The 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. 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,…
Bit of a tangent, but I was recently advised by a consultant that pushing private Nix closures to a publicly-accessible S3 bucket was fine since each NAR file has a giant hash in the name. I didn't feel comfortable with it so we ended up going a different route, but I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request fo…
> I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request for the URL
Extremely different. The former depends on the existence of a contract about URL privacy (not to mention third parties actually adhering to it) when no such contract exists. Any design for an auth/auth mechanism that depends on private links is inherently broken. The very phrase "private link" is an oxymoron.
> I am not sure why you think that having an obscure URI format will somehow give you a secure call (whatever that means). Identifiers are public information.
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>
Re: You cannot simply publicly access private secure links, can you?
#176Earlier quoted context omitted.
Worked for a company which ran into an S3 bucket naming collision when working with a client - turns out that both sides decided hyphenated-company-name was a good S3 bucket name (my company lost that race obviously). One of those little informative pieces where everytime I do AWS now all the bucket names are usually named - . If it's really meant to be private then you encrypt the project-name too and provide a scri…
What would encrypting the project name accomplish? Typically if you’re trying to secure a S3 bucket you’ll do that via bucket settings. Many years ago you had to jump through hoops to get things private, but these days there’s a big easy button to make a bucket inaccessible publicly.
The point is that in some cases the name of the project might itself be considered sensitive in some way, so preventing people testing bucket names by trying to create them helps prevent it, but doesn't completely lock you out of being able to associate the bucket back to its internal name, and allows the names to be deterministic internally - i.e. someone spinning up a test environment is still getting everything marked appropriately, deterministically, and uniquely.
Re: You cannot simply publicly access private secure links, can you?
#177Earlier quoted context omitted.
The problem is links leak. In theory a 256 hex-character link (so 1024 bits) is near infinitely more secure than a 32 character username and 32 character password, as to guess it https://site.com/[256chars] As there's 2^1024 combinations. You'd never brute force it vs https://site,com/[32chars] with a password of [32chars] As there's 2^256 combinations. Again you can't brute force it, but it's more likely than the 2^…
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.
Re: You cannot simply publicly access private secure links, can you?
#178What happened to REST design principles?
A GET isn’t supposed to modify server state. That is reserved for POST, PUT, PATCH…
Re: You cannot simply publicly access private secure links, can you?
#179Earlier quoted context omitted.
To somewhat mitigate the link-loading bot issue, the link can land on a "confirm sign in" page with a button the user must click to trigger the POST request that completes authentication. Another way to mitigate this issue is to store a secret in the browser that initiated the link-request (Ex. local storage). However, this can easily break in situations like private mode, where a new tab/window is opened without acc…
> a button the user must click Makes sense. No action until the user clicks something on the page. One extra step but better than having “helpful bots” wreak havoc. > to store a secret in the browser […] is doing a browser fingerprint match I get the idea but I really dislike this. Assuming the user will use the same device or browser is an anti-pattern that causes problems with people especially while crossing the m…
I agree, better to use an additional factor than fingerprinting.
Re: You cannot simply publicly access private secure links, can you?
#180Earlier quoted context omitted.
Also, it would allow bad actors to just opt out of malware scans - the main vector whereby these insecure URLs were leaked.
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?