キャッシュ汚染とは？

キャッシュ汚染（キャッシュポイズニング、Cache Poisoning）とは、WebサイトやDNS（ドメインネームシステム）のキャッシュ機能を悪用し、偽の情報を保存させることで、多数の利用者を攻撃者が用意した偽サイトや悪意のあるコンテンツへ誘導するサイバー攻撃です。Webキャッシュポイズニング、DNSキャッシュポイズニング（DNSスプーフィング）などの種類があります。

キャッシュとは、一度アクセスしたWebページやDNS情報を一時的に保存しておく仕組みです。次回同じ情報が必要になったとき、最初から取得し直すのではなく、保存されたキャッシュを使うことで、表示速度を上げたり、サーバーの負担を減らしたりできます。しかし、この便利な仕組みを攻撃者が悪用すると、キャッシュに保存された情報を書き換えられてしまい、利用者が正しいサイトにアクセスしているつもりでも、実際には攻撃者が用意した偽サイトへ誘導されてしまいます。

キャッシュ汚染は、大きく分けて「Webキャッシュポイズニング」と「DNSキャッシュポイズニング」の2種類があります。Webキャッシュポイズニングは、CDN（コンテンツ配信ネットワーク）やプロキシサーバーなどのWebキャッシュサーバーを標的にします。一方、DNSキャッシュポイズニングは、ドメイン名をIPアドレスに変換するDNSサーバーのキャッシュを汚染します。どちらも、一度汚染されると、キャッシュが有効な期間中、その情報を参照する全ての利用者が影響を受けるという共通点があります。

キャッシュ汚染を簡単に言うと？

キャッシュ汚染を日常生活で例えるなら、「電話帳に嘘の情報を書き込む」ようなものです。

例えば、あなたが普段利用している銀行の電話番号を電話帳に登録していたとします。ところが、誰かがその電話帳の銀行の番号を、こっそり詐欺グループの電話番号に書き換えてしまったら、どうなるでしょうか。あなたは銀行に電話をかけているつもりでも、実際には詐欺グループにつながってしまい、口座情報やパスワードを聞き出されてしまう危険があります。

キャッシュ汚染も、これと同じ仕組みです。インターネット上の「電話帳」にあたるのが、DNSサーバーやWebキャッシュサーバーです。攻撃者は、この「電話帳」に嘘の情報を書き込み、利用者が正規のWebサイトにアクセスしようとしても、偽サイトに誘導してしまうのです。特に怖いのは、一度「電話帳」が書き換えられると、その情報を信じて使う人全員が被害に遭う可能性があることです。

キャッシュ汚染の現状

キャッシュ汚染は、2008年頃のカミンスキー型攻撃の発見以降、長年にわたって深刻な脅威として認識されてきました。しかし、2024年から2025年にかけて、この攻撃手法は依然として進化を続け、新たな脅威として浮上しています。

2024年10月に開催されたACM SIGSAC Conference on Computer and Communications Securityで発表された大規模調査によると、Tranco Top 1000ドメインとそのサブドメインを評価した結果、172ドメイン（全体の17%）にわたる1,000以上のWebサイトがWebキャッシュポイズニングに脆弱であることが判明しました。この調査では、7つの新しい攻撃ベクトルが発見され、HTTPヘッダーの処理に関する見過ごされていた脆弱性が明らかになりました。

具体的な脆弱性事例として、2025年1月には、人気のWebフレームワークであるNext.jsにおいて、CVE-2024-46982（CVSS 7.5、高）が発見されました。この脆弱性は、バージョン13.5.1から14.2.9のNext.jsを使用するWebサイトで、キャッシュポイズニングと蓄積型クロスサイトスクリプティング（XSS）攻撃が可能となるものでした。攻撃者は特別に細工したHTTPリクエストを送信することで、動的コンテンツをキャッシュさせ、悪意のあるペイロードを他の利用者に配信できてしまいます。この脆弱性は、Eコマース、暗号資産プラットフォーム、金融サービスなど、さまざまな分野のバグバウンティプログラムで悪用が報告されています。

