← Back to context

Comment by arianvanp

3 years ago

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

35 comments

arianvanp

Reply
bscphil  3 years ago

> This is why mastodon , webfinger and ACME uss .well-known uri prefix

This is not how Mastodon does verification (at least not the main method). Mastodon doesn't just link users -> domain. It can link user -> webpage, for example to link social profiles between sites.

If you have a website with user generated content, and a user can set an arbitrary html attribute (rel="me") in a link pointing back to their profile, they can claim ownership of the page on Mastodon. Likewise, if they can set a link tag in the head element of the page for some reason.

Presumably this is somewhat harder to exploit than a (new, poorly thought out) dependency on a static file under /xrpc, but Mastodon does introduce more authentication footguns for sites than just .well-known! https://docs.joinmastodon.org/user/profile/#verification

Edit: authentication -> verification, since Mastodon distinguishes between the two (see below)

  • madeofpalk  3 years ago

    Neither of these are 'authentication'

    You're thinking of how Mastodon does verified links. You could do something similar, provide a verified link on your profile to a file in an S3 bucket, but there's very utility (or risk) in that.

    Mastodon also allows you to be discoverable via a custom domain, using .well-known as parent mentioned https://docs.joinmastodon.org/spec/webfinger/ https://www.hanselman.com/blog/use-your-own-user-domain-for-...

    • bscphil  3 years ago

      I'm thinking, mainly, of how these features are exposed in the UI and how users experience it. What matters is that users take (rightly or wrongly) a verified profile link to mean "I control this webpage". So e.g. if you could verify a Twitter handle on Mastodon, it would mean "if you trust the identity of this Twitter handle, you should also trust the validity of this Mastodon user". That's extremely important to get right no matter what you call it.

      I'm not sure what Bluesky was attempting to do here but what they achieved in practice was allowing a user to claim control of a domain by claiming control of a page. But if you allow user generated content on the home page of your site, there's not a distinction (from a Mastodon user point of view) between the two. It's effectively the same problem if I can "verify" yourdomain.com on Mastodon - and my point is that you can do that without using .well-known.

      1 reply →

Nick87633  3 years ago

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)

  • chrismorgan  3 years ago

    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.

    • cesarb  3 years ago

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

      9 replies →

  • ownagefool  3 years ago

    Or why not just serve it from www.domain.com/.well-known so we only have one thing to block. :p

  • bowmessage  3 years ago

    s3 supports my-bucket.s3-us-west-2.amazonaws.com style URLs as well

    • thayne  3 years ago

      In fact the path method is deprecated, but I don't know if support will ever be removed, because some (old) buckets have periods in their names, and therefore don't work with the subdomain format.

jascination  3 years ago

I use S3 for a simple app landing page and I use .well-known for deeplinks... Unless I'm misunderstanding your comment which I probably am.

  • roblabla  3 years ago

    Yes, but you don't have access to s3.amazonaws.com/.well-known, only to yourdomain.s3.amazonaws.com/.well-known.

benatkin  3 years ago

.well-known seems unintuitive

Also the penalty isn't very high here. Someone impersonated a domain on a burgeoning protocol for a short while. So what?

  • ceejayoz  3 years ago

    > .well-known seems unintuitive

    We're talking about folks setting up a custom domain for a personal social media presence. If they can handle nameservers and DNS records, they can handle a folder with a dot in the name.