パスワードを忘れた? アカウント作成
39103 story
セキュリティ

クッキーを使ったSQLインジェクション、詳細が明らかに 50

ストーリー by hylom

Anonymous Coward曰く、

以前/.で話題になったクッキーを使ったSQLインジェクションについて、詳細が日経IT-PLUSで解説されている

記事によると、今回判明したSQLインジェクション攻撃はASPやASP.NET、PHPなどでCGIがデータを受け取る際に使用する関数の仕様を突いたものだそうだ。たとえばASPでは「Request("引数名")」という関数でGET/POSTに関係なくCGIに渡されたデータを取得できるが、この際にcookieとして渡された情報も取得対象となってしまう(たとえば、Request("data1")という関数を呼び出した際、GETもしくはPOSTでdata1というデータが送信されず、さらにdata1という名前のcookieが存在した場合、そのcookieの値が取得される)。

これを利用すると、cookieとして送信したデータを、CGI側ではGET/POSTで送信されたもののように扱わせることができる。侵入検知システムなどが導入されている場合、不正なGET/POSTについてはブロックできるようになっていることが多いが、cookieについては見落とされていることが多いため、これにより不正なリクエストを侵入検知システムにブロックされずに送信できるようになる。

また、SQLインジェクションに利用される文字列に「%」を埋め込むことにより、侵入検知システムをくぐり抜けるテクニックも使われていたそうだ。「%」は通常、URLエンコードで用いられるキーであるが、IIS/ASPでは無効な%(%のあとの2文字に0~9およびA~F以外の文字が含まれる)際には%を無視する仕様がある(たとえば「DEC%LARE」という文字はIIS/ASPでは「DECLARE」と認識される)。これを利用して、侵入検知システムをだますことも可能になる。