DNSキャッシュポイズニングについては、2025年10月に、BIND 9リゾルバーにおいてCVE-2025-40778（CVSS 8.6、重大）が公開されました。この脆弱性は、BIND 9のバージョン9.11.0から9.21.12までに影響し、世界中で70万6,000以上の公開されたDNSリゾルバーが危険にさらされています。攻撃者は、この脆弱性を悪用して、DNSキャッシュに偽のアドレスレコードを注入し、インターネットトラフィックを悪意のある目的地へリダイレクトできます。

2024年と2025年の脆弱性情報では、CVE-2024-46452（オープンソースのオンラインショップアプリケーションのパスワードリセット機能におけるHostヘッダーインジェクション）、CVE-2024-40686（IBM SmartCloud Analyticsにおけるキャッシュポイズニングとセッションハイジャッキングを可能にするHostヘッダーインジェクション）など、Hostヘッダーインジェクションとキャッシュポイズニングを組み合わせた攻撃が依然として発見されています。

日本国内では、日本レジストリサービス（JPRS）が継続的にDNSキャッシュポイズニング攻撃の増加について注意喚起を行っています。特に、オープンリゾルバー（誰でもDNS問い合わせができる設定になっているDNSサーバー）が日本の一般家庭のWi-Fiルーターなどに多く存在しており、これらが攻撃の踏み台として利用されるケースが報告されています。

最近の手法としては、HTTPリクエストヘッダーの不整合を悪用する攻撃が注目されています。Accept-Encoding、Transfer-Encoding、X-Forwarded-Host、X-Original-URLなど、キャッシュキーに含まれない「非キー入力」（unkeyed inputs）を操作することで、キャッシュサーバーとバックエンドサーバーの間で異なる解釈を引き起こし、悪意のあるレスポンスをキャッシュさせる手法が発見されています。

キャッシュ汚染で発生する被害は？

キャッシュ汚染が成功すると、攻撃者が一度だけ悪意のあるリクエストを送信するだけで、キャッシュが有効な期間中、その情報を参照する全ての利用者が被害を受ける可能性があります。特に、大手WebサイトのホームページやCDN（コンテンツ配信ネットワーク）が汚染されると、数千人から数万人の利用者に影響が及ぶため、被害規模は甚大です。

キャッシュ汚染で発生する直接的被害

• 偽サイトへの誘導とフィッシング被害: DNSキャッシュポイズニングやWebキャッシュポイズニングにより、利用者が正規のWebサイト（オンラインバンキング、ECサイト、暗号資産取引所など）にアクセスしようとしても、見た目が本物そっくりの偽サイトへ誘導されます。そこで入力したログイン情報、クレジットカード番号、個人情報などが攻撃者に盗まれ、不正送金や不正購入などの金銭的被害につながります。2024年のNext.js脆弱性の事例では、攻撃者が蓄積型XSS攻撃を通じて利用者の機密データを抽出することに成功しています。

• マルウェア感染: キャッシュ汚染により、利用者が正規のWebサイトにアクセスしたつもりでも、攻撃者が用意した悪意のあるWebサイトへリダイレクトされ、知らないうちにマルウェア（ウイルス、スパイウェア、ランサムウェアなど）がダウンロード・インストールされてしまいます。マルウェアに感染すると、端末内のファイルが暗号化されて身代金を要求されたり、機密情報が外部に流出したり、端末が乗っ取られてボットネットの一部として利用されたりする危険があります。

• サービス妨害（DoS）: キャッシュポイズニングを利用して、エラーページや存在しないページをキャッシュさせることで、正規の利用者が本来アクセスすべきWebサイトのコンテンツを閲覧できなくなります。これは、サービス妨害攻撃（DoS攻撃）の一種であり、企業のWebサイトが利用できなくなることで、ビジネス機会の損失や顧客満足度の低下につながります。2024年の研究では、HTTPヘッダーサイズを悪用したDoS攻撃の可能性も指摘されています。

キャッシュ汚染で発生する間接的被害

• 企業の信用失墜とブランド毀損: キャッシュ汚染により、企業のWebサイトが攻撃者の支配下に置かれたり、偽サイトに誘導されたりすると、顧客は「このサイトは安全ではない」と感じ、企業への信頼を失います。特に金融機関やEコマースサイトなど、セキュリティが重視される業種では、一度失った信用を回復するのは非常に困難です。また、SNSやニュースでセキュリティ事故が報道されると、ブランドイメージが大きく損なわれ、長期的な顧客離れや株価下落につながる可能性があります。

