Skip to content

Note

このドキュメントは2026-02-27 03:09にPLaMo Translation Modelを使用して自動翻訳されました。

FEP-fe34: オリジンベースのセキュリティモデル

概要

ActivityPub標準に基づく包括的なセキュリティフレームワークを、ウェブオリジンの概念に基づいて構築する。

背景説明

ActivityPub規格では認証および認可メカニズムが明示的に規定されていない。ただし、特定のケースにおいてオブジェクトの出所（origin）の重要性について示唆している箇所が存在する：

3. オブジェクト

... サーバはコンテンツ偽装攻撃を防止するため、受信したコンテンツの検証を行うべきである（少なくとも、オブジェクトがその発信元で受け取った通りに表示されているかを確認する程度の措置は必要である。可能であれば、署名の検証などのより堅牢なメカニズムを採用することが望ましい）。

7.3 Update Activity

... 受信側サーバは、更新内容が自身のオブジェクトを変更するための権限を有することを確実に確認しなければならない。最低限、これを実現する方法として、更新内容とその対象オブジェクトが同じオリジンに属していることを保証することが挙げられる。

実装においては、アクティビティやオブジェクトの正当性を判断する際にしばしばオリジンと所有権チェックに依存するが、具体的な要件は文書化されておらず、容易に見落とされがちである。このため、GHSA-3fjr-858r-92rwのような脆弱性が生じる可能性がある。

本提案は、既存の慣行を形式化し、実装者向けのガイドラインを提供することを目的としている。

要求事項

本ドキュメント中で使用される「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」の各用語は、RFC-2119で定義された解釈に従うものとする。

前提条件

オリジンベースのセキュリティモデルは、サーバがホストするアクター間のセキュリティ境界を管理するネットワーク環境を想定して設計されている。検証を行わずにオブジェクトを公開するタイプのサーバはサポート対象外である。

オブジェクト識別子についてはHTTP(S) URL形式を想定している。本モデルは他の種類の識別子にも適用可能であるが、これについては本ドキュメントでは扱わない。

オリジン

オブジェクト識別子は「オリジン」と呼ばれる保護ドメインにグループ化される。この概念はRFC-6454で説明されている「ウェブオリジン」と同様のものであり、オブジェクトIDのオリジン計算も同じアルゴリズムによって行われる。

同一オリジンポリシーにより、オブジェクト間の関係性が信頼できるかどうかが判断される。異なるオリジンを持つオブジェクトは基本的に敵対的とみなされ、相互間で様々なレベルで隔離される。同じオリジンを共有するアクターは、すべてのインタラクションが単一のソフトウェアコンポーネント（単一の個人または組織によって運用）を介して行われるため、互いに信頼し合っているものと仮定する。

オリジンの比較

  1. uri-schemeをURIのスキーム部分とし、小文字に変換する
  2. uri-hostをURIのホスト部分とし、小文字に変換する
  3. URIにポート部分が存在しない場合、uri-portはuri-schemeで指定されたプロトコルのデフォルトポートとする。それ以外の場合は、uri-portをURIのポート部分とする
  4. (uri-scheme, uri-host, uri-port)というトリプルを返す

オリジンは、スキーム・ホスト・ポートがすべて同一である場合に一致すると判定される。

認証

認証とは、ActivityPubオブジェクトの出所を検証するプロセスである。これは、アプリケーションが[なりすまし]攻撃から保護されるために行われる。

オブジェクトは以下の方法で認証可能である：

  • オリジンから直接取得する方法
  • 署名の検証を行う方法
  • 埋め込みによる認証方法

もしオブジェクトを認証できない場合、当該オブジェクトは破棄されなければならない。

オリジンから直接取得する方法は主要な認証手段であり、本ドキュメントで説明する他の認証方法もこの方式に依存する。他の認証方法が利用できない場合、消費者はそのオブジェクトを可能な限りオリジンから取得するよう試みるべきである。

オリジンから直接取得する方法

匿名でないActivityPubオブジェクトは、対象オブジェクトIDを指定してHTTP GETリクエストを行うことで認証可能である。

リダイレクトチェーンにおける最終URIが当該オブジェクトの所在地となる。この所在地は取得したオブジェクトIDと一致している必要がある。オブジェクトの所在地とIDが異なる場合、それらは必ず同一のオリジンに属していなければならない。

オブジェクトが保護されている場合、サーバは［HTTP署名］HttpSigを要求することができる。

サーバはすべてのクライアントから受信したオブジェクトを検証しなければならない。アクターがその権限を持たない［操作］を表すアクティビティは、必ず拒否されなければならない。特にメディアアップロードには注意を要する。悪意のあるアクターが、ActivityPubドキュメントをメディアとしてアップロードすることで検証を回避しようとする可能性があるからである。サーバが任意のファイルをクライアントにアップロードさせる場合、メディアは別のオリジン（例えば異なるサブドメイン）から提供されなければならない［詳細はGHSA-jhrq-qvrm-qr36を参照］。

追加的な保護策として、攻撃者が検証プロセスを突破した場合でも、消費者はGETリクエストに対する応答にContent-Typeヘッダーが含まれており、かつその値がapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"またはapplication/activity+jsonメディアタイプであることを確認しなければならない［詳細についてはGHSA-jhrq-qvrm-qr36を参照］。

サーバは検証が完了するまでオブジェクトを提供してはならない。

署名

署名ベースの認証は以下の場合に使用可能である：

  • オブジェクトが受信トレイに届き、HTTPリクエストに有効な［HTTP署名］HttpSigが含まれている場合
  • オブジェクトに有効な［FEP-8b32］完全性証明が含まれている場合

公開鍵ID（または検証方法）は、そのオブジェクトIDと同じオリジンに属している必要がある。

サーバはクライアントと秘密鍵を共有してはならない。

サーバは、公開鍵を表すオブジェクトや、アクター内やその他のオブジェクトに埋め込まれたそのようなオブジェクトの作成・更新をクライアントに許可してはならない。公開鍵は「publicKeyPem」および「publicKeyMultibase」というプロパティによって識別可能である。異なるオリジンを持つ埋め込み公開鍵も許容される。

キー漏洩や検証不足が発生した場合の被害を最小限に抑えるため、消費者は署名用キーが［所有者］[#ownership]として同じ属性を持つオブジェクトであることを必ず確認しなければならない。また、［相互請求］[#reciprocal-claims]を検証することでキーの所有権を確認する必要もある。

[!WARNING] JSON-LDを利用するアプリケーションは、publicKeyPemおよびpublicKeyMultibaseプロパティを持たない特殊なJSONオブジェクトを公開鍵として処理してしまう可能性がある。このような攻撃に対する防御策については本ドキュメントでは扱わない。

埋め込み

特定のケースにおいて、包含するオブジェクトが異なるオリジンを持つ場合でも、その関係性は［相互請求］によって確認されていれば可能となる。この場合、同一オリジンポリシーを回避することができる。

例：

  • アクター文書から参照されているキーであれば、異なるオリジンのキーでアクティビティに署名することが可能である
  • 当該オブジェクトが属するコンテキストのモデレータとして指定されている別のオリジンのアクターであれば、そのアクターによるオブジェクト削除が可能である
  • 移行元サーバのalsoKnownAsフィールドに対象アクターが含まれている場合、［Move］アクティビティを実行することでアクターは一つのサーバから別のサーバへ移行することが可能である

参考文献

著作権

CC0 1.0 Universal（CC0 1.0）パブリックドメイン献呈

法律で許容される範囲において、本Fediverse Enhancement Proposalの著者らは、当該作品に関するすべての著作権および関連する権利を放棄している。