Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Saturday, 06-Sep-2025 19:19:05 JST silverpill

   Added new requirements to FEP-ef34:

   https://codeberg.org/fediverse/fep/pulls/672

   Previously the FEP put the burden of C2S validation solely on the originating server (producer), but I think it would be better to do corresponding security checks on the consumer side too:

   - When fetching an object: verify that Content-Type includes one of the AP & AS media types.
   - When verifying a signature: also perform same-owner check and verify key ownership.

   Both are already considered good practices in the Fediverse.

   I also attempted to clarify how fetching from origin (authentication) is related to access control (authorization).

   #fep_fe34

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Friday, 12-Sep-2025 09:52:27 JST silverpill

     in reply to

     • tesaguri 🦀🦝

     @tesaguri What do you think about the recommendations given in FEP-fe34? ^

     GHSA-jhrq-qvrm-qr36 is written as if Mastodon is guilty, because it didn't check Content-Type header. However, I think we should blame the servers that failed to validate uploaded documents, because it is their actors get impersonated.

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Friday, 12-Sep-2025 23:09:16 JST tesaguri 🦀🦝

     in reply to

     @silverpill Actually I didn't think Mastodon was to blame either. I asked them to word the GHSA that way only because my report to the editors of ActivityPub spec was not public yet so I was not comfortable to publicly call it as a problem of AP in general.

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Friday, 12-Sep-2025 23:09:16 JST tesaguri 🦀🦝

     in reply to

     • Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     @silverpill That said, when I reported the spoofing vulnerability to @evan, what was in my consideration was not only impersonations, but also craft of fake AS documents on *non-AP* servers. For example, anyone can upload an AS actor document to GitHub, claiming it to be "GitHub support", which might be useful for phishing. While you shouldn't trust a random account calling itself "the support", a common user expectation should suggest that no server with a sensible moderation should just let loose an account assuming the name of its support account. […]

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Friday, 12-Sep-2025 23:09:16 JST tesaguri 🦀🦝

     in reply to

     • Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     @silverpill […] But of course you cannot blame GitHub in this case, so it has to be handled on the clients' side. Mastodon's GHSA didn't elaborate on this problem because Mastodon mandates WebFinger (which requires control of the `/.well-known` route), but WebFinger is not mandatory in AP, and Misskey was indeed vulnerable to it.

     @evan

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Friday, 12-Sep-2025 23:09:16 JST tesaguri 🦀🦝

     in reply to

     @silverpill Also, I believe the capability of uploading arbitrary documents itself isn't to blame by itself. It's completely common to upload JSON files to e.g. Discord, and it'd be weird if you are allowed to attach a *normal* JSON file, but not one that resembles an AS document. Yes, the best practice is to host user-uploaded contents on a separate domain, but it should be noted that AP is retrofittable to traditional websites like WordPress. For that use-case, it might be over-demanding to retroactively check files under e.g. `/wp-content/`. […]

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Friday, 12-Sep-2025 23:09:16 JST silverpill

     in reply to

     • tesaguri 🦀🦝

     @tesaguri

     >it'd be weird if you are allowed to attach a normal JSON file, but not one that resembles an AS document

     Application only needs to check the id property. If the identifier has local origin, the upload must be rejected.

     If an application can't perform this validation step, then the only solution is to use a separate domain.

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Friday, 12-Sep-2025 23:27:08 JST tesaguri 🦀🦝

     in reply to

     @silverpill That sounds reasonably less intrusive and simple for plain-JSON processors, but I feel like that would be susceptible to the usual problem of different expectations between plain-JSON and JSON-LD consumers

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Friday, 12-Sep-2025 23:27:08 JST silverpill

     in reply to

     • tesaguri 🦀🦝

     @tesaguri Like when object has a property named foo but it is transformed into id (@id?) when JSON-LD magic is applied?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Friday, 12-Sep-2025 23:31:32 JST silverpill

     in reply to

     • tesaguri 🦀🦝

     @tesaguri I actually think checking Content-Type is a good solution. Do you disagree with FEP's recommendations?

     https://codeberg.org/fediverse/fep/src/commit/ff51196ee2331807103f00a6ff85065b67aef79c/fep/fe34/fep-fe34.md#fetching-from-an-origin

     Servers MUST validate all objects received from clients. Any activity representing an action that actor is not authorized to perform MUST be rejected. Special attention needs to be paid to media uploads, because malicious actors might attempt to bypass the validation by uploading ActivityPub documents as media. As an additional protection in cases where an attacker was able to bypass the validation, consumers MUST verify that the response to a GET request contains the Content-Type header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" or application/activity+json media type (see GHSA-jhrq-qvrm-qr36 for more information).

     The blame is on the originating server. But we also have Content-Type verification as an additional protection.

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Friday, 12-Sep-2025 23:31:33 JST tesaguri 🦀🦝

     in reply to

     • infinite love ⴳ

     @silverpill @silverpill […] In the case of WordPress, maybe you can just trust the uploaded contents, but I don't think that can be generalised.

     While the `Content-Type` solution has a hole as @trwnh points out, I thought AS is relatively novel type so that it may be acceptable to impose some additional requirements on those who declare the type (at least it's better than blaming servers like GitHub that haven't even opted to support AP).

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Friday, 12-Sep-2025 23:31:33 JST tesaguri 🦀🦝

     in reply to

     • infinite love ⴳ

     @silverpill That said, it was like my best-effort proposal then that's least controversial and simple enough for multiple servers to implement at once. So I think it's nice to explore alternative solutions, though I don't have any specific idea yet. (6/6)

     @trwnh

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Saturday, 13-Sep-2025 00:15:48 JST silverpill

     in reply to

     • tesaguri 🦀🦝

     @tesaguri

     I feel a bit sorry about losing the possibility of hosting AS feeds on a simple static site for consumption by AP clients

     I don't think we lose it. As long as site administrator doesn't publish untrusted AS documents there, the site will work.

   • Embed this notice
     tesaguri 🦀🦝 (tesaguri@fedibird.com)'s status on Saturday, 13-Sep-2025 00:15:49 JST tesaguri 🦀🦝

     in reply to

     @silverpill No, I'm not particularly against the FEP's recommendations (it's only that I feel a bit sorry about losing the possibility of hosting AS feeds on a simple static site for consumption by AP clients, but I admit that's too much of idealism).

     I don't quite agree as to whom to blame, since I believe some sort of client-side verification is required anyway and server-side checks are only mitigation after all. But I don't think that's essential.

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Saturday, 13-Sep-2025 05:17:38 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • tesaguri 🦀🦝

     @tesaguri @silverpill yeah, I'm not sure this is a problem. I think we actually want to have support for static sites.