また、記事内ではPOSTやcookieを使った攻撃は内容がWebサーバーのログに残りにくいため、痕跡が残りにくいという(攻撃者にとっての)メリットもあるとのことだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 要するに (スコア:4, すばらしい洞察)

    by Anonymous Coward on 2008年10月30日 14時41分 (#1447166)
    もともとSQLインジェクション脆弱性のあるシステムをIDSで守るだけで放置していたら、
    IDSをすり抜けられてインジェクションを喰らったということか。

    先に脆弱性を直せよ。
    • by Anonymous Coward
      根本から問題抱えたシステムなんて、直すより使わない方がいいと思うよ。
      • by Anonymous Coward
        つまり会社ごとt(ry
    • by Anonymous Coward
      GETパラメータ経由であろうがCookieであろうが,
      そもそもなんで外から渡されたSQL文がそのまま
      SQL文として実行されるのかと・・・

      値の渡し方に気をつけるより,他にやることがあるだろう.
      • by Anonymous Coward
        なるほど、SQLではなく別のデータベース言語を使えってことですね?
  • PHPだと$_REQUESTが諸悪の根源だってことなのかな。
    PHPerにとっては常識だと思うんだけど・・・。

    仕事でこれ使ったコード見つけたら 書いた奴呼び出してシバき倒すけどね。
    中途採用でVBを10年やってました!って奴がこういうことを知らずに書くから怖い。
    というか畑違いはこっちくんなと・・・。

    // そして泣く泣く修正し深夜に全工程をテストして再リリースの王道パターン(:>^
    // 新人だけのプロジェクトとか技術者一年生向けの問題周知なんだろうけど。
    • Request関数にはGET/POST/クッキーそれぞれに対応した関数があるから、Requestは使うなという話がすでに前々から挙ってはいるはず。 最近のドキュメントはほとんどそうなっているはずなのだが、なんでRequest使うんじゃいと。
      --
      theInsiderman(-1:フレームの元)
      親コメント
    • PHPだとSuhosinで守れるかなと思っているのですが
      考えが甘いかなぁ(Cookieだけに)

      親コメント
    • PHPだと$_REQUESTが諸悪の根源だってことなのかな。
      PHPerにとっては常識だと思うんだけど・・・。

      すいません知りませんでした。(仕事じゃないけど)
      なにがまずいんでしょう?
      親コメント
      • by Anonymous Coward on 2008年10月30日 16時12分 (#1447229)
        たとえば、hoge.php?PHPSESSID=セッションID
        とかいうリンクを他人に踏ませると、このセッションIDでログインさせる事ができる。
        (PHPSESSIDという名前のクッキーも、get変数PHPSESSIDも、$_REQUEST['PHPSESSID']では区別しないから)
        要するに、セッションキーを盗むのと同じ効果が得られる。セッション・フィクセーション攻撃という、古い古い攻撃手法。
        phpのバージョンが古く、session_start()でセッション管理をしてる場合、phpが$_REQUEST相当の変数からセッションキーを読み出す仕様になっている。

        それ以外でも、POSTとGETを区別しない$_REQUESTは色々マズい。
        例えば<img src="http://www.example.com?title=spam&text=hoge">なんてタグを適当な場所に貼る事で
        掲示板に連POST、みたいな事もできたりする。
        親コメント
        • なるほど勉強になりました。ありがとうございます。
          親コメント
        • by Anonymous Coward
          >POSTとGETを区別しない$_REQUESTは色々マズい。

          Java Servlet方面(のお勉強)でも、
          doGetとdoPostを速攻で同じひとつのメソッドに委譲しちゃう、なんてな実装は
          ふつうに書かれていますな。

          …致命的?

          >例えばなんてタグを適当な場所に貼る事で
          >掲示板に連POST

          これは「掲示板はGETで書けるように実装すべきではない」っていう話ですか?

          …そんなの掲示板の仕様によるんじゃないの?
          「ふつうの」掲示板ではたしかにGETで書けるようにしとくメリットは少ないけど。
          • by Anonymous Coward
            これは個人的意見じゃなく、「CSRF攻撃」という非常に有名な手口ですよ、と言ったら反応が変わったりするのかな。
            getとpostを同一視していい場合と、してはダメな場合がある。
            検索フォームなんかはどっちでも受け取れたほうが便利だし、実際そうなってる事が多い。
            一般に、参照系はgetでも問題ない事が多い。getという名が示す通りだが。
            逆に、データ送信系、投稿系など副作用のあるものをgetで受けてしまうと火種になる。

            >「掲示板はGETで書けるように実装すべきではない」
            結論から言うとイエス。
            途中の遷移(表示確認とか)はgetを使ってもいいが、最後の最後、サーバー側のDBなりストレージなりに
            変更を加えるリクエストは、一切の例外なく、技術的に可能ならば常にpostのみを受け付けるべき。
        • by Anonymous Coward

          それは$_REQUESTを使うことが問題なのではなくて、それ以前にリクエストメソッドのチェックが必要な場面でチェックしてないことが問題なのでは?

    • 常識なんですか?
      自分も知りませんでした。
      デバッグくらいでしか使ってないですけどね。

      Post/Getの取得用のラッピング関数を作って使い回してます。
      Postのみ有効とか、Getも取得するとか・・・・仕様変更が楽なので。
      親コメント
      • by Anonymous Coward
        ・リリース時に誤ってデバッグコードを有効にしたままだった!
        ・仕様変更したらペネトレーションテストでパスしていた項目が通らなくなった!
        ・新人がPOSTとGETは区別せず扱うものだと学習した!

        どれがいい?
        • >・リリース時に誤ってデバッグコードを有効にしたままだった!
          これは、リリース手順に問題があるって事では?
          テストしないでリリースなんて・・・してる人たまにいそうですね。
          ってか、デバッグくらいでしか使わないとは言ったけど、デバッグで常に使うわけではないし。

          >・仕様変更したらペネトレーションテストでパスしていた項目が通らなくなった!
          これも仕様変更の方法の問題では?
          通らなくなったら、通る方法を考えなければいけないのはどんな仕様変更でも可能性はあるでしょう?

          >・新人がPOSTとGETは区別せず扱うものだと学習した!
          これは問題ですね。
          でも、直接$_POST/$_GETにアクセスさせると、それはソレで障害のタネになるので一長一短はありそうです。

          基本はPostしか使わないようにしていれば、リスクは軽減されると思いませんか?
          親コメント
          • by Anonymous Coward
            > 基本はPostしか使わないようにしていれば

            最近はRESTというものが流行っておってのう
    • by Anonymous Coward
      PHPの慣習は知りませんが、
      SQLインジェクションが問題な訳であって、値取得方法は
      REQUESTだろうと何だろうと問題ないのでは?
      SQL発行時にエスケープ(サニタイジング)処理を
      行ってないのが根源かと。
      • 確かに。
        inputはどんなのでも、DBに入れる段階でキチンと検査・下処理しておけばinjectionは起きませんものね。

        phpが話題に上がっているのは$_GETと$_POSTと$_COOKIEがマージされたものが$_REQUESTに入るから
        値が本当にそのmethodで来たものかは件の機器では分からないよ、ってことらしいですな。

        そもそも検査とかデータの正当性検査とかは組み込む奴が作るものだし、
        何某の機器で誤魔化そうとすること自体に違和感を感じるけどなぁ。
        親コメント
      • by Anonymous Coward
        PHPやASP.NETは入力時にエスケープ処理を行ってしまう設定が
        デフォルトでONだったりするために
        SQL発行時にまたエスケープすると駄目なケースもあるかと。

        自作ならいいけど、途中から派遣されて参加した場合は
        設定変えろとも言えないし。

  • 抽象化(及び抽象化って良いことという観念)の暗黒面じゃないだろうか。

    POSTもGETもリクエスト側からのデータである -> オブジェクトとして抽象化できる -> しました
    cookie もリクエストのデータと見なせる -> さらに抽象化できる -> しました

    そして cookie 自身には他にメタデータはあるけど、POSTやGETに無いからとにかくキーと値としてみなした結果がこれだよ

    フレームワークによっては GET,POST,cookie は明確に分離されているから、この程度でオブジェクト指向の暗黒面というと言い過ぎかもしれない。そしてフレームワーク云々ではなく自ら今回の挙動を引き起こすようなモジュールを作成して悦に浸る輩は絶えなさそう・・・。

  • by dokusuke (36955) on 2008年10月30日 15時32分 (#1447189) 日記
    全くやり方が解りません…

    もっと解りやすく説明できる猛者はいますか?

    クッキーを保存させるサイトを訪問した時に保存されたクッキーの内容を改竄して
    サーバにSQLを送りつけることができるってことですか?

    その時に%を紛れ込ませることで
    $res = str_replace("select","ERR",$res); みたいな小細工をすりぬけされて
    se%le%ct ac,pw fro%m tblpwd; とかをサーバに実行させるって話なの?

    アホすぎてごめん
    • by rose (10717) on 2008年10月30日 15時49分 (#1447202)
      別にサイトがCookieを使っている必要はない。
      GETやPOSTの代わりにCookieで渡すだけです。
      親コメント
    • by Anonymous Coward
      上で、他の人が書いるけど、要するに
      ・コード上は、今までのSQLインジェクションと同じ。
      ・ただし、言語によっては、POSTのパラメータやGETのパラメータを表す変数が、(利便の為か)REQUESTとしてまとめられているのだが、そのREQUESTの内容は、えてして、COOKIEも混じっている、という話。
      (COOKIEまで混じっているのは、REQUESTの意味合いが、外部からのパラメータ、という意味だからかな?)

      POST: name=hogehoge, value=fugafuga
      COOKIE: name=root, value=password
      という風になっていた場合、hogehoge fugafuga が、root passwordに置き換えられてしまう、という事。

      # と、理解したんだが、間違ってたら修正プリーズ

      %の話は、また別の話ね。
      • by Anonymous Coward
        get/postパラメータのチェックはやってるかも知れないけど、cookieへのチェックはあんまりやってないだろう。
        言語によってはcookieもget/postパラメータと同様と見なされるから、もしかしたらやばいんじゃないの?
        って意味でしょ。

        cookieで送られれば、必ずSQLインジェクションが成功しちゃうってわけでもない。
        どこから出たパラメータかによらず、パラメータはパラメータとしてちゃんと処理してやればいいわけで。
        • by Anonymous Coward
          >get/postパラメータのチェックはやってるかも知れないけど、cookieへのチェックはあんまりやってないだろう。
          >言語によってはcookieもget/postパラメータと同様と見なされるから、もしかしたらやばいんじゃないの?

          get/postとcookieとを区別しないなら、
          get/postのチェックをすれば、必然的にcookieもチェックしてしまうのではないでしょうか。
          ファイアウォールとかプログラム以外のチェックだけにまかせているなら、
          cookie が同列に扱われないのは分かるけれど、それはそれで問題だと思います。
          あとget より post や cookie で Webサーバーのログに残りづらいのはあると思います。
          • by Anonymous Coward
            >ファイアウォールとかプログラム以外のチェックだけにまかせている
            まさに今回はそれを問題にしてるんでしょう。

            なので、方々で言われてるとおり、アプリ内でちゃんとチェックしてれば関係のない話。
  • JSPタンとお付き合いを始める方はいませんか?
    つーか、ASP,ASP.NET,PHPと並ぶということは、JSPはそんなにマイナーなのか
  • by Anonymous Coward on 2008年10月30日 14時37分 (#1447164)
    coolie
  • by Anonymous Coward on 2008年10月30日 14時39分 (#1447165)
    CGIって厳密にはインターフェースなんだから、

    ASPやASP.NET、PHPなどでCGIがデータを受け取る

    というか

    ASPやASP.NET、PHPなどがCGIを通してデータを受け取る

    だと思うんだよ。

    通じるから全然問題ないんだけど。
    • by Anonymous Coward
      ASPやPHPはCGIでは無いのでは?

      CGIってWebサーバーのソフトウェアが
      他のソフトウェアを動かすインターフェースですよね。

      ASPもPHPもWebサーバー自身に組み込まれているのでCGIという気がしません。
      (たしか chmod a+x みたいなのも不要じゃなかったでしたっけ?)
      • 他のソフトウェアとのデータの受け渡しインタフェースであって
        外部プログラムであるかは関係ありません。

        RFC 3875 CGI Version 1.1 より
        http://www.ietf.org/rfc/rfc3875.txt [ietf.org]
        > 'script'
        > The software that is invoked by the server according to this
        > interface. It need not be a standalone program, but could be a
        > dynamically-loaded or shared library, or even a subroutine in the
        > server.

        > スクリプト
        >   このインタフェースに従ってサーバにより起動されるソフトウェア。
        >   独立したプログラムである必要はなく、動的にロードされるライブラリ、
        >   共有ライブラリ、さらにはサーバ内のサブルーチンの場合もあり得る。
        親コメント
  • by Anonymous Coward on 2008年10月30日 14時51分 (#1447172)
    甘いもの食べ過ぎですよ。
  • by Anonymous Coward on 2008年10月30日 15時01分 (#1447174)
    「Cookie」って書いてくれよ。「クッキー」って書かれてたから一瞬、素で食べ物のクッキーを使ったネタ系のニュースかと思ったぞ。
    • by Anonymous Coward
      そんなこと言って、cookieと書いたら書いたで漫画雑誌 [shueisha.co.jp]と勘違いするじゃないかとかいうくせに。
  • by Anonymous Coward on 2008年10月31日 0時33分 (#1447610)
    詳細が明らかに?
    前回のストーリーのときに既に明らかになってたことばかりのようだけど?
typodupeerror

にわかな奴ほど語りたがる -- あるハッカー

読み込み中...