• 法的責任とコンプライアンス違反: キャッシュ汚染により顧客の個人情報が漏洩したり、金銭的被害が発生したりした場合、企業は法的責任を問われる可能性があります。個人情報保護法やGDPR（EU一般データ保護規則）などの規制により、適切なセキュリティ対策を怠った企業には罰金や制裁が科されることがあります。また、顧客からの損害賠償請求や訴訟に発展する可能性もあり、企業にとって大きな経済的負担となります。

• 企業ネットワークへの侵入の踏み台: キャッシュ汚染は、単独の攻撃で終わらず、より大規模な攻撃の第一段階として利用されることがあります。例えば、従業員が業務中に汚染されたDNSキャッシュを経由して偽サイトにアクセスし、そこでマルウェアに感染すると、攻撃者は従業員の端末を足がかりに企業ネットワーク内部に侵入できます。その後、標的型攻撃（APT）や横展開により、企業の重要なサーバーやデータベースにアクセスされ、機密情報の大量流出やランサムウェア攻撃につながる危険があります。

キャッシュ汚染の対策方法

キャッシュ汚染への対策は、DNSキャッシュポイズニングとWebキャッシュポイズニングのそれぞれに対して、多層的なアプローチが必要です。完全に防ぐことは難しいものの、リスクを大幅に低減できる対策が存在します。

利用者としての対策では、信頼できるDNSサービスの利用が重要です。GoogleパブリックDNS（8.8.8.8）やCloudflareのDNS（1.1.1.1）など、大手事業者が提供するDNSSEC対応のDNSサービスを利用することで、DNSキャッシュポイズニングのリスクを低減できます。また、定期的にDNSキャッシュをクリアすることも有効です。Windowsでは「ipconfig /flushdns」、macOSでは「sudo dscacheutil -flushcache」コマンドで、ブラウザのキャッシュと併せてクリアすることをお勧めします。

HTTPS対応サイトの利用も重要な対策です。URLが「https://」で始まるWebサイトは、通信が暗号化されており、証明書による認証が行われるため、DNSが汚染されていても、偽サイトにアクセスした際にブラウザが警告を表示することがあります。警告が表示された場合は、絶対にアクセスを続行せず、すぐにブラウザを閉じてください。

VPN（仮想プライベートネットワーク）の利用も効果的です。特に公共Wi-Fiなど信頼できないネットワークを利用する際は、VPNを使用することで、通信が暗号化され、キャッシュポイズニングを含むさまざまな攻撃から身を守ることができます。

企業・Webサイト運営者としての対策では、まずDNSSEC（DNS Security Extensions）の導入が最も効果的です。DNSSECは、DNS応答に電子署名を付加し、DNSキャッシュサーバーがその署名を検証することで、応答が偽装・改ざんされていないかを確認できます。これにより、DNSキャッシュポイズニングに対する防御がほぼ完全になります。実装には、権威DNSサーバーでのDNSSEC設定と、ドメインレジストラへのDS（Delegation Signer）レコード登録が必要です。

ソースポートランダマイゼーションの実装も重要です。DNSキャッシュサーバーの問い合わせ用通信ポート番号を固定せず、ランダムにすることで、攻撃者がDNS応答を偽装する難易度を大幅に上げることができます。2008年のカミンスキー型攻撃発見後、ほとんどのDNSサーバーソフトウェアにはこの機能が標準実装されていますが、古いバージョンを使用している場合は至急アップデートが必要です。

オープンリゾルバーの解消も不可欠です。DNSサーバーを運用する場合は、問い合わせを受け付けるクライアントを信頼できる範囲に限定し、インターネット全体からの問い合わせを受け付けない設定にします。設定ファイルでアクセス制御リスト（ACL）を適切に構成することで、攻撃者が自由にDNS問い合わせを行えないようにします。

Webキャッシュポイズニングへの対策としては、キャッシュキーの厳密な管理が重要です。キャッシュキーに含まれないHTTPヘッダー（X-Forwarded-Host、X-Original-URL、Accept-Encodingなど）の処理を厳格にし、これらのヘッダーがキャッシュされるレスポンスに影響を与えないようにします。また、ユーザー入力をキャッシュキーとして使用しないことも重要です。

