Added new requirements to FEP-fe34:
-
Added new requirements to FEP-fe34:
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-Typeincludes 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).
-
Added new requirements to FEP-fe34:
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-Typeincludes 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).
I'll have to give this a full read later, but I think this would be a good candidate for the newly formed ActivityPub API taskforce (it's still being fully setup, but Evan and myself are the co-leads on it)
-
Thanks, I would be happy to discuss it.
What do you mean by a good candidate for the taskforce, though? I am not affiliated with the Social CG.
-
Added new requirements to FEP-fe34:
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-Typeincludes 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).
@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-Typeheader. However, I think we should blame the servers that failed to validate uploaded documents, because it is their actors get impersonated. -
@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-Typeheader. However, I think we should blame the servers that failed to validate uploaded documents, because it is their actors get impersonated.@silverpill @tesaguri checking content-type doesn't actually solve the issue either, because a web server may be configured to serve the "correct" type for user uploaded documents. the real mistake is
> FetchRemoteStatusService#trustworthy_attribution? trusts the attributedTo property of a fetched object as long as the domain of the attributed actor is the same as the original request URI.
attribution is only trustworthy within a trust framework that allows entities to validate existing claims
-
@silverpill @tesaguri checking content-type doesn't actually solve the issue either, because a web server may be configured to serve the "correct" type for user uploaded documents. the real mistake is
> FetchRemoteStatusService#trustworthy_attribution? trusts the attributedTo property of a fetched object as long as the domain of the attributed actor is the same as the original request URI.
attribution is only trustworthy within a trust framework that allows entities to validate existing claims
@silverpill @tesaguri i.e. if org.example/~alice/foo claims to be attributed to org.example/~bob, we don't know a priori if this is true or false. ~bob needs to be able to make a claim for ~alice/foo as well.
ironically, mastodon came up with a relatively more sound solution for fediverse:creator than it uses for attributedTo. their attributionDomains property at least establishes trust for a domain explicitly. (it would be nice to have more granularity though! maybe attributionPrefixes?)
-
@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-Typeheader. However, I think we should blame the servers that failed to validate uploaded documents, because it is their actors get impersonated.@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.
-
@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.
@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. […]
-
@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. […]
@tesaguri @silverpill yeah, I'm not sure this is a problem. I think we actually want to have support for static sites.
