要約

  • RFC 10025 の Cookie は、ユーザーエージェントが条件に従って保存・返送できる状態である。値の業務上の意味とセッションの受理はアプリケーションが決める。
  • Secure、HttpOnly、SameSite、Domain、パス、名前接頭辞はそれぞれ異なる境界を狭める。現在の意思、操作権限、完了結果を一つで保証するものではない。
  • 重要な操作では、発行と失効、要求の文脈、個別の許可、鮮度・再送、コミット、観測された結果を別々に結び、Cookie を一括した結論にしない。

障害対応の担当者が見るのは、しばしば「セッションあり」という簡潔な表示である。しかし、それは調査の開始点にはなっても、終了点にはならない。たとえば管理者追加の要求に Cookie が付いていたとしても、その Cookie を持つセッションが直前のアカウント回復後も有効だったか、その画面に正しい確認経路があったか、追加対象と権限範囲が許容されていたか、後段の台帳が実際に更新されたかは別の事実である。

RFC 10025 の価値は、この差を曖昧にしないことにある。Set-Cookie と Cookie、保存、選択、返送を規定する一方、cookie-value の意味はアプリケーションに委ねる。その文字列がサーバー側セッション、設定、カート、既に無効になった参照のどれを指すかは RFC が決めない。したがって「ブラウザが返した」から「人が許可した」までの飛躍には、別の証拠が必要になる。

ブラウザが見ている境界

Cookie には名前と値に加え、有効期限、ドメイン、パス、host-only、secure-only、HTTP-only、same-site といった属性がある。ユーザーエージェントは受信を無視でき、保存後も自身の方針で削除できる。サーバーが発行した値を永久に保管する証明書として扱うことはできない。

Domain を省略すれば host-only になり、認められた Domain は対応する範囲に選択を広げる。Public Suffix の扱いは過度に広い設定を抑える助けになる。しかしこれは返送先の選択に関する規則であり、同じ範囲のすべてのホストが同じ業務権限を持つという意味ではない。パスも同様に選択の補助であり、認可の壁ではない。同名の値や想定外の組合せをサーバーがどう処理するかは、明示的な受理規則として持つ必要がある。

Secure はユーザーエージェントの安全な接続という概念に返送を限定する。HttpOnly は非 HTTP API からのアクセスを制限する。どちらも重要だが、前者はセッションの現時点の有効性を判定せず、後者も該当する HTTP 要求にブラウザが Cookie を添付することを止めない。読み出せないことと、自動送信されないことは違う。

そこで RFC の ambient authority という表現が重要になる。誰かがブラウザを特定の資源へ向ければ、すでに保持された資格情報的な状態が同伴しうる。危険は文字列の窃取だけではない。アプリケーションが同伴を本人の現在の決裁と取り違えることにもある。

SameSite は経路を減らすが、意思を署名しない

Strict と Lax は、一定のクロスサイト場面での返送を制限する。採用すべき制限である一方、RFC 10025 は Lax を特定の CSRF に対する多層防御と位置付け、一般的で堅牢な CSRF 防御とは呼ばない。既定 Cookie の互換挙動には、最近設定された Cookie がトップレベルの安全でないメソッドのナビゲーションに送られ得る余地もある。

このため、設計レビューで聞くべきなのは「SameSite はあるか」ではない。「この操作に、セッションとは別にどの文脈証拠が必要か」である。回復先メールの変更なら、画面と結び付いた防止トークン、適切な Origin の確認、最近の再認証、従来の連絡先への通知が必要かもしれない。送金やネットワーク設定なら、限度額、二者承認、保留時間、別系統の確認が必要になることがある。これは属性の穴埋めではなく、結果の所有者が決める統制である。

__Secure- と __Host- は有用な発行側の境界を与える。後者は安全な由来、Secure、Path=/、Domain 不在を要求する。だが接頭辞はセッション失効台帳を照会せず、役割変更を知覚せず、取引を承認しない。そこに期待しないことが、接頭辞を正しく強く使う条件になる。

セッション、許可、結果を切り分ける

サーバーは Cookie を解析した後、その参照先セッションを今受け入れるか決める。期限、明示的な無効化、パスワード変更後の回転、回復中の制限、リスク評価はブラウザ保存とは独立する。セッション固定への対策も、既存の識別子を権限上昇後に回転し、旧値を拒否することであり、ヘッダーから価値を読み直すことではない。

次に操作ごとの認可がある。残高の閲覧を許すセッションが、管理者追加や支払先変更を許すとは限らない。対象、役割、委任、限度、確認、時間条件を評価しなければならない。HTTP の安全性や冪等性の語はプロトコル上の振る舞いを表すのであって、業務上の意思や権限を認証する語ではない。

最後にコミットと結果を分ける。200 はジョブ投入、内部書込み、処理開始のどれかを意味し得る。端末設定、送金、通知、外部記録が完了したことの証明にはならない。重要な操作には、一意な要求参照、下流参照、観測結果、必要なら補正手順が必要である。

出典