静的コンテンツのみのキャッシュに制限することも効果的な対策です。JavaScriptファイル（.js）、CSSファイル（.css）、画像ファイル（.webp、.jpg、.pngなど）のような、常に同一である静的リソースのみをキャッシュし、動的に生成されるコンテンツはキャッシュしないように設定します。これにより、キャッシュポイズニングによる被害範囲を大幅に限定できます。

クロスサイトスクリプティング（XSS）対策の徹底も必須です。キャッシュポイズニングは、多くの場合、XSSと組み合わせて使用されるため、XSS脆弱性を解消することで、キャッシュポイズニングの影響を軽減できます。入力値の適切なサニタイゼーション、コンテンツセキュリティポリシー（CSP）の実装などが有効です。

キャッシュの適切な設定も重要です。Cache-Controlヘッダーで「private」を指定し、個人情報を含むページが共有キャッシュに保存されないようにします。また、必要最小限のTTL（Time To Live、キャッシュの有効期間）を設定し、万が一汚染された場合でも、被害が続く期間を短縮します。

キャッシュ汚染の対策を簡単に言うと？

キャッシュ汚染の対策を日常生活で例えるなら、「電話帳に鍵をかけ、書き込みには署名が必要にする」ようなものです。

先ほどの「電話帳」の例で言えば、キャッシュ汚染対策とは、誰かが勝手に電話帳を書き換えられないように保護することです。まず、電話帳に鍵をかけて、信頼できる人しか編集できないようにします（これがアクセス制御に相当します）。次に、電話帳に新しい番号を追加するときは、必ず信頼できる機関からの「署名」や「証明書」が必要としておけば、偽の情報が入り込むのを防げます（これがDNSSECやHTTPSに相当します）。

また、電話帳の情報を定期的に確認し、おかしな点があればすぐに修正する習慣をつけること（これがDNSキャッシュのクリアやセキュリティ監視に相当します）も大切です。そして、電話をかける前に、その番号が本当に正しいか、別の方法で確認する習慣をつける（これがHTTPS証明書の確認に相当します）ことで、万が一電話帳が書き換えられていても、被害を最小限に抑えられます。

キャッシュ汚染に関連した攻撃手法

キャッシュ汚染は、単独で使用されるよりも、他のサイバー攻撃手法と組み合わせて使用されることが多い攻撃手法です。ここでは、キャッシュ汚染と密接に関連する3つの攻撃手法について解説します。

XSS（クロスサイトスクリプティング）

XSS（クロスサイトスクリプティング）は、Webサイトに悪意のあるスクリプトを埋め込み、そのサイトを訪れた利用者のブラウザで実行させる攻撃手法です。キャッシュ汚染とXSSは非常に相性が良く、しばしば組み合わせて使用されます。

通常のXSS攻撃では、攻撃者が特定の利用者を標的にして悪意のあるリンクを送信する必要があります。しかし、キャッシュ汚染と組み合わせることで、攻撃の規模が劇的に拡大します。攻撃者は、XSSペイロード（悪意のあるスクリプト）を含むHTTPリクエストを送信し、そのレスポンスをキャッシュサーバーに保存させます。すると、その後に同じページにアクセスした全ての利用者が、キャッシュされた悪意のあるコンテンツを受け取ることになります。これは「蓄積型XSS」や「持続型XSS」と呼ばれ、通常の反射型XSSよりもはるかに危険です。

2024年のNext.js脆弱性（CVE-2024-46982）では、まさにこのキャッシュ汚染とXSSの組み合わせが悪用されました。攻撃者は特別に細工したHTTPヘッダーを送信し、悪意のあるJavaScriptコードをキャッシュに注入することで、そのWebサイトを訪れる全ての利用者に対してXSS攻撃を実行できました。

対策としては、キャッシュ汚染とXSSの両方に対処する必要があります。入力値の適切なサニタイゼーション、HTTPOnlyフラグ付きCookieの使用、コンテンツセキュリティポリシー（CSP）の実装などでXSS自体を防ぎつつ、前述のキャッシュ設定の見直しでキャッシュポイズニングを防ぐことが重要です。

