zlacker

[return to "So this guy is now S3. All of S3"]
1. arianv+53[view] [source] 2023-05-04 19:07:02
>>aendru+(OP)
This is why mastodon , webfinger and ACME uss .well-known uri prefix. .well-known is reserved and you can't e.g. make a bucket named .well-known

It's funny the bluesky devs say they implemented "something like webfinger" but left out the only important part of webfinger that protects against these attacks in the first place. Weird oversight and something something don't come up with your own standards

◧◩
2. Nick87+x6[view] [source] 2023-05-04 19:21:24
>>arianv+53
What about serving the challenge file from the root or a near-root of the fully qualified url? Like www.domain.com/mastodon.txt or abc.freehost.com/mastodon.txt?

Maybe I'm old but what are some popular use cases for webfinger? (I'm just learning about it now)

◧◩◪
3. chrism+m9[view] [source] 2023-05-04 19:34:51
>>Nick87+x6
The /.well-known/ path prefix is the standard name to use (https://www.rfc-editor.org/rfc/rfc8615) so that any sort of “we’ll host user content from our domain” thing can block it. (Hosting user content from the user’s domain is fine and doesn’t need this restriction.)

A few things are effectively grandfathered in due to their vintage: /favicon.ico, /sitemap.xml and /robots.txt are the three that occur to me—so if you’re running something vaguely like S3, you’ll want to make sure users can’t create files at the top level of your domain matching at least those names.

But nothing new should use anything other than /.well-known/ for domain-scoped stuff, or else you run into exactly this problem.

◧◩◪◨
4. cesarb+8r[view] [source] 2023-05-04 21:03:49
>>chrism+m9
> A few things are effectively grandfathered in due to their vintage: /favicon.ico, /sitemap.xml and /robots.txt are the three that occur to me—so if you’re running something vaguely like S3, you’ll want to make sure users can’t create files at the top level of your domain matching at least those names.

I also recall /crossdomain.xml as an important one; allowing users to create an arbitrary file matching that name could allow certain kinds of cross-site attacks against your site.

◧◩◪◨⬒
5. ehPRet+it[view] [source] 2023-05-04 21:15:59
>>cesarb+8r
I think crossdomain.xml died with Flash but I could be wrong, does anyone know?
◧◩◪◨⬒⬓
6. roblab+Kv[view] [source] 2023-05-04 21:29:17
>>ehPRet+it
None of the standardized web technologies use crossdomain.xml, but I think Acrobat Reader still uses it for... stuff. And acrobat still has a browser plugin, so I guess it's still a potential vector for abuse.
◧◩◪◨⬒⬓⬔
7. ehPRet+o51[view] [source] 2023-05-05 02:15:11
>>roblab+Kv
ah! Reader. That's a fun one. I once encountered an "Acrobat Reader-only" PDF that after filling out and selecting any applicable attachments on your filesystem you then... literally put in your credentials to the website in the PDF so that it could.. submit itself. I lost some braincells seeing that..
◧◩◪◨⬒⬓⬔⧯
8. capeco+x61[view] [source] 2023-05-05 02:30:06
>>ehPRet+o51
Oh man, then you really don’t want to know about a product I once created.

Reader could have an optional Flash plugin, and better yet, you could configure the PDF interactive plugin to dynamically download the swf file to run.

I built an entire Flex based rich UI that was dynamically loaded by the 1kb PDF you’d receive in email, the Flex app retrieved and posted data via HTTP APIs.

Because reasons.

That product was live for years. I think we shut it down as recently as 2 years ago.

To be 100% clear, wasn’t my idea.

But it was my mistake to joke about the absurd possibility to build such a thing in front of some biz folks.

◧◩◪◨⬒⬓⬔⧯▣
9. ehPRet+va1[view] [source] 2023-05-05 03:22:34
>>capeco+x61
oh looooooooooooord. O_O
◧◩◪◨⬒⬓⬔⧯▣▦
10. ehPRet+Qg6[view] [source] 2023-05-06 19:14:25
>>ehPRet+va1
https://twitter.com/subtee/status/1654858616065732609?s=12

in an interesting coincidence, I found this today!

[go to top]