Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

[PR]小規模ECサイトに最適なWAF、SiteGuard Lite

徳丸浩の日記


2008年05月02日 複文が利用できるデータベースの調査

_SQL Serverが狙われるには理由がある

SQLインジェクションを利用したWebサイトの改ざん事件が頻発している。標的となったサイトの多くがIIS(ASP)とSQL Serverの組み合わせを利用していることから、今回の攻撃がIISやSQL Serverの脆弱性を利用したものだと言う報道があるらしい。
これに対して、マイクロソフトが反論している。 「SQLインジェクション攻撃とIISは無関係」とMicrosoft

 しかしMicrosoftはセキュリティ対策センター(MSRC)のブログで、今回のWebサーバ攻撃では「未知の脆弱性や新しい脆弱性は悪用されていないことが当社の調査で分かった」と説明。攻撃はIISやSQL Serverの脆弱性を突いたものではなく、アドバイザリー951306の脆弱性とも無関係だとした。

これはまぁ、もっともな内容だと思う。しかし、疑問は残る。なぜ、IISとSQL Serverの組み合わせが狙われるのか。これに対する理由は色々と憶測できるが、私はSQLインジェクションによるデータ改ざんを行う上で重要となる「SQLの複文」に注目している。 SQLインジェクションによるサイト改竄 2008-03-20 - T.Teradaの日記によると、 Neil Carpenter’s Blog : Anatomy of a SQL Injection Incident, Part 2: Meatを引用する形で、今回の攻撃を以下のように説明している。

非常におおざっぱに言うと、以下のような感じです。

1. リクエストを送ってみて、SQLインジェクション脆弱性があるか調べる。
2. 脆弱性がある場合、それを突いて、全テーブルの、全カラムの、全レコードの値を改竄する*1。具体的には、DB格納値の末尾に「<script src=http://www.211796...(省略)」のような攻撃コードを追加する。
3. DBのデータをエスケープせずにHTMLに出力している箇所があると、挿入されたJavaScriptがユーザのブラウザ上で動作して、これが悪さをする。

この2番目のフェーズでは、T-SQL(Transact-SQL)というSQL Serverの拡張SQLが利用されているのだが、SQLインジェクションにより以下のようなリクエストでこれを実行している。

d=z';DECLARE%20@S%20NVARCHAR(4000);SET%20【略】

すなわち、セミコロンにより複数のSQLを記述する「複文」が利用されている。

ところで、SQL Injection Cheat Sheetという文書によると、言語とデータベースの組み合わせにより、この複文が利用できるか否かが異なっている。

SQL Server MySQL PostgreSQL Oracle
ASP
ASP.NET
PHP ×
Java ×
凡例:
○:複文に対応
×:複文に非対応

ごらんのように非常に不完全な表であるので、手元の環境で補完してみることにした。ただし、自宅のPCがWindowsXP Home Editionなので、IISを実行することができない。そのため、ASPとASP.NETは調査から除外し、代わりににPerlを追加して、SQL Server、MySQL、PostgreSQl、Oracleについて、調査を行った。

SQL Server MySQL PostgreSQL Oracle
PHP × ×
Java × ×
Perl × ×
凡例:
○:複文に対応
△:更新系のSQLであれば複文に対応
×:複文に非対応

事前の予想では、言語依存もあるのかなと思っていたのだが、確認してみると言語依存はほとんどなく、データベースの種類によって決まるようだ。

SQLインジェクションによって複雑なことを行う(とくに更新系)ためには、複文が利用できるかどうかが問題となる。広く利用されているデータベースでは、SQL ServerとPostgreSQLで複文が利用できることは、攻撃者の立場から考えると、ターゲットにしやすいプラットフォームということになる。PostgreSQLは日本では人気があるが、世界的には他の三種のデータベースほど普及していない。このように考えると、SQL Serverが狙われる背景には、(Microsoftの責任とは言えないにしても)、それなりの理由があるのだと考える。

本日のリンク元
アンテナ
その他のリンク元
検索


[PR]小規模ECサイトに最適なWAF、SiteGuard Lite

ockeghem(徳丸浩)の日記はこちら
HASHコンサルティング株式会社

最近の記事

  • 2011年08月30日
    • 1. RSSフィードをリダイレクトします
  • 2011年07月01日
  • 2011年03月29日
    • 1. PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因
  • 2011年03月22日
    • 1. PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合(脆弱性)あり
  • 2011年01月27日
    • 1. CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
  • 2011年01月04日
    • 1. escapeshellcmdの危険な実例
  • 2011年01月01日
    • 1. PHPのescapeshellcmdの危険性
  • 2010年10月03日
    • 1. 問題点の概要
  • 2010年09月27日
    • 1. 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
  • 2010年07月25日
    • 1. ツッコミSPAM対策で、ツッコミ抜きのRSSフィードを用意しました
  • 2010年07月01日
    • 1. ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
  • 2010年04月06日
    • 1. PROXY(プロキシ)経由でのDNSリバインディングと対策
  • 2010年04月05日
    • 1. JavaアプレットのDNSリバインディングはJRE側で対策済みだった
  • 2010年03月29日
    • 1. DNSリバインディングによる無線LANパスフレーズの読み出しに成功
  • 2010年03月25日
    • 1. DNSリバインディングによるルータへの侵入実験
  • 2010年02月22日
    • 1. ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された
  • 2010年02月12日
    • 1. かんたんログイン手法の脆弱性に対する責任は誰にあるのか
  • 2010年01月18日
    • 1. iモードブラウザ2.0のXMLHttpRequestでPOSTデータの扱いが困難になった
  • 2009年10月19日
    • 1. quoteメソッドの数値データ対応を検証する
  • 2009年10月14日
    • 1. htmlspecialchars/htmlentitiesはBMP外の文字を正しく扱えない
  • 2009年10月09日
    • 1. htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
  • 2009年09月30日
    • 1. htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか
  • 2009年09月24日
    • 1. SQLの暗黙の型変換はワナがいっぱい
  • 2009年09月18日
    • 1. 文字エンコーディングバリデーションは自動化が望ましい
  • 2009年09月14日
    • 1. 既にあたり前になりつつある文字エンコーディングバリデーション
  • 2009年08月05日
    • 1. 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性
  • 2009年03月28日
    • 1. IPAは脆弱性の呼び方を統一して欲しい
  • 2009年03月27日
    • 1. IPAの新版「セキュア・プログラミング講座」がイマイチだ
    • 2. JETエンジンにおいてパイプ記号「|」は今でも「危険」なのか
  • 2009年03月11日
    • 1. U+00A5を用いたXSSの可能性
  • 2008年12月22日
    • 1. JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性

最近のツッコミ

Google