オープンリダイレクト

オープンリダイレクトは、Webサイトの正規のリダイレクト機能を悪用し、利用者を攻撃者が用意した悪意のあるWebサイトへ誘導する攻撃手法です。キャッシュ汚染との組み合わせにより、この攻撃の影響範囲が大幅に拡大します。

通常、Webサイトには利用者を別のページへ自動的に転送する「リダイレクト」機能があります。例えば、ログイン後に元のページに戻す場合などに使用されます。しかし、このリダイレクト先のURL検証が不十分だと、攻撃者が任意のWebサイトへのリダイレクトを引き起こせてしまいます。これがオープンリダイレクトです。

キャッシュ汚染と組み合わせると、攻撃者はオープンリダイレクトを引き起こすHTTPリクエストをキャッシュサーバーに送信し、そのリダイレクトレスポンスをキャッシュさせることができます。その後、正規の利用者が同じページにアクセスすると、キャッシュされたリダイレクトレスポンスにより、自動的に攻撃者のWebサイトへ誘導されてしまいます。利用者は、信頼できる正規のWebサイトからリダイレクトされているため、誘導先のWebサイトも安全だと誤認しやすくなります。

2024年の研究では、Hostヘッダーインジェクションとキャッシュ汚染を組み合わせた攻撃により、パスワードリセットメールに含まれるリンクを攻撃者のドメインへリダイレクトさせる事例が報告されています。この場合、利用者がパスワードリセットリンクをクリックすると、リセットトークンが攻撃者のサーバーに送信されてしまい、アカウント乗っ取り（ATO）につながります。

対策としては、リダイレクト先URLの厳格な検証（ホワイトリスト方式）、相対URLの使用、リダイレクトURL検証の実装などが有効です。また、キャッシュ汚染対策として、リダイレクトレスポンスをキャッシュしない設定にすることも重要です。

サプライチェーン攻撃

サプライチェーン攻撃は、ソフトウェアの開発・配信過程に侵入し、正規のソフトウェアやアップデートに悪意のあるコードを埋め込む攻撃手法です。キャッシュ汚染は、このサプライチェーン攻撃の実行手段として悪用される可能性があります。

現代のWebサイトは、多数のサードパーティライブラリ、JavaScriptフレームワーク、CDNから配信されるコンテンツに依存しています。これらの外部リソースがキャッシュ汚染により改ざんされると、その影響は広範囲に及びます。攻撃者は、広く使用されているJavaScriptライブラリやCSSファイルをホストするCDNのキャッシュを汚染することで、そのライブラリを使用する全てのWebサイトに悪意のあるコードを配信できてしまいます。

例えば、攻撃者がCDNのキャッシュポイズニングに成功し、人気のあるJavaScriptライブラリ（jQueryやReactなど）に悪意のあるコードを注入できたとします。すると、そのライブラリを読み込む数千から数万のWebサイトが、知らないうちに訪問者に対して悪意のあるコードを実行してしまいます。これは、一度の攻撃で膨大な数の利用者に影響を与えられるため、サプライチェーン攻撃の中でも特に危険な手法です。

また、ソフトウェアのアップデートプロセスでも、キャッシュ汚染が悪用される可能性があります。DNSキャッシュポイズニングにより、ソフトウェアのアップデートサーバーのドメインを攻撃者のサーバーに偽装すると、利用者が正規のアップデートをダウンロードしているつもりでも、実際にはマルウェアをダウンロードしてしまう危険があります。

対策としては、Subresource Integrity（SRI）の実装が重要です。SRIは、外部リソースのハッシュ値を事前に指定しておくことで、CDNから取得したファイルが改ざんされていないかをブラウザが検証できる仕組みです。また、信頼できるCDNプロバイダーの選定、HTTPS通信の徹底、Content Security Policy（CSP）による外部リソース読み込みの制限なども効果的です。

キャッシュ汚染のよくある質問

Q1. 自分のパソコンがキャッシュ汚染の被害に遭っているか確認する方法はありますか？

