【入門編】CSP Level 3のstrict-dynamicによる動的スクリプトの管理 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは。セキュリティの世界へようこそ。

「Webサイトのセキュリティ」と聞くと、なんだか難しそうな要塞を築くようなイメージを持つかもしれませんね。でも、実は私たちの身の回りの「家の防犯」と全く同じ考え方で紐解くことができます。

今日は、現代のWeb開発で避けては通れない「インジェクション攻撃」の防波堤、そしてその中でも少し上級者向けとされる「CSP（Content Security Policy）の『strict-dynamic』」という強力な魔法について、一緒に学んでいきましょう。

—

まずは「インジェクション攻撃」を、皆さんの家の「郵便受け」に例えてみましょう。

本来、郵便受けは「手紙」を入れるための場所ですよね。でも、もし悪意のある誰かが、手紙の代わりに「家の中の鍵を開けるための魔法の呪文」を書き込んだ紙を投げ入れたらどうなるでしょう？

Webの世界でいう「インジェクション攻撃」はこれと同じです。ユーザーが入力するフォームなどに、ただの文字ではなく、「プログラムを動かすための命令（＝悪意あるコード）」を紛れ込ませて、勝手にサイトを操作させようとする攻撃のことです。

これが成功すると、あなたのサイトが泥棒の入り口にされてしまいます。

—

この泥棒を防ぐための強力な仕組みが「CSP（Content Security Policy）」です。これは、ブラウザに対して「このサイトでは、どこの誰が書いたプログラムなら実行していいよ」と指示を出すための「警備員」のようなもの。

ところが、最近のWebアプリは複雑です。メインのプログラムが、さらに別の小さなプログラムを次々と呼び出す……という「孫請け」のような構造が当たり前になっています。

ここで登場するのが、今回の主役『strict-dynamic』です。

従来のCSP設定だと、「このスクリプトはOK」と個別に許可を出さなければなりませんでした。しかし、プログラムが動的に読み込まれるたびにいちいち許可証を出すのは、現場のエンジニアにとって悪夢のような手間です。

そこで『strict-dynamic』は、こう言います。
「信頼できる親分（メインスクリプト）が許可した子分（動的スクリプト）なら、すべて実行を許可する！」

これにより、セキュリティを維持しながら、複雑なWebアプリもスムーズに動かせるようになるのです。

—

では、実際にどのように設定するのかを見てみましょう。Webサーバーから送るHTTPヘッダーに、以下のような設定を追加します。

CSPヘッダーの例
Content-Security-Policy: script-src ‘nonce-random123’ ‘strict-dynamic’; object-src ‘none’; base-uri ‘none’;

'nonce-random123': これは「合言葉」です。サーバー側でリクエストのたびに発行する使い捨てのパスワードのようなもので、この合言葉を持っているスクリプトだけが「親分」として認められます。
'strict-dynamic': これが魔法です。「合言葉を持つ親分が信頼した相手なら、その子分も通していいよ」というルールを有効にします。
object-src 'none': 泥棒が好む「プラグイン（Flashなど）」の読み込みを禁止します。
base-uri 'none': 攻撃者が勝手にリンク先を書き換えるのを防ぎます。

このように設定することで、攻撃者が外部から怪しいスクリプトを差し込もうとしても、合言葉（nonce）を持っていないため、警備員（ブラウザ）によって即座にブロックされるわけです。

—

ここまで読んで、「なんだか難しそうだな……」と感じた方もいるかもしれません。でも、安心してください。

最初から完璧なCSPを書こうとする必要はありません。まずは「レポート専用のCSP（Content-Security-Policy-Report-Only）」を使って、「今の設定だと、どのスクリプトがブロックされるかな？」と観察することから始めるのが、プロの現場での定石です。

セキュリティ対策は、一度やって終わりではありません。皆さんが書いたコードが、ユーザーにとっての「安全な家」であり続けるよう、少しずつ、丁寧に守りを固めていきましょう。

分からないことがあれば、いつでもまた聞きに来てくださいね。一歩ずつ、着実に強くなっていきましょう！