4. セキュリティ考慮事項

新しい well-known URI を mint するアプリケーションと, それらをデプロイする管理者は, 機密データの露出, サービス拒否攻撃 (通常の負荷問題に加えて), サーバおよびクライアントの認証, DNS リバインディング攻撃への脆弱性, サーバへの限定的アクセスが well-known URI の提供方法に影響を与える攻撃など, いくつかのセキュリティ関連事項を考慮する必要がある (これらに限定されない).

[RFC3552] には, アプリケーションプロトコルおよびデプロイする管理者に関連しうるセキュリティ考慮事項の例が含まれる.

4.1. Well-Known リソースの保護

Well-known 場所は実質的にオリジン全体を表すため, サーバ運用者はそれらへの書き込み能力を適切に管理すべきである. 複数のエンティティが同一オリジンに共存する場合は特にそうである. 単一エンティティが管理し代表するオリジンであっても, サーバ設定を通じて外部から, または実装上の権限 (ファイルシステムなど) を通じてローカルから, well-known 場所への書き込みアクセスが不用意に付与されないよう十分注意すべきである.

4.2. Web ブラウジングとの相互作用

http または https URL に well-known URI を使うアプリケーションは, well-known リソースが Web ブラウザからアクセス可能であり, したがってそのオリジンの他の部分から得たコンテンツによって操作されうることを認識する必要がある. 攻撃者がコンテンツを注入できる場合 (例: クロスサイトスクリプティングの脆弱性), well-known リソースに対して潜在的に任意のリクエストを行える可能性がある.

HTTP と HTTPS は, cookie [RFC6265], Web Storage [WEBSTORAGE], 各種機能など, 多くの他のメカニズムでもオリジンをセキュリティ境界として使う.

Well-known 場所を定義するアプリケーションは, これらのメカニズムへの独占的アクセスや, オリジンを使う唯一のアプリケーションであると仮定すべきではない. アプリケーションの性質に応じた緩和策には次が含まれうる.

機密情報の暗号化
識別子 (cookie 名など) の使用に柔軟性を持たせ, 他アプリケーションとの衝突を避ける
cookie に HttpOnly フラグを使い, ブラウザのスクリプト言語に cookie が露出しないようにする [RFC6265]
cookie に Path パラメータを使い, オリジンの他の部分で利用できないようにする [RFC6265]
X-Content-Type-Options: nosniff [FETCH] を使い, 攻撃者制御下のコンテンツが Web ブラウザによってアクティブコンテンツとして解釈される形に誘導されないようにする

その他の良い慣行:

Content-Type ヘッダフィールドにアプリケーション固有のメディアタイプを使い, 使用されていない場合はクライアントに失敗を要求する
Content-Security-Policy [CSP] を使い, アクティブコンテンツ (HTML [HTML5] など) の能力を制約し, クロスサイトスクリプティング攻撃を緩和する
Referrer-Policy [REFERRER-POLICY] を使い, URL 内の機密データが Referer リクエストヘッダフィールドに漏えいしないようにする
機密情報 (認証トークン, パスワードなど) への圧縮の使用を避ける. Web ブラウザのスクリプト環境では攻撃者が圧縮空間を繰り返し探査でき, 通信経路へのアクセスがあればその能力で情報を復元しうる.

4.3. アプリケーションのスコープ設定

本メモは, well-known URI から得た情報の適用範囲も, 特定アプリケーションの well-known URI の発見方法も規定しない.

本メカニズムを使う各アプリケーションは両方を定義しなければならない. 指定がないと, 実装のばらつきやアプリケーション間の境界に関する混乱からセキュリティ上の問題が生じうる.

Well-known URI で発見したメタデータを, 同一オリジンに共存しないリソースに適用することは, 管理上およびセキュリティ上のリスクがある. 例えば https://example.com/.well-known/example が https://department.example.com, https://www.example.com, あるいは https://www.example.com:8000 にポリシーを適用することを許すと, ホスト間に存在しないかもしれない関係を仮定し, 潜在的攻撃者に制御を与える.

同様に, 特定のホスト名上の well-known URI をプロトコルのブートストラップに使うと, 望ましくない大量のリクエストを引き起こしうる. 例えば, メールなど別サービスに関するポリシーを見つけるために well-known HTTPS URI を使うと, well-known URI を実装していない Web サーバにもリクエストの洪水が及ぶことがある. そのような望ましくないリクエストはサービス拒否攻撃に似うる.

4.4. 隠れた機能

Well-known 場所を使うアプリケーションは, 一部のサーバ管理者がその存在に気づいていない可能性 (特に . で始まるディレクトリ名を隠す OS では) を考慮すべきである. つまり攻撃者が .well-known ディレクトリへの書き込みアクセスを持つと, 管理者が気づかないうちにその内容を制御できる可能性がある.