キャッシュ汚染の被害に遭っているかを確認するには、いくつかの兆候に注意してください。まず、普段アクセスしているWebサイトのデザインが突然変わったり、見慣れない警告やポップアップが表示されたりする場合は、キャッシュポイズニングの可能性があります。

確認方法としては、DNSキャッシュをクリアして再度アクセスしてみてください。Windowsでは、コマンドプロンプトを管理者権限で開き「ipconfig /flushdns」と入力します。macOSでは、ターミナルで「sudo dscacheutil -flushcache」と入力します。キャッシュクリア後に問題が解消される場合は、キャッシュポイズニングだった可能性があります。

また、複数の異なるネットワーク（自宅のWi-Fi、スマートフォンのテザリング、公共Wi-Fiなど）から同じWebサイトにアクセスして、表示内容に違いがないか確認してください。特定のネットワークでのみ問題が発生する場合、そのネットワークのDNSサーバーが汚染されている可能性があります。

HTTPS証明書の確認も重要です。ブラウザのアドレスバーで鍵マークをクリックし、証明書の詳細を確認してください。証明書が無効だったり、発行者が不明だったりする場合は、偽サイトに誘導されている可能性が高いです。ただし、キャッシュポイズニングは検出が難しいため、定期的なDNSキャッシュクリアとセキュリティソフトの最新化を習慣づけることが最善の対策です。

Q2. 企業のWebサイトを運営していますが、キャッシュ汚染対策で最優先すべきことは何ですか？

企業のWebサイト運営者として最優先すべきキャッシュ汚染対策は、DNSSECの導入とWebキャッシュ設定の見直しです。

まず、DNSSECを実装してください。これは、DNSキャッシュポイズニングに対する最も効果的な防御策です。実装には、権威DNSサーバーでDNSSECを有効化し、ドメインレジストラにDS（Delegation Signer）レコードを登録する必要があります。多くのDNSホスティングサービスやクラウドプロバイダー（Route 53、Cloudflare、Google Cloud DNSなど）は、DNSSECを簡単に有効化できる機能を提供しています。

次に、Webキャッシュの設定を見直してください。特に、CDNやリバースプロキシを使用している場合は、キャッシュキーの設定を厳密にします。HostヘッダーやX-Forwarded-Hostヘッダーなど、キャッシュキーに含まれていないHTTPヘッダーがレスポンス生成に影響を与えないよう、入力検証を徹底してください。また、動的コンテンツや個人情報を含むページには「Cache-Control: private」や「Cache-Control: no-store」ヘッダーを設定し、共有キャッシュに保存されないようにします。

さらに、セキュリティ監視とログ分析を強化してください。異常なDNSクエリパターンや、キャッシュミスが急増している場合、キャッシュポイズニング攻撃の兆候である可能性があります。WAF（Web Application Firewall）やIDS/IPS（侵入検知/防御システム）を導入し、不審なHTTPヘッダー操作を検出・ブロックする設定を行ってください。

定期的な脆弱性診断とペネトレーションテストも重要です。外部のセキュリティ専門家に依頼して、自社のWebサイトとDNSインフラにキャッシュポイズニングの脆弱性がないか確認してもらいましょう。また、使用しているWebフレームワーク（Next.js、WordPressなど）やCDNサービスのセキュリティアップデートを常に監視し、脆弱性が発見されたら速やかにパッチを適用してください。

Q3. DNSキャッシュポイズニングとWebキャッシュポイズニングの違いは何ですか？

DNSキャッシュポイズニングとWebキャッシュポイズニングは、どちらもキャッシュ機能を悪用する攻撃ですが、標的とするシステムと攻撃の仕組みが異なります。

DNSキャッシュポイズニングは、DNS（ドメインネームシステム）のキャッシュサーバーを標的にします。DNSは、ドメイン名（例：www.example.com）をIPアドレス（例：192.0.2.1）に変換するシステムです。攻撃者は、DNSサーバーのキャッシュに偽のIPアドレス情報を注入し、利用者が正規のドメイン名にアクセスしようとしても、攻撃者が用意した偽サイトのIPアドレスに誘導します。この攻撃は、インターネットの基盤インフラを標的にするため、影響範囲が非常に広くなる可能性があります。例えば、ISP（インターネットサービスプロバイダー）のDNSサーバーが汚染されると、そのISPを利用する全ての顧客が影響を受ける可能性があります。

