FEP-fe34 (Origin-based security model) update : https://codeberg.org/fediverse/fep/pulls/849
-
FEP-fe34 (Origin-based security model) update : https://codeberg.org/fediverse/fep/pulls/849
I tried to better explain the assumptions on which the model is based, and clarified how exactly origins should enforce boundaries between actors:
Servers MUST ensure that activities published by a client do not represent unauthorized actions. This includes activities embedded within other activities and objects.
Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Lemmy API and Mastodon API implementers don't have to worry about this, but one needs to be very careful when accepting arbitrary payloads from clients, for example, when implementing ActivityPub C2S API or FEP-ae97 API. Unfortunately, these security issues are completely ignored by people who push for wide deployment of ActivityPub C2S API.
Another addition is the recommendation to not use partially embedded objects, because that might lead to cache poisoning:
Embedded non-anonymous objects SHOULD NOT be partial representations. A server that relies on embedding for authentication might save a partial representation of an object to the cache, replacing the full object.
(see this issue for details: https://codeberg.org/silverpill/feps/issues/21)
-
? Guest crossposted this topic to General Discussion
-
FEP-fe34 (Origin-based security model) update : https://codeberg.org/fediverse/fep/pulls/849
I tried to better explain the assumptions on which the model is based, and clarified how exactly origins should enforce boundaries between actors:
Servers MUST ensure that activities published by a client do not represent unauthorized actions. This includes activities embedded within other activities and objects.
Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Lemmy API and Mastodon API implementers don't have to worry about this, but one needs to be very careful when accepting arbitrary payloads from clients, for example, when implementing ActivityPub C2S API or FEP-ae97 API. Unfortunately, these security issues are completely ignored by people who push for wide deployment of ActivityPub C2S API.
Another addition is the recommendation to not use partially embedded objects, because that might lead to cache poisoning:
Embedded non-anonymous objects SHOULD NOT be partial representations. A server that relies on embedding for authentication might save a partial representation of an object to the cache, replacing the full object.
(see this issue for details: https://codeberg.org/silverpill/feps/issues/21)
@phnt Following on one of our conversations, I now call out authorized fetch as ineffective when it is used on public objects:
Some servers require an HTTP signature in an attempt to limit access to public objects. In this scenario, the request is expected to be signed with a key that is owned by a server actor. However, this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.
-
FEP-fe34 (Origin-based security model) update : https://codeberg.org/fediverse/fep/pulls/849
I tried to better explain the assumptions on which the model is based, and clarified how exactly origins should enforce boundaries between actors:
Servers MUST ensure that activities published by a client do not represent unauthorized actions. This includes activities embedded within other activities and objects.
Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Lemmy API and Mastodon API implementers don't have to worry about this, but one needs to be very careful when accepting arbitrary payloads from clients, for example, when implementing ActivityPub C2S API or FEP-ae97 API. Unfortunately, these security issues are completely ignored by people who push for wide deployment of ActivityPub C2S API.
Another addition is the recommendation to not use partially embedded objects, because that might lead to cache poisoning:
Embedded non-anonymous objects SHOULD NOT be partial representations. A server that relies on embedding for authentication might save a partial representation of an object to the cache, replacing the full object.
(see this issue for details: https://codeberg.org/silverpill/feps/issues/21)
I don't think this makes sense: "Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor."
We've never had this requirement; it's not built into ActivityPub; it's not how federation work.
- Like
- Announce
- inReplyTo
- Follow
- Accept
- RejectI think two way verification is a better mechanism than same-origin. So, check that the `object` of a `Create` has the same `attributedTo` as the `actor`.
-
@phnt Following on one of our conversations, I now call out authorized fetch as ineffective when it is used on public objects:
Some servers require an HTTP signature in an attempt to limit access to public objects. In this scenario, the request is expected to be signed with a key that is owned by a server actor. However, this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.
@silverpill
>this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.
I never thought about it like that, but that too is a way to circumvent it. Although you would still need some way to publish that key and a valid Actor for verification, a server. If a remote server implementing restrictions on fetching based on signatures only disallows the instance Actor, then that is a way to bypass that restriction. Although I think there currently is no implementation that does that. Mastodon instead blocks everything on the domain including all subdomains and GTS probably does the same. No idea how the Misskey forks and Iceshrimp.NET do it though. Of course using different domains works as well.
>Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Unrelated to the this FEP, but this came up when fixing the recent Pleroma security issues. There is no agreed upon way of federating moderation decisions to remote instances. It is logical when validating remote Update Activities to only allow Activities that update Objects owned by the same Actor, however that is never guaranteed when for example an admin on a remote instance forces a post to be NSFW. Similarly Delete Activities can have the Actor be the moderator, but Object actually owned by user. -
I don't think this makes sense: "Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor."
We've never had this requirement; it's not built into ActivityPub; it's not how federation work.
- Like
- Announce
- inReplyTo
- Follow
- Accept
- RejectI think two way verification is a better mechanism than same-origin. So, check that the `object` of a `Create` has the same `attributedTo` as the `actor`.
@evan This is my mistake, thanks for pointing out. It should be changed to "...where embedded objects are owned by another local actor".
I think
Create.object.attributedTo==Create.actoris a different thing, because it is related to authorization, whereas the requirement we're discussing here is related to authentication.In general, yes, none of this was built into ActivityPub. But over the years implementers figured out authentication and authorization on their own, and now this is how federation works. People expect that same-origin embeddings can be cached as is, without re-fetching.
-
@silverpill
>this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.
I never thought about it like that, but that too is a way to circumvent it. Although you would still need some way to publish that key and a valid Actor for verification, a server. If a remote server implementing restrictions on fetching based on signatures only disallows the instance Actor, then that is a way to bypass that restriction. Although I think there currently is no implementation that does that. Mastodon instead blocks everything on the domain including all subdomains and GTS probably does the same. No idea how the Misskey forks and Iceshrimp.NET do it though. Of course using different domains works as well.
>Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Unrelated to the this FEP, but this came up when fixing the recent Pleroma security issues. There is no agreed upon way of federating moderation decisions to remote instances. It is logical when validating remote Update Activities to only allow Activities that update Objects owned by the same Actor, however that is never guaranteed when for example an admin on a remote instance forces a post to be NSFW. Similarly Delete Activities can have the Actor be the moderator, but Object actually owned by user.@phnt Yesterday, a proposal was submitted that offered a solution to this exact problem: https://codeberg.org/fediverse/fep/src/branch/main/fep/baf5/fep-baf5.md. I don't like some parts of it (see discussion), but it's a step in the right direction
-
@phnt Yesterday, a proposal was submitted that offered a solution to this exact problem: https://codeberg.org/fediverse/fep/src/branch/main/fep/baf5/fep-baf5.md. I don't like some parts of it (see discussion), but it's a step in the right direction
@silverpill I don't have issues with it besides attributedTo usage being a classic case of trying to fit Activity Vocabulary into things that shouldn't use it. It solves the part one of a draft I wanted to write. Part two being something simple as "hidden: true" in Update Activities (or HiddenUpdate Activity) to hide moderation changes from status history on remote servers. -
@silverpill
>this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.
I never thought about it like that, but that too is a way to circumvent it. Although you would still need some way to publish that key and a valid Actor for verification, a server. If a remote server implementing restrictions on fetching based on signatures only disallows the instance Actor, then that is a way to bypass that restriction. Although I think there currently is no implementation that does that. Mastodon instead blocks everything on the domain including all subdomains and GTS probably does the same. No idea how the Misskey forks and Iceshrimp.NET do it though. Of course using different domains works as well.
>Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Unrelated to the this FEP, but this came up when fixing the recent Pleroma security issues. There is no agreed upon way of federating moderation decisions to remote instances. It is logical when validating remote Update Activities to only allow Activities that update Objects owned by the same Actor, however that is never guaranteed when for example an admin on a remote instance forces a post to be NSFW. Similarly Delete Activities can have the Actor be the moderator, but Object actually owned by user.>Although you would still need some way to publish that key and a valid Actor for verification, a server.
I just realized that it could be effective in island networks, where domains are allowlisted.
-
@evan This is my mistake, thanks for pointing out. It should be changed to "...where embedded objects are owned by another local actor".
I think
Create.object.attributedTo==Create.actoris a different thing, because it is related to authorization, whereas the requirement we're discussing here is related to authentication.In general, yes, none of this was built into ActivityPub. But over the years implementers figured out authentication and authorization on their own, and now this is how federation works. People expect that same-origin embeddings can be cached as is, without re-fetching.
@silverpill @general so this is for **embedded** objects? That totally makes sense.
-
>Although you would still need some way to publish that key and a valid Actor for verification, a server.
I just realized that it could be effective in island networks, where domains are allowlisted.
@silverpill It is also effective for nomadic actors. When you switch to a mindset where there are lots of users on a small number of relays, like is the case with Nostr, blocking by domain stops being effective. You could spin up new users that the relay will publish and circumvent it that way. Provided that the relay isn't the one that would normally sign the Activities/fetches, which I don't think is the case (haven't looked into nomad implementations though).
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login