Webサイト防御のためにできること：今、見直すWebアプリケーションのセキュリティ

Webサイトへの攻撃が後を絶たない。改ざんや悪質サイトへと誘導するその手口はさらに巧妙化し、従来のIPSなどでは防ぎきれなくなった。サイトを脅威から守るために、今すぐできるセキュリティ対策を紹介する。

[大野祐一，ラック サイバーリスク総合研究所]

　2005年春、2007年春に猛威を振るったSQLインジェクション（※注1）の検知数が、2008年の3月上旬から当時の何倍もの規模にまで増えてきた（図1）。正直なところSQLインジェクションは「過去の遺物」であり、ほとんどのサイト運営者が何らかの手を打ち、もう絶滅したと思われていたが、現在も被害に遭うサイトは後を絶たない（図2）。

※注1　第三者がWebアプリケーションなどのセキュリティ上の脆弱性を悪用してデータベースの不正な操作を可能とする攻撃手法

図1●JSOC（ラックセキュリティ監視センター）で検知したSQLインジェクションの件数

図2●被害サイトは予想以上（Googleの検査結果）《クリックで拡大》

　ここではWebアプリケーション（以下、Webアプリ）の脆弱性対策の話が中心であるため、攻撃の詳細にまでは触れないが、一連の攻撃で厄介だったのは、攻撃コードが難読化されていたことである（図3）。攻撃コードの難読化により、既存のベンダー製シグネチャが適用されたIDS／IPS（不正侵入検知／防御システム）などでは検知できないため、自組織では攻撃があったことに気付かなかった。利用者や第三者からの指摘があるまで放置されていたのである。

　その結果、Webページに利用されているデータベースの値（HTMLの一部になる値）が改ざんされ、ページを改ざんされたのと同じ状態となった。そのサイトにアクセスしたユーザーは知らないうちに悪質なプログラムをダウンロード・実行し、Webブラウザや音楽プレーヤーなどのプログラムの脆弱性を突いて攻撃者に情報を送信したり、ウイルスに感染したりしてしまう。さらに各サイトの攻撃コード（スクリプト）も難読化されていたため対応が遅れ、被害規模が大きくなってしまったのだ。

図3●難読化されている攻撃コード

　皆さんのサイトは本当に大丈夫だろうか？　もし不安なら、以下に挙げるようなIPA（情報処理推進機構）やわれわれのようなセキュリティベンダーが提供する無償ログチェッカーで、攻撃の有無を調べてみることをお勧めする。仮に攻撃があったと判定されたとしても、誤検知の場合もあるので慌てず内容を確認し、攻撃が本物か誤検知かを判断する。攻撃が本物ならその攻撃が成功していそうか否か、また攻撃されているWebアプリの脆弱性（設計／プログラミング上の欠陥）の有無などを調べてみるとよい（自組織で調べられない場合は後述を参照）。そのほか、とにかく不安なら最初から身近なセキュリティベンダーに相談するのもよいだろう。

• iLogScanner（IPA提供）
• SecureSite Checker Free（ラック提供）

対策の大前提――セキュリティ対策の要件化

　まず、セキュリティ対策を発注する側が注意する点を考える。Webアプリのセキュリティ対策に限らず、セキュリティ対策を考える際に重要なことは、発注者側が満たすべき要件をシステムインテグレーター側に要求することである。「インテグレーターの技術者は言われなくてもきちんと対策をやってほしい」と彼らの良心に期待するのは自由だが、セキュリティ対策はほとんどの場合、要求しなければ実装されない。なぜなら、アプリケーションの機能を追加したときと同様、セキュリティ対策にはお金が掛かるからである。

　では、どのように要求すべきか？　まずは自社のセキュリティポリシーやシステム開発標準などを確認し、その上で日本ネットワークセキュリティ協会（JNSA）の「Webシステム　セキュリティ要求仕様（RFP）」編 β版やPCI DSS（クレジットカード業界のセキュリティ基準）などを参考に提案依頼書（RFP）を作成してみてはいかがだろうか。

　次に対策を行う側、つまり開発者側にとってWebアプリのセキュリティ対策の中心は、セキュアなアプリケーションを開発することである。しかし、そのアプリケーションが稼働するサーバが欠陥だらけでは、下位レイヤーのOSやミドルウェアから攻められてしまう。従って、従来言われている「サーバの要塞化（ハードニング）」「セキュリティパッチ適用の徹底」などの基本的な対策を怠ってはいけない。どの分野においても基本は大事である。

関連ホワイトペーパー

Webアプリケーション | 脆弱性 | IPS | IDS | SQL | IPA（情報処理推進機構）