3月11日頃から突然、中国からのSQLインジェクションが急増した（http://www.lac.co.jp/news/press20080312.html）ことは記憶に新しい。この一連の攻撃の目的は定かではないが、世界中の多くのサイトのコンテンツが改竄された。興味深いのは、従来のiframeタグの挿入ではなく、スクリプトタグの挿入であることや、誘導サイトで利用されているツールキットが、中国産の攻撃ツールであったこと、悪意あるJavaScriptにfuckjpとしていることなど、中国ハッカーの独自色が出ていることが挙げられる。これに対し、これほど改竄されるサイトが存在したことにも驚きが隠せない。攻撃手法の傾向が、OSやサーバアプリケーションの脆弱性を狙ったものから、Webアプリケーションの脆弱性を狙ったものへと変化したことに、未だ世界中が対応出来ていないことが露呈したのだ。先日、公開されたWhiteHat Securityのレポート（http://www.whitehatsec.com/home/news/08presssarchives/NR_stats032408.html）によると、10サイト中のうち9サイトは攻撃者がExploit可能な脆弱性を保有しているという。中でも、XSSは全体の約70%で、SQLインジェクションにおいては、6サイト中１つだという。このデータは診断サービスを受けるようなセキュリティ意識の高い企業のものであることを考えると、世の中が標準的にセキュアなWebサイトを構築されることはまだまだ先なのかもしれない。そこで、本稿ではWebアプリケーションの攻撃への対策を考えてみた。■負荷分散のススメプログラマ依存の対策は、人的リソースやスピードなどに限界がある。つまり、ミスは必ず発生するものと考えるべきだ。(1) WAF安定度や攻撃検知精度が疑問なWAFだが、決して悪いわけではない。これらの製品には、スクリプトキディからの7割〜8割程度の攻撃が遮断されれば良いと考えるべきだ。これだけでもコード修正を行うプログラマからすると、負荷が軽減されるはずだ。IDS/IPSでも良いのだが、最近の攻撃はURLエンコードなどの回避技術が取り込まれていることや、Webのトラフィックを処理する際のパフォーマンス面を考慮すると適切ではない。(2) ホスト型セキュリティツールApache対応のmod_securityや、「FORTIFY Defender」のようなホスト型セキュリティツールなども有効だ。ホワイトリストを作成するタイプや、ある程度の安全性を確保するタイプのツールが殆どだ。運用が少々面倒であるが、コードを常にチェックすることに比べれば、自動的に攻撃のダメージを軽減してくれるため、効果は大きい。(3) サーバ設定Webアプリケーションばかりに目がいってしまうが、SQL Serverなどの場合は設定も重要な要素だ。例えば、エラーメッセージを出力設定だ。この設定は、デバッグ用にオンにされていることが多いが、攻撃者はこの設定を悪用して重要情報を出力することが多い。そのため、エラーメッセージを出力しないだけでも、根本的ではないがリスクを軽減することが可能だ。さらに、SQL Serverの自由度の高さを示す代表的な機能といえば、システム拡張ストアドプロシージャなどの問題が挙げられる。これらの使用を停止するだけでも有効だ。(4) 楽天等の利用全く話が異なるが、開発を諦めて楽天等に運用を任せてしまうのも手段のひとつだ。個人情報の取り扱いやサーバの運用等、一括でアウトソースすることで、コスト面を含めて大幅にリスクを軽減させることが可能だ。但し、決まった仕様で管理が可能な、小中規模のWebサイトに限られてしまうため、大規模サイトの運用は少々難があるとは思う。最近の事件を見ていると、別の傾向が見えてきた。それは…【執筆：二根太】【関連記事】セキュアにならないWebサイト(1) 改善されない理由とはhttps://www.netsecurity.ne.jp/3_11450.html──※ この記事は Scan購読会員向け記事をダイジェスト掲載しました購読会員登録案内 http://www.ns-research.jp/cgi-bin/ct/p.cgi?w02_ssw