一方、Webキャッシュポイズニングは、WebサーバーやCDN（コンテンツ配信ネットワーク）、プロキシサーバーのキャッシュを標的にします。攻撃者は、特別に細工したHTTPリクエストを送信し、悪意のあるコンテンツを含むHTTPレスポンスをキャッシュサーバーに保存させます。その後、同じリソースを要求した他の利用者に、キャッシュされた悪意のあるコンテンツが配信されます。Webキャッシュポイズニングは、特定のWebサイトやページに影響が限定されることが多いですが、人気の高いページやCDNが汚染されると、数千から数万の利用者に影響が及ぶ可能性があります。

両者の主な違いをまとめると、DNSキャッシュポイズニングは「どのIPアドレスにアクセスするか」を偽装するのに対し、Webキャッシュポイズニングは「特定のWebページのコンテンツ」を偽装します。対策としては、DNSキャッシュポイズニングにはDNSSECやソースポートランダマイゼーション、Webキャッシュポイズニングにはキャッシュキーの厳密な管理とHTTPヘッダー検証が有効です。

Q4. キャッシュの有効期間（TTL）が短ければ、キャッシュ汚染の被害も小さくなりますか？

はい、キャッシュの有効期間（TTL：Time To Live）を短く設定することは、キャッシュ汚染による被害の継続時間を短縮する効果的な対策の一つです。ただし、これは完全な解決策ではなく、他の対策と組み合わせる必要があります。

TTLとは、キャッシュされたデータが「新鮮」とみなされる期間を指定する設定です。例えば、DNSレコードのTTLが3600秒（1時間）に設定されている場合、DNSキャッシュサーバーはその情報を1時間保持し、その間は同じ問い合わせに対して元の権威DNSサーバーに問い合わせることなく、キャッシュから応答します。もしこのキャッシュが汚染された場合、汚染された情報は最大1時間にわたって配信され続けます。

TTLを短くする（例：300秒や60秒）と、キャッシュが汚染されても、その影響が続く時間が短くなります。これは、インシデント発生時の被害拡大を抑え、迅速な復旧を可能にします。また、攻撃者にとっては、短いTTLではキャッシュを継続的に汚染し続けるために、より頻繁に攻撃リクエストを送信する必要があり、攻撃の難易度が上がります。

しかし、TTLを極端に短くすることには欠点もあります。キャッシュの効果が薄れ、サーバーへの問い合わせ回数が増加するため、サーバー負荷が上がり、レスポンス時間が長くなる可能性があります。また、TTLを短くするだけでは、キャッシュポイズニング攻撃そのものを防ぐことはできません。攻撃者は、短いTTLであっても、継続的に攻撃リクエストを送信することで、キャッシュを汚染し続けることができます。

実際には、重要なDNSレコードには中程度のTTL（3600秒〜86400秒）を設定しつつ、DNSSECを導入してキャッシュポイズニング自体を防ぐことが推奨されます。Webキャッシュについても、静的コンテンツには適切なTTL（数時間〜数日）を設定し、動的コンテンツや個人情報を含むコンテンツはキャッシュしない（TTL=0またはCache-Control: no-cache）ことが重要です。TTLの短縮は、他のセキュリティ対策を補完する手段として位置づけるべきです。

Q5. 家庭用Wi-Fiルーターがオープンリゾルバーになっていないか確認する方法はありますか？

家庭用Wi-Fiルーターがオープンリゾルバーになっているかどうかは、オンラインツールを使用して簡単に確認できます。オープンリゾルバーとは、インターネット上の誰でもDNS問い合わせができる設定になっているDNSサーバーのことで、攻撃者に悪用されてキャッシュポイズニング攻撃の踏み台にされる危険があります。

確認方法としては、Open Resolver Projectなどのオンライン診断サービスを利用できます。これらのサービスにアクセスすると、あなたのルーターがオープンリゾルバーになっていないかを自動的にチェックしてくれます。また、DNSチェックツール（Gibson Research CorporationのDNS Spoofabilityテストなど）を使用して、ルーターのDNS機能が外部からアクセス可能かどうかを確認することもできます。

