パスワードを忘れた？ アカウント作成
Close
36631 submission
日記

Cookieを使用したSQLインジェクション 33

タレコミ by schiavona
schiavona 曰く、
Cookieを使用したSQLインジェクションについて、LACから注意喚起のリリースが出ている。対象となるのは、IIS/ASP/ASP.NET上で開発されたWebサイト。攻撃内容がCookieに埋め込まれているため、そこを見ていないIDS/IPSによる検知をくぐり抜け、デフォルト設定だとCookieの内容はログに記録されないため、痕跡が残っていないケースが多そうだ。

攻撃元IPアドレスも公表されているため、ひとまずはこれをチェックすることはやっておいたほうがいいかもしれない。もちろん、ほかのIPアドレスからの攻撃も十分あり得る。

ちなみに、リリースとほぼ同じくしてゴルフダイジェスト・オンラインがやられているため、これも同じ攻撃だったかもしれない。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Cookieを使用したSQLインジェクション More

  • ASPがひどすぎる (スコア:4, 参考になる)

    by kanie (911) on 2008年10月06日 18時29分 (#1432823)

    ASP.NETで入力されたデータを HttpRequest.Params を使って取得すると、GET, POSTの他にCookieの値も混ざっている、ということですね。この仕様はPHPの $_REQUEST と同じ。こんなWebサイトがIDSなどに頼っていた場合はいつもの被害が発生。SQLインジェクションでやり放題、もしくはXSSでセッションや秘密情報が盗まれると。

    しかし、HttpRequest.Paramsで検索 [google.com]しても887件しか引っかからないところをみると、ほとんどの人はRequest.QueryString, Request.Formを使っているようです。
    # そもそもHttpRequest.Paramsを知らない?

    それよりも驚いたのは以下の部分。

    IIS/ASPでは、%に続く文字が16進数表記できない文字列が続いた場合、%を除去して、WebアプリケーションにSQL文を送り込みます。この場合、「DEC%LARE 」や「e%xec」はそれぞれ「DECLARE 」や「exec」としてWebアプリケーションに渡されます。よって、構文エラーなどにならず、(当該WebアプリケーションにSQLインジェクションの脆弱性が存在した場合)攻撃SQL文が実行されてしまいます。IDS/IPSでは、リクエストに含まれる特定のキーワードとのパターンマッチにより、SQLインジェクションの試みを検知します。このため、検知するキーワードの中に無効な%が含まれると、検出するのが非常に困難になります。

    どういう理由でこんな仕様になってるんでしょうね。

    • 訂正されてます (スコア:4, 参考になる)

      by t-wata (10969) on 2008年10月07日 3時53分 (#1433122) 日記

      10月2日に公開した本レポート中において、脆弱性が再現できる環境に誤った記述がありましたので訂正をいたします。
      具体的には、特徴2の記載内容において、ASP.Netでは%に続く文字が16進数表記できない文字列が続いた場合、%を除去せずにそのままWebアプリケーションに引き渡します。つまり、ASP.Netでは特徴2には該当しません。
      本訂正にあたり、上原和彦様にご協力をいただきました。ここに、心より感謝の意を表します。
      だそうです。
      なので、さすがに%を除くという通常の発想の範囲外な実装では無いようです。
      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      うっひょー、これぞ Microsoft の真骨頂ですなあ。

      久しぶりに見た気がする。

      • Re:ASPがひどすぎる (スコア:1)

        by kanie (911) on 2008年10月06日 19時41分 (#1432863)

        Microsoftがこういう訳の分からない仕様にするときって、

        • 互換性のため
        • 競合と同じ振る舞いをして、顧客を奪うため

        のどちらかだから、今回もそうだと思うのですが...どうなんでしょうか。

        Windowsなんてそんなののカタマリですしね。クジラの内臓がはみ出たOSです。

        シェア
        親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      Webアプリケーション側でURLエンコードのデコードを正常に行うためでは？
      それにIDS/IPSはURLエンコードが不正な時点で弾くべきだとも思いますが。

      # そーいや、IISにゃそんなフィルタ [microsoft.com]があったな。

    • Re: (スコア:0)

      by Anonymous Coward
      > # そもそもHttpRequest.Paramsを知らない?

      ASP.NET + VB.NETだと
      HttpRequest("paramname")
      で値が取得できるのですが、この場合の挙動は HttpRequest.Params と同じようです。

      HttpRequest.FormやHttpRequest.QueryStringを明示的に指定していないHttpRequest("paramname")なコードの方が引っかかりそうな気がします。

  • PHP? (スコア:1)

    by 127.0.0.1 (33105) on 2008年10月06日 17時24分 (#1432751) 日記
    LACのレポートでは、

    > （Cookieにてパラメータを受け取れるフレームワークは
    > IIS/ASP/ASP.NET以外にPHPも同様と確認していますが、
    > 現時点では他のフレームワークの状況は当研究所では未確認です。）

    とありますが、実際のところPHPはどうなんですかね?

    #自分で確認したいけど今忙しいので!
    • セッション情報をDBに保存する仕組みの所はヤバいかもなぁ、とここ数年さわってないけど言ってみるテスト。

      ＃確かに、Sessionはテイントチェックしてなかった気がする。前のバイト先のプログラムをうすらぼんやり思い出してみると。
      シェア
      親コメント

      • Re: (スコア:0)

        by Anonymous Coward
        ＞セッション情報をDBに保存する仕組みの所はヤバいかもなぁ

        いや、それぜんぜん今回の問題に関係ないでしょ。

        • Re:PHP? (スコア:1)

          by __hage (7886) on 2008年10月06日 21時47分 (#1432938)
          そのセッション情報をユーザーと(厳密にはユーザの使っているブラウザのプロセスと)結びつけるためにcookieを利用する手法が今は一般的です。なので今回の話に大いに関係があります。勿論これだけに限った話ではないですが、無関係と言い切れるほど関係のない話ではありません。
          シェア
          親コメント

          • Re: (スコア:0)

            by Anonymous Coward

            そのセッション情報をユーザーと結びつけるためにcookieを利用する手法が今は一般的です。
            「今は」どころか昔から当然。

            なので今回の話に大いに関係があります。
            ぜんぜん関係ない。

            勿論これだけに限った話ではないですが、無関係と言い切れるほど関係のない話ではありません。
            無関係。「言い切れるほどではない」などという表現を使ってる時点で無意味な発言だと気付こう。

        • Re: (スコア:0)

          by Anonymous Coward
          PC用WebブラウザをターゲットとしたWebアプリの場合、セッションIDはCookieで特定しているケースが多いので

          ・CookieにSQLインジェクションの攻撃コードがある
          ・Cookieの内容(=セッションID)をDBに保存する
          ・DB保存のコードにSQLインジェクション脆弱性があるとSQLインジェクションが成功

          ということでSQLインジェクションが発生しやすくなりますね。
          今回のケースはASPのRequest()で書いたコードが引っかかる可能性が高そうなのですが、あちこちにバラまいたコードを修正する、という意味ではSQLインジェクション対策とどっちがマシか状態になるかもしれません。

          • Re: (スコア:0)

            by Anonymous Coward

            • CookieにSQLインジェクションの攻撃コードがある
            • Cookieの内容(=セッションID)をDBに保存する
            • DB保存のコードにSQLインジェクション脆弱性があるとSQLインジェクションが成功
            ということでSQLインジェクションが発生しやすくなりますね。
            ならねーよ。元記事読んで来い。

    • Re: (スコア:0)

      by Anonymous Coward
      PHPも同様です。

  • サニタイズ言うな！ (スコア:0, 興味深い)

    by Anonymous Coward on 2008年10月06日 15時37分 (#1432684)
    これこそ高木先生が展開していた「サニタイズ言うなキャンペーン [takagi-hiromitsu.jp]」のターゲットとなる好例ですな。GETやPOST以外からでもデータは入ってくるんだよ、ということで。

    # と私は解釈しているのだが間違ってますかね。

    • Re:サニタイズ言うな！ (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2008年10月06日 16時09分 (#1432703)
      誤解が誤解を生んでる好例に見えた。そのキャンペーン自体くだらないと思ってる派ですが
      シェア
      親コメント

      • Re:サニタイズ言うな！ (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2008年10月06日 16時43分 (#1432720)
        くだらないというなら、こんなのに引っかかる連中の方でしょ？
        考える力が足りないから何度も同じようなSQLインジェクションに引っかかるし、サニタイズ言うなキャンペーンも誤解する
        全くどうかしてる
        シェア
        親コメント
        • 連中ってどの範囲を指しますか？
          1. そのようなコードを書いた本人
          2. そのようなコードがあることを見逃して納品した開発チーム or 開発チームリーダ or プロジェクトマネージャ
          3. そのようなコードがあることを見逃して検収を完了させた発注元
          4. そのようなコードがあることを知らずにサーバ上に乗っけているインフラチーム
          5. そのようなコードがあることを知らずに運用させている発注元の経営者
          6. そのようなコードがあることを知らずに利用しているユーザ
          ちなみにこの時、一番被害を蒙るのはどこでしょうか。

          シェア
          親コメント

          • Re: (スコア:0)

            by Anonymous Coward
            「連中」とは1,2、被害を被るのは6じゃない？

            ところでサニタイズ言うなキャンペーンは誰が対象ですか？
            1. そのようなコードを書いた本人
            2. そのようなコードがあることを見逃して納品した開発チーム or 開発チームリーダ or プロジェクトマネージャ
            3. そのようなコードがあることを見逃して検収を完了させた発注元
            4. そのようなコードがあることを知らずにサーバ上に乗っけているインフラチーム
            5. そのようなコードがあることを知らずに運用させている発注元の経営者
            6. そのようなコードがあることを知らずに利用しているユーザ

            ちなみにこの時、サニタイズｗやら文字のエスケープを意識すべきなのはどこでしょうか。

            #なんなの？この人？？
            • フツウは被害者と「罠にかかる」人が一致していないと、マヌケとは言わないのでは。

              被害を蒙らないことをいいことに意図して罠にかかっている場合を考慮しているのかどうか。
              もし、そういう人もマヌケと呼ぶのなら、タブン私と #1432720 のAC氏とはマヌケの定義が違うのでしょう。

              と、それはおいといて。
              プログラムの作成を発注して意図して穴を残された場合、どこまで瑕疵責任を負わせることができるのでしょう。
              IT法務ライブラリ [nikkeibp.co.jp]の記述を見ると、

              過去の裁判例を検討すると，システムの処理速度に関する瑕疵が「重大な瑕疵」と判断されているケースが目につきます
              とあるわけですが、セキュリティホールはどうなるのでしょう。
              私は法律の専門家ではないので推測しかできませんが、意図しての行為だとしても「滅多に無いことだ」とか「製造時は予想できなかった」と言い張られると追求が厳しそうな。
              また、意図してかどうかは、どの程度立証可能なのかとか。考えると厳しそうですけど…。
              # 法律の専門家の方、突っ込み願います

              もし、もし瑕疵責任を取らせることが難しいとなると、SQLインジェクションによる問題はいつまでもなくならないのかもしれないと危惧してしまうわけです。
              そこで、法律上もある程度は瑕疵責任を特別に認定できるようにしておく必要性というものが見えてくるのですが、それはそれで問題がでそうですね。
              そんなわけで、開発者は納期に追われて厳しいと言われている昨今、啓蒙だけではSQLインジェクション問題が無くならないのではと思ってしまうわけですが、いかがでしょうか。

              シェア
              親コメント
              • サイバーノーガード戦法 [wikipedia.org]なら企業が被害者になることは無いのでいくらでもばっちこいなのでは？
                原因が把握され対応もできる脆弱性が敢えて放置されるのはそれを放置しても(利用者はどうかしりませんが)企業は困らないからだと思いますよ。
                そして既にそれがデファクトスタンダードになりつつあるから自分のとこがそうでも気にしないのでは？ならば、そもそものところでSQLインジェクション問題が無くなるわけがないと思われ。
                --
                ◆IZUMI162i6 [mailto]
                シェア
                親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      つまり Cookie も消毒しなきゃ！ってことですね。（否

      jbeef たんが言いたかったのは「必要なところでエスケープしようキャンペーン」だと思ってたのだけど、
      いずれにしてもその真意を誰も理解していないという点でキャンペーンとしては失敗だったんじゃないかな。

      # と半可通がデレッとした顔で言ってみる

      • Re:サニタイズ言うな！ (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2008年10月06日 20時44分 (#1432903)
        真意も何も、「サニタイズするな」キャンペーンは有意な主張を成しておらず実質何も言ってないのと同じだと思うんですが。
        ・「必要なところ」って何？「出力する直前」という概念は本当にwell-definedか？
        ・何らエスケープされないデータがプログラム内を広く流通する(かもしれない)状況を作り出したとき、リスク増大しない根拠は？

        どう考えても結局データ形式の選択と管理は徹頭徹尾プログラマの責任であり、
        エスケープの有り様は要件と周辺状況に応じて適切に選択されるべきという
        分かりきった結論しか残らんとです、、

        「サニタイズするな」キャンペーン賛同者の大半が「誤解してるかもしれませんが、、」と恐る恐る私的解釈を述べるのも、
        キャンペーンの主張が曖昧であることの裏返しだと思う。

        なおプログラムの階層設計と絡めて上記キャンペーンを理解しようとしてる人もいるようですが、
        階層設計で綺麗にすれば問題解消、というのは数学的根拠に欠けた単なる経験知にすぎず、一般性に疑問符。
        シェア
        親コメント

        • Re: (スコア:0)

          by Anonymous Coward
          君は全然判ってない。自分で思ってるほどには賢くないよ。

        • Re: (スコア:0)

          by Anonymous Coward
          > 数学的根拠に欠けた単なる経験知にすぎず

          ここが笑うところですか。

  • 着眼点 (スコア:0)

    by Anonymous Coward on 2008年10月06日 21時12分 (#1432915)
    こういう手法を最初に編み出す奴は、やってることは糞だが
    着眼点はすごいなと思う。

    だが所詮、糞は糞だ。

  • 攻撃元IPが判っているのに (スコア:0)

    by Anonymous Coward on 2008年10月06日 21時24分 (#1432923)
    攻撃元IPが割と限定されているみたいだけど、
    当局ってこういうのには無力なの?
typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー