Tsumiki

コース目次 / 第4章

まとめ — 指示書で、守りを一段

セキュリティヘッダーとCSPを畳みます。既定は厳しく・script-srcはインライン非許可・緩い箇所には理由、を持って、Web診断の次へ進みます。

第4章 / 全5章目安 約3分この章のゴール: ヘッダーとCSPの要点を畳み、診断で他人のCSPを読む視点を持つ

ブラウザへの指示書=セキュリティヘッダーと、その主役 CSP を、このサイトの本物のポリシーで読み解き、XSS を止めるところまで見ました。

セキュリティヘッダー・早見表

ヘッダー 防ぐもの
X-Content-Type-Options: nosniff MIME 推測による誤実行
Referrer-Policy 送り元 URL からの情報漏れ
X-Frame-Options / frame-ancestors クリックジャッキング(埋め込み)
Content-Security-Policy XSS の実行・データ持ち出し(多層防御)

CSP の読みどころ

診断で他人の CSP を読むときの、チェック順です。

1. default-src は何か。‘self’ や ‘none’ なら土台が固い。 なら要注意。
2. script-src に ‘unsafe-inline’ があるか。あれば、CSP の XSS 防御はほぼ無効(注入スクリプトが実行できてしまう)。無ければ、ハッシュ/nonce で狙い撃ちしている良い設計。
3. 緩い箇所に、理由があるか。‘unsafe-inline’ や 、広いホスト許可を見つけたら、「なぜここが緩いのか、正当か」を問う。このサイトの style-src-attr ‘unsafe-inline’ のように、理由付きで範囲が限定されていれば健全。
4. object-src / base-uri / form-action / frame-ancestors が締まっているか。個別の攻撃口が塞がれているか。

一貫する原則、みたび

CSP の芯も、これまでと同じ形でした——既定は最も厳しく(default-src ‘self’)、必要なものだけ明示的に許す(ハッシュで狙い撃ち)。認可の deny-by-default、CORS の許可リスト、そして CSP の ‘self’ 土台。「既定は拒否、例外は理由付きで最小に」——守りの設計は、どの層でもこの一つの姿勢に戻ります。

Web 診断(T3)の、ミニ2本を終えて

これで T3 のミニ、CORS と CSP を通りました。旗艦(sec-web-basics)から始まった Web 診断の主要トピック——注入・認可・オリジン・ヘッダー——が、ひとまず一巡します。

このコースの実習相手は、自分の 127.0.0.1 と、このサイトの公開設定ファイルだけでした(法と倫理)。他人のサイトの CSP を読む(レスポンスヘッダを見る)のは問題ありませんが、緩さを見つけても実際に突くのは自作環境か許可環境だけ。読むと攻めるの間に、いつもの線があります。

お疲れさまでした。あなたはもう、ヘッダー一行の意味を読み、守りを一段足せる人です。

こうなっていればOK

この章で卒業です。

この章はまだ完了していません。