PR

ケース別、攻撃の手口

2009年2月27日(金)
近藤 伸明

SQLインジェクションの侵入の手口

 今回は、SQLインジェクションの侵入の手口を紹介するが、その前に注意がある。本記事は、システムを防御するにはまず敵を知らなければならない、という意図の下に、攻撃手法を紹介する。実際に試す場合、自分の管理下にあるサーバー以外には絶対に行ってはいけない。ほかのサーバーに攻撃を試した場合、「不正アクセス行為の禁止等に関する法律」に抵触する可能性がある。

 自分の管理下にあるサーバーでも、予期しないトラブルが発生することを考慮し、破壊しても問題ない環境を用意するか、問題が発生してもすぐに復旧できるような措置を講じてほしい。また、第3回で紹介した防御方法もあわせて確認してほしい。

 さて、ここから実際にSQLインジェクションの侵入の手口を紹介する。

 まず、会員サイトなどでユーザーID、パスワードを使って認証して、専用ページを表示するような一般的な認証システムを想定する。この場合、事前に用意されているSQL文は以下のようなものだ。

select * from users where id=’$userid’ and password=’$pass’;

 $useridの部分に入力したユーザーID、$passの部分にパスワードを入れてデータベースにアクセスするSQL文を完成させる。例えば、ユーザーIDに「abc001」、パスワードに「abc123!”#」を入力した場合、以下のようなSQL文となる。

 select * from users where id=’ abc001’ and password=’ abc123!”#’;
データベースに該当する組み合わせのデータが存在すれば、認証が成功する。ここで、ユーザーIDに「' or 1=1 --」を入力したとするとどうだろう。SQL文は、以下のようになる。

select * from users where id=’' or 1=1 --’ and password=’’;

 「--」以降はコメントとなり、以下と同意になる。

select * from users where id=’' or 1=1

 検索条件は「id=’'」または「1=1」となり、常に条件が成り立つこととなる。つまり、データベースに登録されたユーザーIDとパスワードに関係なく、常に会員専用のページにアクセスできるのだ。

 これが認証を迂回(うかい)する最も初歩的な攻撃方法だ。似たような方法で作成者の意図しないSQL文を実行させ、データベースに対して不正な要求を実行し、データベース上の情報を閲覧/改ざんする方法がSQLインジェクションである。

 なお、この攻撃は第3回で紹介した「バインド機構」「エスケープ処理」が
対策として有効だ。

攻撃の窓口となる場所は?

 SQLインジェクションの脆弱(ぜいじゃく)性を狙った攻撃では、一般的にWebブラウザからWebサーバーに送信するHTTPリクエストメッセージの中にSQLインジェクションに使用する攻撃コードを挿入する。

 HTTPリクエストメッセージの中で攻撃を仕掛けることのできる場所は以下の3つだ(図1)。

・HTTPリクエストライン
・HTTPヘッダ
・HTTPメッセージボディー

 まず、HTTPリクエストラインに指定するURIパラメタに攻撃を仕掛けられる。例えば「http://≪ホスト名≫/example.cgi?p=1&code=abc」のように、URLの後ろに「?」記号に続けて、指定されているパラメタを改ざんして、攻撃コードを仕掛ける。

 また、入力フォームからの入力の場合でもFORMタグのmethod属性にGETが指定されている場合は、HTTPリクエストラインに格納され送信される。入力フォームの値を改ざんすれば、攻撃コードを仕掛けることができる。

 HTTPリクエストラインは通常のWebサーバーのログでも攻撃コードの内容を記録することができるため、攻撃内容を検知することはログの監視を行っていれば比較的容易だ。

 続いて、HTTPヘッダではフィールドの値を使って攻撃できる。HTTPヘッダには、汎用ヘッダ、リクエストヘッダ、エンティティヘッダ、Cookieなどがあるが、いずれのヘッダもフィールドにある値をWebアプリケーション側で取り出し、SQL文の生成に利用している場合は、SQLインジェクションの攻撃対象になる可能性がある。

 例えばWebアプリケーションでCookieの値を取り出し、SQL文の生成に使用する場合、Cookieに攻撃コードを仕掛けることができる。

 HTTPサーバーの標準のログ設定では、HTTPヘッダの内容を全て記録していない場合があるので注意が必要だ。

 そして、HTTPメッセージボディーに含まれる値をWebアプリケーションが取り出して、SQL文の生成に使用している場合も、攻撃の対象になる可能性がある。

 HTTPメッセージボディーは、HTTPリクエストラインよりも大きなサイズのデータをサーバーに送信することができる。例えば、HTTPメッセージボディーを使用して、入力フォームでFORMタグのmethod属性にPOSTが指定する場合や、AjaxなどでWebAPIに対しHTTPメソッドのPOSTを使用してアクセスする場合だ。

 HTTPメッセージボディーは大きなデータサイズを取り扱うことができ、開発者にとって利便性が高い反面、HTTPサーバーの標準のログ記録機能では、攻撃コードの内容を記録できないため攻撃者の行動が追跡しにくい。

 これらの窓口からの攻撃は、HTTPサーバーの標準のログだけではなく、WAF/IDS/IPSなどによるログ監視が有効である。

 続いて、「個人情報や企業の機密情報など、その情報だけで換金できる情報」「システム情報やデータベースを構成する情報などWebサイトを攻撃するための有用な情報」を入手する場合の手法について解説する。

株式会社神戸デジタル・ラボ

2003年神戸デジタル・ラボに入社。
2007年からWebセキュリティ診断業務を事業化し、現在に至る。
2008年4月に経済産業省から発表された「モデル取引・契約書(追補版)」のセキュリティガイドライン ワーキング・グループ委員として「Web アプリケーションセキュリティ」を担当。
2010年10月、CSS2010にてセキュリティ関連論文を発表するなど、診断業務のかたわらセキュリティ基盤研究開発業務に活躍中。

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています