玄関の鍵をかけても「泥棒が宅配業者に化けていたら」？―SRIで守るWebの裏側
こんにちは！セキュリティの世界へようこそ。
日々、アプリケーションの脆弱性と戦っている皆さんは、きっと「XSS（クロスサイトスクリプティング）」という言葉を一度は耳にしたことがあるはずです。
「うちはちゃんとフォームの入力をチェックしているから大丈夫！」
そう思っているあなた。実は、「あなたが信頼している外部の誰か」が、知らない間に裏切っているかもしれないとしたら、どうしますか？
今日は、Webサイトの「外部依存」という盲点を突く攻撃と、それを物理的な防犯に例えて解決する「SRI（Subresource Integrity）」という強力な武器についてお話しします。
—
1. XSSの「想定外」の侵入経路
XSSは、攻撃者が悪意のあるスクリプトをあなたのサイトに忍び込ませ、ユーザーのブラウザ上で実行させる攻撃です。
- 反射型・格納型・DOM型：これらは主に「入力されたデータ」を疑う手法です。
- 今回の盲点：でも、もし「信頼できるCDN（コンテンツデリバリーネットワーク）」から読み込んでいるライブラリそのものが改ざんされていたら？
例えば、jQueryやReactといった有名なライブラリをCDNから読み込んでいるとします。もしそのCDNサーバーがハッキングされ、ライブラリの末尾に「こっそりパスワードを盗むコード」が追記されたらどうなるでしょうか。
これは、「信頼していたはずの宅配業者が、実は泥棒だった」というケースです。あなたのサイトのセキュリティ対策がどれほど完璧でも、ブラウザは「CDNから来たものだから安全だろう」と信じて実行してしまいます。
—
2. SRI（Subresource Integrity）で「本人確認」をする
この脅威を防ぐのがSRI（サブリソース完全性）です。
SRIは、読み込むファイルに「指紋（ハッシュ値）」を持たせる仕組みです。
泥棒を防ぐ「封印」の考え方
手紙に蝋（ろう）で封印をするのを想像してください。もし誰かが途中で手紙を開封して中身を書き換えたら、その封印は壊れてしまいますよね。
SRIも全く同じです。
1. ファイルの「指紋（ハッシュ値）」を計算する。
2. その指紋をHTMLタグの中に書き込んでおく。
3. ブラウザは、ダウンロードしたファイルが「その指紋と一致するか」を確認する。
もし、ハッカーがCDNのファイルを1文字でも書き換えたら、指紋が一致しなくなります。その瞬間、ブラウザは「中身が変わっている！危険だ！」と判断して、そのスクリプトの実行を即座に停止します。
—
3. 実装のステップ：SRIを導入してみよう
では、具体的にどう書くのか見てみましょう。
どうやって指紋を作るの？
手動で計算するのは大変なので、CI/CDパイプライン（開発から公開までの自動化ツール）に任せましょう。最近のビルドツールや、以下のようなコマンドで簡単に生成できます。
OpenSSLを使ってファイルのハッシュ値を生成する例
cat library.js | openssl dgst -sha384 -binary | openssl base64 -A
出力された文字列を、HTMLの integrity 属性にコピーするだけです！
—
4. 現場のプロからのアドバイス：運用上の注意点
SRIは非常に強力ですが、一つだけ注意が必要です。「ファイルの更新」です。
CDN上のライブラリを新しいバージョンに上げたら、当然ながらファイルの指紋（ハッシュ値）も変わります。古い指紋のまま新しいファイルを読み込もうとすると、ブラウザは「改ざんされた！」と勘違いして、サイトの機能が動かなくなってしまいます。
- 自動化が鍵：CI/CDパイプラインの中に「ライブラリのバージョンを上げた時に、自動的にHTMLのSRIハッシュを書き換える」仕組みを組み込んでおきましょう。
- クロスドメインの意識：
crossorigin="anonymous"を忘れがちですが、これがないとブラウザが指紋をチェックしてくれません。セットで覚えましょう。
—
まとめ：あなたのサイトの「防犯」を一歩進めよう
セキュリティ対策は、一度やって終わりではありません。
「入力フォームをチェックする」という玄関の鍵をかけるだけでなく、「中身がすり替わっていないか確認する」という二重のチェックを取り入れること。これが、信頼されるWebサイトを作るための「プロの作法」です。
今日からあなたのサイトでも、CDNから読み込んでいる外部ライブラリに integrity 属性が設定されているか、ぜひ確認してみてください。
もし何か分からないことがあれば、またいつでも聞きに来てくださいね。一歩ずつ、安全な開発者を目指していきましょう！
コメント