Webサイトへの攻撃対応を前回に引き続き解説する。Web改ざんは「見えない改ざん」へと巧妙化してきている。狙われやすいのはCMS（コンテンツ・マネジメント・システム）の脆弱性だ。事故対応の基本となる早期発見に向け、事前準備を徹底しよう。

　外部に公開するWebアプリケーション（Webサイト）が攻撃された場合のセキュリティ事故（インシデント）対応を、前回に引き続き解説します。今回はWebアプリケーションの改ざん対策と被害に遭った場合のCSIRT（情報セキュリティインシデント対応チーム）の対応を取り上げます。

　インシデント対応は、一般的に「発見」→「初動対応」→「復旧・再発防止」→「事後対応」の4ステップで進めます。今回は4ステップの前段階である「事前準備」と、3ステップ目の「復旧・再発防止」までについて解説します。

CMSの脆弱性が狙われている

　「Web改ざん」と聞くと何を思い浮かべるでしょうか。真っ黒な背景にドクロマークが表示されている画面や、政治的・社会的な主張に書き換えられた画面など、見た目が分かりやすい例を連想されるのではないでしょうか。

　しかし、近年は本連載第3回で詳解したように一見しただけでは改ざんが全く分からないケースが増えています。この場合、攻撃者の目的はいたずらでも技術力の誇示でも政治的・社会的主張でもありません。Webサイトを閲覧した人に気付かれずにPCをマルウエアに感染させる「ドライブ・バイ・ダウンロード攻撃」の成功です。

　攻撃者がWebアプリケーションを改ざんする手口は二つあります。一つは何らかの手段でサーバーのアカウント情報を入手し、なりすまして侵入、改ざんする方法です。

　「何らかの手段」とは、例えば、Webアプリケーションが動作するサーバーにアクセス権を持つ人が設定した安易なパスワードを攻撃者が見破ることです。物理的な盗み見やSNSなどから情報を集めるソーシャルエンジニアリングや標的型攻撃でアカウント情報を盗むケースもあります。