SQLを文法解析して不正アクセスを防ぐ~Oracle Security Forum Report | graybanのブログ

graybanのブログ

ブログの説明を入力します。

SQLインジェクションが脅威でありつづける理由

 Database Firewallは、米国で今年2月に発表された新製品で、SQLに特化したファイアーウォールともいうべき特徴を持つ。

 西村氏はまず、近年のSQLインジェクションの動向として、2006年頃から被害がではじめた比較的古い攻撃でありながら、引き続き最も多い攻撃の1つであるとし、2010年は「ガンブラー」とともにインターネットの二大脅威であったことを紹介。

実際、LACの調査によると、2010年上半期に確認されたウェブ系攻撃103件のうちSQLインジェクションは35件と、クロスサイトスクリプティングの38件につぐシェアを占めている。「クレジットカード情報などの盗難事故は継続しており、情報を盗むだけでなく、ウイルス頒布や受動的攻撃といったほかの攻撃の足がかりとして使われることも多い」という。

 その一方で、IPAの調査資料「IPA Web Application Firewall読本」によると、SQLインジェクション対策は遅れがちであり、脆弱性を発見したとしても、修正までに1カ月以上の時間を要しているという。その原因としては、「すでに開発者がいない、仕様が分からない」などの技術的な問題、「膨大に増えるWebサイトをすべてチェックできない」などの運用的な問題、「Webサイトの長期停止による機会損失や膨らみ続ける改修費用」などのコスト的な問題があるようだ。

 また、内部や外部からの不正アクセスを早期に検知するという点では、ログをとることが重要だが、実際には活用が進んでいないという現実もある。その理由としては、そもそもデータベースの監査ログの機能を知らない、データベースパフォーマンスへの影響を懸念している、どのログを取得すべきか監査条件が絞り込めない、ログを保存する領域が膨大になる、ログをモニタリングしていないなどが挙げられるという。

 こうした背景のもと、SQLインジェクションは、今日もなお、インターネット上の脅威でありつづけている。そこで、データベース側でSQLインジェクションに対抗する手段として、注目してほしいのがDatabase Firewallだという。

不正なSQL文を遮断するファイアーウォール製品

 Database Firewallは、アプリケーションとデータベースの中間に位置し、ネットワークトラフィックからSQL文を収集?解析するファイアウォール製品だ。機能は「ブロッキング」と「モニタリング」の2つ。ブロッキングは、SQLを解析し、危険と判断されるものはブロックや警告を行うことで内部不正、外部攻撃からデータベースを保護するもの。モニタリングは収集したSQLをログとして記録し、レポーティングを行うものだ。

 西村氏によると、Database FirewallがWebアプリケーションファイアーウォールやIPS/IDSと決定的に異なる点は、SQLの文法解析エンジンを積んでいることにある。ファイアーウォール製品の多くは、パターンマッチングによって、パケット中の文字列を正規表現などで検索し、ブロックするかパスするかを決めている。だが、これをSQL文にあてはめた場合、例えば「TRUEとなる条件」1つとっても、「1=1」「20000=(1000+19000)」「'dog'='dog'」「SIN(45)=COS(45)」など、数えきれない表現の仕方があり、検出する文字列をすべて網羅するような条件を設定することは不可能だ。

 また、SQL文は、そもそもトランザクションが多く、フォールスポジティブ(誤検出:正しいSQLを不正なSQLとして検出してしまうこと)やフォールスネガティブ(検出漏れ:不正なSQLを検出せずに見逃してしまうこと)が運用管理の手間や不正アクセスのリスクを増大させやすいという問題もある。例えば、1秒あたり3000のSQLが発行されているシステムの場合、1日に換算すると260万SQLとなる。ここで、フォールスポジティブの発生率が0.001%だとすると、1カ月あたり7800件のアラートが発生する。一方、フォールネガティブの発生率が0.0001%だとすると、1カ月あたり28件の不正アクセスを受ける可能性がある。

 Database Firewallの文法解析エンジンでは、キーワード、スキーマ、データ、 演算子といったSQLの文法にそって、SQLが正しいか不正かを判断する。このため、パターンマッチングのような問題は引き起こさず、高精度の検知が可能になっているという。設置の仕方としても、アプリケーションとデータベースの間に直列に配置する(ブロッキングの場合)か、ネットワークスイッチと並列に配置する(モニタリングの場合)だけでよく、既存のデータベースへの変更は一切必要ない。

 パフォーマンスについても、「非常に軽く」作られており、オーバーヘッドは1SQLあたり200マイクロ秒程度だという。「ブロッキングを施しても既存のデータベースへの影響はほとんどない。モニタリングの場合はポートミラーリングを利用するオーバーヘッドはゼロ」(同氏)となる。実際、海外のある投資銀行では、24時間365日稼働する600超のデータベースについて1日1.7億トランザクションをさばいていることを紹介した。

齋藤公二 [著]