Post AxufTJQikmdWBnduLI by silverpill@mitra.social
(DIR) More posts by silverpill@mitra.social
(DIR) Post #AxufTJQikmdWBnduLI by silverpill@mitra.social
2025-09-06T00:44:38.209738Z
1 likes, 0 repeats
Added new requirements to FEP-ef34:https://codeberg.org/fediverse/fep/pulls/672Previously 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
(DIR) Post #Ay4Er90wNOTPeaK5AW by poopdotnet@blog.poop.net
2025-09-10T15:34:04.905216Z
0 likes, 0 repeats
@silverpill help my data folder fills up and never gets emptied my retention config is the version in the example uncommented but it never empties help
(DIR) Post #Ay77C0TR6lE55Wy5oG by silverpill@mitra.social
2025-09-12T00:51:50.495674Z
0 likes, 0 repeats
@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.
(DIR) Post #Ay8GJLUCTbr51srN1E by tesaguri@fedibird.com
2025-09-12T13:46:09Z
0 likes, 0 repeats
@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.
(DIR) Post #Ay8GJMkBneEsvlLea0 by tesaguri@fedibird.com
2025-09-12T13:46:25Z
0 likes, 0 repeats
@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. […]
(DIR) Post #Ay8GJNFNvfC0UVwZCi by tesaguri@fedibird.com
2025-09-12T13:46:45Z
0 likes, 0 repeats
@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
(DIR) Post #Ay8GJNvvNVDicRqXVg by tesaguri@fedibird.com
2025-09-12T13:46:56Z
0 likes, 0 repeats
@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/`. […]
(DIR) Post #Ay8GJThFwx3IUh1uTo by tesaguri@fedibird.com
2025-09-12T13:47:13Z
0 likes, 0 repeats
@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).
(DIR) Post #Ay8GJabUGnb3upNtxY by tesaguri@fedibird.com
2025-09-12T13:48:07Z
0 likes, 0 repeats
@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
(DIR) Post #Ay8HGPMhhJks95W5kO by silverpill@mitra.social
2025-09-12T14:19:20.406314Z
0 likes, 0 repeats
@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-originServers 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.
(DIR) Post #Ay8MFE5MeJhIdxf6US by tesaguri@fedibird.com
2025-09-12T14:33:29Z
0 likes, 0 repeats
@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.
(DIR) Post #Ay8MFFUZQ5SD0QSkPw by silverpill@mitra.social
2025-09-12T15:15:04.099520Z
0 likes, 0 repeats
@tesaguriI feel a bit sorry about losing the possibility of hosting AS feeds on a simple static site for consumption by AP clientsI don't think we lose it. As long as site administrator doesn't publish untrusted AS documents there, the site will work.