search

w3c / activitypub

http://w3c.github.io/activitypub/
Other
1.2k stars 77 forks source link

clarify/extend security consideration B.2 "verification" for attached files #432

Open Johann150 opened 5 months ago

Johann150 commented 5 months ago

As a thought after Mastodon's GHSA-jhrq-qvrm-qr36 it might be a good idea to extend the security consideration B.2 with a bit of wording about what kind of user submitted content is meant, and what relevance the Content-Type and perhaps Content Type Negotiation has in that context.

Especially when reading the 2nd paragraph the focus seems to me to be on ActivityPub Content, perhaps not taking into account that attached files/media may be hosted on the same host(-name).

In particular I'm thinking of wording like this:

Servers should not trust client submitted content (both ActivityPub activites and, if hosted by the same host, other resources), ...

And perhaps inserting another paragraph like this at the end of the section:

Federated servers that serve resources completely under the control of users, like for example attached media files, SHOULD make sure that the Content-Type header of such files can never be application/ld+json; profile="https://www.w3.org/ns/activitystreams" or application/activity+json. On paths/directories controlled by users, they SHOULD return the HTTP status code 406 "Not Acceptable" if a client's Accept header is set to application/ld+json; profile="https://www.w3.org/ns/activitystreams" as required of the client in section 3.2.

evanp commented 5 months ago

This is an issue with user-uploaded data. Here are some ways to mitigate:

  1. As suggested, No JSON uploads.
  2. Remote clients should check the content-type for JSON types when GETting, and don't accept e.g. text/plain as AP, maybe application/json.
  3. Use a separate domain for uploaded artifacts. This will prevent naive checks that just accept the same origin as verification.
  4. Develop an attribution endpoint FEP to check attribution of objects. Possibly other types of endpoints for other verification, including a server-wide verification.
  5. Use digital signatures. Who the signature is from and what it entails is an open question. E.g. is it client side, server side, user owned, server owned, ...

I believe this solution requires at least these fixes:

  1. A Primer page on the topic.
  2. An Erratum for the security consideration in verification that covers the issue.
  3. Potentially pushing the editor's draft to the public document.
ap-socialhub commented 4 months ago

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-0391-special-collection-proofs/4165/4