京セラコミュニケーションシステム株式会社
プロダクトサービス事業本部　技術顧問
徳丸　浩

　最近問題となっているWebサイトの改ざんは，サイトの改ざん自体が目的ではなく，改ざんされたコードを参照した一般ユーザーを危険なサイトに誘導して，マルウエアを導入することを最終的な目的としている。この目的のため，HTMLのIFRAME要素やSCRIPT要素が利用される場合が多い。

　先に説明したように，SQLインジェクションのぜい弱性を利用してデータベースの内容を，これら要素を使った内容に書き換えることが可能な場合がある。それでも，その内容をそのまま表示するかどうかはサイトの作りによって異なる。

図1●HTMLのエスケープ
図1●HTMLのエスケープ
　一般的にデータベース中の「<」などの特殊記号をそのまま表示するとクロスサイト・スクリプティングのぜい弱性（XSS）の原因となるので，表示の際にこれらの文字をエスケープすることが行われる（図1）。

　現実には多くのサイトにおいて，SQLインジェクションによって挿入されたIFRAME要素やSCRIPT要素がそのまま表示されている。これはつまり，潜在的にXSSのぜい弱性が存在していたことを示している。もしもHTML生成時にエスケープするという正しい方法を採用していれば，万が一データベースが改ざんされたとしても，一般ユーザーにマルウエアを導入させる手前で防げていただろう。

　このように，最近のSQLインジェクションによる改ざん事件では，潜在的にはXSSぜい弱性も利用されていることになるので，SQLインジェクション対策と並行してXSS対策も実施することをお勧めする。もちろん，XSS単独での攻撃を受ける場合に備えて，元々必要な対策である。

■ メタデータに対する参照権限を制限する
　データベースを改ざんするには，データベースの構造（テーブルや列の名称，型など）の情報が必要となる。MS SQL Serverの場合，ビューINFORMATION_SCHEMA.TABLESからテーブル情報を参照でき，同様にビューINFORMATION_SCHEMA.COLUMNSから列情報を参照できる。これらのデータ構造に関する情報をメタデータと呼ぶが，MS SQL Serverに限らず，その他のデータベースにもメタデータ取得のためのテーブルやビューがある。また，エラー・メッセージからテーブルや列の情報の一部が表示される場合もある。

　メタデータやエラー・メッセージから得られるデータ構造情報は外部からの攻撃に有益であるため，これら情報を極力出さないようにすることがSQLインジェクション対策の保険的対策として有効である。具体的には，以下の二つの対策を行うとよい。

  • INFORMATION_SCHEMAなどメタデータを提供するテーブル，ビュー，スキーマなどに対して，参照権限のないユーザーによりアプリケーションを実行する
  • エラー・メッセージにはシステム的な内容を表示せず，ユーザー向けの表現にとどめる

これらにより，万一SQLインジェクション攻撃を受けた場合でも，データを改ざんされるリスクを減少できる。

■ テーブルの更新権限を制限する
　Webアプリケーションで扱うデータには，ユーザーが更新できるものと参照だけが可能なものがある。ブログや掲示板の場合，ユーザーが更新した情報を別のユーザーが閲覧することになるが，その他の多くのサイトでは，ユーザーは「リード・オンリー」の情報を閲覧していることになる。ECサイトの場合は，商品カタログの内容がこれに該当する。

　ただ多くの場合，アプリケーションが使用するデータベース・ユーザーは，これら「リード・オンリー」のテーブルに対しても更新権限を持っていることが多い。SQLインジェクションの被害が急増している状況から考えると，データベースに対する権限を細かく設定しておくことは，保険的対策として価値があると考えられる。

■ SQL ServerとPostgreSQLは特に注意を
　現在SQLインジェクションによる改ざん攻撃は，マイクロソフトのIISとSQL Serverの組み合わせを利用しているサイトに集中しているが，既にマイクロソフトから発表があったように，これら製品のぜい弱性が原因というわけではない 。

　ただ筆者の調査によると，攻撃の受けやすさはデータベースの種類によって差がある。SQLインジェクションによりデータベースを改ざんする際には，SQLの「複文（Multiple Statements）」が利用されているからだ。複文が利用できるかどうかは，データベースと記述言語（およびライブラリ）の組み合わせによって決まる。筆者が調査した範囲では，SQL ServerとPostgreSQLではSQLインジェクションによる改ざんが容易。OracleとMySQLの場合は改ざんできる条件が非常に限定されていた。

　SQL ServerやPostgreSQLに原因があるわけではなく，あくまでもアプリケーションのぜい弱性が原因なわけだが，現実にSQL Serverで被害が多発していること，ラボの検証でもSQL ServerとPostgreSQLでの改ざんが容易であったことから，これらのデータベースを利用する際には，SQLインジェクションに一層気をつける必要があると言える。

●その他のぜい弱性パターンについても対策を
　ここまで，Webアプリケーションぜい弱性を利用したサイトの改ざん手段の典型例としてSQLインジェクションを取り上げ説明した。技術的には，Webサイトの改ざんに利用できるぜい弱性の種類はほかにもある。たとえば，「OSコマンド・インジェクション」がそれ。先に取り上げたXSSも，サイトの性質によってはiframeやJavaScriptの埋め込みに利用できる場合がある。

　また，改ざんだけがWebサイトのセキュリティ脅威ではなく個人情報漏えいなどを避ける意味からも，ほかのぜい弱性パターンについても対策を講じておくべきである。

●一度は専門家によるぜい弱性診断を
　様々なパターンのぜい弱性対策を自力で実施する場合は，「安全なWebサイトの作り方 改訂第3版」などを活用するとよいだろう。「安全なWebサイトの作り方」は，無料で入手できる資料としては内容の正確性や，読みやすいボリュームという理由から推薦できる。

　同書は入門的な性格を持つ資料であるため，網羅性という点では十分とは言い切れない。Webアプリケーションのぜい弱性パターンは多様であり，複雑なアプリケーションのぜい弱性を網羅的に探すには，専門性と労力の両方が必要だ。一番よいのは，セキュリティの専門家に依頼して既存のWebサイトのぜい弱性を診断してもらい，指摘されたぜい弱性についてアプリケーションの改修を行うことである。

　筆者がセキュリティコンサルタントとして対策後の再診断を実施した際，修正されていなかったり，不十分な修正にとどまっていた例を数多く経験してきた。できるだけ早期に予算を確保して，専門家に診断してもらうことを強く推奨する。

●まとめ
　最近急増しているWebサイトの改ざん事件に対して，対策の基本を解説した。アプリケーションのぜい弱性対策，プラットフォームのぜい弱性対策，パスワード攻撃対策など，いずれもサーバーのセキュリティ対策としては基本的なものばかりだ。本稿を参考に，身の回りのサーバーに対するセキュリティ対策を見直されることをお勧めする。