Developing a comprehensive ActivityPub security framework based on the concept of web origin.
ActivityPub standard does not specify authentication and authorization mechanisms. However, in some cases it hints at the importance of the web origin:
3. Objects
… Servers SHOULD validate the content they receive to avoid content spoofing attacks. (A server should do something at least as robust as checking that the object appears as received at its origin, but mechanisms such as checking signatures would be better if available).
7.3 Update Activity
… The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.
Implementations often rely on origin and ownership checks for determining the validity of activities and objects, but exact requirements are not documented and can be easily overlooked, leading to vulnerabilities such as GHSA-3fjr-858r-92rw.
This proposal attempts to formalize existing practices and provide guidance for implementers.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.
Object identifiers can be grouped together into protection domains called “origins”. This concept is similar to the “web origin” concept described in RFC-6454, and origins of object IDs are computed by the same algorithm.
The same-origin policy determines when a relationship between objects can be trusted. Different origins are considered potentially hostile and are isolated from each other to varying degrees. Actors sharing an origin are assumed to trust each other because all their interactions are mediated by a single piece of software operated by a single person or an organization.
Origin-based security model is supposed to be used when object identifiers are HTTP(S) URIs and actors are managed by servers. The model can also be used with other kinds of identifiers, but that is not covered in this document.
Servers MUST NOT store invalid objects received from clients. This includes any activities representing actions that actors are not authorized to perform. Special attention needs to be paid to media uploads, because malicious actors might attempt to bypass validation by uploading ActivityPub documents as media (see GHSA-jhrq-qvrm-qr36 for more information).
Servers MUST NOT allow clients to create objects representing public keys (including such objects embedded within actors and other objects).
Servers MUST NOT share secret keys with clients.
Authentication is the process of verifying the origin of an object. It is performed in order to protect an application from spoofing attacks.
ActivityPub object is considered authentic if any of the following conditions are met:
If none of these conditions are met, the object MUST be discarded.
Consumers SHOULD attempt to fetch the object by its ID if other authentication methods are not available.
[!NOTE] In some cases, consumers can process unauthenticated objects if the risk is deemed acceptable.
An object without an ID can only exist when embedded within another object. It is considered authentic when the parent object is authentic.
Authorization is the process of verifying permission to create, read, update or delete an object.
Ownership is indicated by a property of an ActivityPub object. The name of this property differs depending on the object class:
id property.actor property, which describes the actor that performed the activity. This actor is considered to be the owner of the activity.owner and controller properties.attributedTo property, which describes the actor to which the object is attributed. This actor is considered to be the owner of the object.The owner of an object MUST be an actor.
Identifier of an object and identifier of its owner MUST have the same origin.
[!NOTE] This document uses terms such as “actor” and “activity” in accordance with the object classification given in FEP-2277.
[!WARNING] According to Activity Vocabulary,
actorandattributedToproperties can contain references to multiple actors. These scenarios are not covered by this document and implementers are expected to determine the appropriate authorization procedures on a case-by-case basis.
The actor that creates an object MUST be its owner.
If activity modifies or deletes an object, its owner SHOULD match the object’s owner. If owners are different, their IDs MUST have the same origin.
Examples:
Create, Update and Delete activities, and objects indicated by their object property SHOULD have the same owner.Undo activity and object indicated by its object property SHOULD have the same owner.Add and Remove activities, and objects indicated by their target property SHOULD have the same owner.Announce and Like activities don’t modify objects indicated by their object property, therefore their owners can be different.When ownership changes, the new owner ID MUST have the same origin as the old owner ID.
When a protected object is retrieved, the GET request MUST contain a HTTP signature created using a key whose owner MUST belong to object’s intended audience. The same-origin policy is not sufficient in this case because clients might use the proxyUrl endpoint to make requests signed with a key controlled by the server.
In some cases ownership can be implicit. Examples:
Authorization recommendations provided in this document still apply in such cases.
When the same-origin policy can not be used, a trusted relationship between objects can be established with reciprocal claims. Claims are considered reciprocal when one object specifies a claim that is accompanied by a reverse claim specified in another object.
Example:
Relationships between objects with different origins are possible, but they MUST be confirmed with reciprocal claims made by both origins. In that case, the same-origin policy can be bypassed.
Examples:
Move activity if the migrating actor is included in the target actor’s alsoKnownAs.CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.