もしオープンリゾルバーであることが判明した場合、以下の対策を実施してください。まず、ルーターの管理画面にアクセスし（通常は http://192.168.1.1 や http://192.168.0.1 など）、DNS設定を確認します。ルーターのDNSフォワーダー機能が有効になっている場合は、外部からのDNS問い合わせを受け付けないように設定を変更してください。多くのルーターでは、「DNSプロキシを有効にする」や「DNSリレーを有効にする」といった設定項目がありますが、これらを無効にするか、アクセス制限を設定することで、オープンリゾルバー状態を解消できます。

また、ルーターのファームウェアを最新バージョンにアップデートすることも重要です。古いファームウェアには、オープンリゾルバーを含むさまざまなセキュリティ脆弱性が存在することがあります。メーカーのWebサイトで最新のファームウェアを確認し、定期的にアップデートを適用してください。

さらに、家庭内ネットワークのDNS設定を見直し、ルーターのDNS機能を使用するのではなく、信頼できる外部DNSサービス（Google Public DNS、Cloudflare DNS、Quad9など）を直接使用する設定に変更することも検討してください。これらのサービスは、DNSSEC対応で、キャッシュポイズニング対策が施されており、セキュリティが高いです。

Q6. キャッシュ汚染の被害に遭った場合、企業はどのような対応をすべきですか？

キャッシュ汚染の被害に遭った場合、企業は迅速かつ組織的なインシデント対応が必要です。初動対応の遅れは、被害の拡大や企業の信用失墜につながるため、事前にインシデント対応計画を策定しておくことが重要です。

まず、被害の検知と確認を行います。異常なアクセスパターン、顧客からの問い合わせ増加、セキュリティツールのアラートなどから、キャッシュポイズニング攻撃の可能性を検知した場合、すぐにインシデント対応チームを招集します。影響範囲を特定し、どのキャッシュサーバー（DNSサーバー、CDN、プロキシなど）が汚染されているか、どのページやリソースが影響を受けているかを確認します。

次に、即座の封じ込めとして、汚染されたキャッシュをクリアします。DNSキャッシュの場合は、キャッシュサーバーの再起動やキャッシュフラッシュコマンドを実行します。Webキャッシュの場合は、CDNやプロキシのキャッシュパージ機能を使用して、汚染されたコンテンツを削除します。緊急性が高い場合は、一時的にキャッシュ機能を無効化することも検討してください。

並行して、利用者への通知を行います。Webサイトのトップページに緊急のお知らせを掲載し、SNSやメールでも情報を発信します。具体的には、「現在、当社のサービスにおいてセキュリティインシデントが発生しており、調査中です。利用者の皆様には、一時的にサービスのご利用をお控えいただくか、アクセス時にブラウザのセキュリティ警告に注意していただくようお願いします」といった内容を伝えます。個人情報漏洩の可能性がある場合は、影響を受けた可能性のある顧客に個別に連絡を取る必要があります。

根本原因の調査と修正も重要です。どのような脆弱性が悪用されたのか、攻撃者はどのような手法を使ったのかを詳細に分析します。ログファイル（アクセスログ、DNSクエリログ、キャッシュログなど）を収集・分析し、攻撃の全容を把握します。脆弱性が特定できたら、速やかに修正パッチを適用します。例えば、DNSソフトウェアのアップデート、Webアプリケーションの脆弱性修正、キャッシュ設定の見直しなどを行います。

再発防止策として、DNSSECの導入、キャッシュキーの厳密化、HTTPヘッダー検証の強化、セキュリティ監視の強化、定期的な脆弱性診断などを実施します。また、インシデント対応計画を見直し、今回の経験を反映させた改善を行います。

最後に、法的対応とコンプライアンスの確認を行います。個人情報保護法やGDPRなどの規制に基づき、必要な場合は監督官庁への報告を行います。また、サイバー保険に加入している場合は、保険会社への報告も忘れずに行ってください。インシデントの詳細な報告書を作成し、関係者（経営陣、取締役会、顧客、パートナー企業など）に共有します。

キャッシュ汚染は、迅速な対応によって被害を最小限に抑えられる攻撃です。事前の準備と訓練が、インシデント発生時の効果的な対応の鍵となります。