Webセキュリティの実務

ブラウザが Cookie を付けるかどうかは、送り先と Cookie の属性で決まります。要求を起こしたページが誰かは、判定の主役ではありません。自前サーバの実測では、a.test のページから送ったフォームの POST に、b.test の Cookie が付きました。

CORS エラーは「要求が届かなかった」という意味ではありません。単純な要求なら、サーバには届いて処理され、ブラウザはその応答をスクリプトに渡さないだけです。

別オリジンへの要求のうち、事前確認(プリフライト)が付くのは一部だけです。Fetch Standard はその線を「HTML のフォーム要素でできる範囲より込み入った要求」と書いており、事前確認なしで送られるメソッドと Content-Type は、フォームが送れる範囲とほぼ重なります。

SameSite が比べるのは origin ではなく site(scheme + registrable domain)です。`https://a.example.test` と `https://b.example.test` は origin が違っても同じ site なので、手元の実測では3エンジンとも、兄弟から来た POST に `SameSite=Strict` の Cookie が付きました。

このコースの芯は「ブラウザが確かめられるのは『どこから来たか』までで、『本人が望んだか』はサーバが自分で確かめるしかない」です。CSRF の防御はこの境目にあり、サーバは Cookie ではなく、別サイトのページには作れない信号を要求の中から探して照合します。

ブラウザが確かめられるのは「どこから来たか」までです。ページの中で動くスクリプトは、誰が書いたものであれ、そのオリジンから来たものとして扱われます。HTML の定義は、同じオリジンの行為者を `the same authority` を持つものと前提しています。

URL の `#` 以降(フラグメント)は仕様上リクエストに載りません。サーバのログにも、要求を検査する WAF にも現れませんが、ページ内のスクリプトからは読めます。

CSP の仕様は、CSP を注入に対する最初の防御線ではなく、注入が起きたときの被害を減らす多層防御だと自ら書いています。

セッションIDはサーバの表の1行を指す参照です。Cookie を消させても、表の行が残っていれば、同じ値を持つ要求はまだ通ります(自前サーバと curl をブラウザ役にした実測)。

ブラウザが確かめられるのは「どこから来たか」までで、「本人が望んだか」はサーバが自分で確かめるしかありません。OAuth の認可コードフローはこの前提どおりに作られていて、ブラウザを通る経路には短命で1回限りの認可コードだけを載せ、アクセストークンはクライアントと認可サーバの直接の通信で受け渡します。

認可コードはリダイレクトでブラウザを通って運ばれます。ブラウザは、そのコードを受け取った者が要求を始めた当事者かどうかを確かめません。確かめるのはサーバの側で、PKCE ではそれを認可サーバが担います。

ID トークンの署名が正しいことは、本物の発行者が出したことを示すだけで、自分に宛てて出したことは示しません。OpenID Connect Core は、aud に自分の client_id が無いトークンを MUST で拒否させます。