クッキーを使ったSQLインジェクション、詳細が明らかに 50
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, すばらしい洞察)
IDSをすり抜けられてインジェクションを喰らったということか。
先に脆弱性を直せよ。
Re: (スコア:0)
Re: (スコア:0)
全くその通り (スコア:0)
そもそもなんで外から渡されたSQL文がそのまま
SQL文として実行されるのかと・・・
値の渡し方に気をつけるより，他にやることがあるだろう．
Re: (スコア:0)
モノの品質に問題あるんじゃないのそれ (スコア:1)
PHPerにとっては常識だと思うんだけど・・・。
仕事でこれ使ったコード見つけたら 書いた奴呼び出してシバき倒すけどね。
中途採用でVBを10年やってました！って奴がこういうことを知らずに書くから怖い。
というか畑違いはこっちくんなと・・・。
// そして泣く泣く修正し深夜に全工程をテストして再リリースの王道パターン(:>^
// 新人だけのプロジェクトとか技術者一年生向けの問題周知なんだろうけど。
Re:モノの品質に問題あるんじゃないのそれ (スコア:2, 参考になる)
theInsiderman（-1:フレームの元）
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
このへんとかですね。
>これらは信頼できるとは限りません。
としか書いてないや。
Re: (スコア:0)
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
考えが甘いかなぁ（Cookieだけに）
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
すいません知りませんでした。(仕事じゃないけど)
なにがまずいんでしょう?
Re:モノの品質に問題あるんじゃないのそれ (スコア:3, 参考になる)
とかいうリンクを他人に踏ませると、このセッション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、みたいな事もできたりする。
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
Re: (スコア:0)
Java Servlet方面(のお勉強)でも、
doGetとdoPostを速攻で同じひとつのメソッドに委譲しちゃう、なんてな実装は
ふつうに書かれていますな。
…致命的？
>例えばなんてタグを適当な場所に貼る事で
>掲示板に連POST
これは「掲示板はGETで書けるように実装すべきではない」っていう話ですか？
…そんなの掲示板の仕様によるんじゃないの？
「ふつうの」掲示板ではたしかにGETで書けるようにしとくメリットは少ないけど。
Re: (スコア:0)
getとpostを同一視していい場合と、してはダメな場合がある。
検索フォームなんかはどっちでも受け取れたほうが便利だし、実際そうなってる事が多い。
一般に、参照系はgetでも問題ない事が多い。getという名が示す通りだが。
逆に、データ送信系、投稿系など副作用のあるものをgetで受けてしまうと火種になる。
>「掲示板はGETで書けるように実装すべきではない」
結論から言うとイエス。
途中の遷移（表示確認とか）はgetを使ってもいいが、最後の最後、サーバー側のDBなりストレージなりに
変更を加えるリクエストは、一切の例外なく、技術的に可能ならば常にpostのみを受け付けるべき。
Re: (スコア:0)
それは$_REQUESTを使うことが問題なのではなくて、それ以前にリクエストメソッドのチェックが必要な場面でチェックしてないことが問題なのでは？
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
自分も知りませんでした。
デバッグくらいでしか使ってないですけどね。
Post/Getの取得用のラッピング関数を作って使い回してます。
Postのみ有効とか、Getも取得するとか・・・・仕様変更が楽なので。
Re: (スコア:0)
・仕様変更したらペネトレーションテストでパスしていた項目が通らなくなった！
・新人がPOSTとGETは区別せず扱うものだと学習した！
どれがいい？
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
これは、リリース手順に問題があるって事では？
テストしないでリリースなんて・・・してる人たまにいそうですね。
ってか、デバッグくらいでしか使わないとは言ったけど、デバッグで常に使うわけではないし。
>・仕様変更したらペネトレーションテストでパスしていた項目が通らなくなった！
これも仕様変更の方法の問題では？
通らなくなったら、通る方法を考えなければいけないのはどんな仕様変更でも可能性はあるでしょう？
>・新人がPOSTとGETは区別せず扱うものだと学習した！
これは問題ですね。
でも、直接$_POST/$_GETにアクセスさせると、それはソレで障害のタネになるので一長一短はありそうです。
基本はPostしか使わないようにしていれば、リスクは軽減されると思いませんか？
Re: (スコア:0)
最近はRESTというものが流行っておってのう
Re: (スコア:0)
SQLインジェクションが問題な訳であって、値取得方法は
REQUESTだろうと何だろうと問題ないのでは？
SQL発行時にエスケープ（サニタイジング）処理を
行ってないのが根源かと。
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
inputはどんなのでも、DBに入れる段階でキチンと検査・下処理しておけばinjectionは起きませんものね。
phpが話題に上がっているのは$_GETと$_POSTと$_COOKIEがマージされたものが$_REQUESTに入るから
値が本当にそのmethodで来たものかは件の機器では分からないよ、ってことらしいですな。
そもそも検査とかデータの正当性検査とかは組み込む奴が作るものだし、
何某の機器で誤魔化そうとすること自体に違和感を感じるけどなぁ。
Re: (スコア:0)
デフォルトでONだったりするために
SQL発行時にまたエスケープすると駄目なケースもあるかと。
自作ならいいけど、途中から派遣されて参加した場合は
設定変えろとも言えないし。
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
あえて言ってしまうと (スコア:1)
POSTもGETもリクエスト側からのデータである -> オブジェクトとして抽象化できる -> しました
cookie もリクエストのデータと見なせる -> さらに抽象化できる -> しました
そして cookie 自身には他にメタデータはあるけど、POSTやGETに無いからとにかくキーと値としてみなした結果がこれだよ
フレームワークによっては GET,POST,cookie は明確に分離されているから、この程度でオブジェクト指向の暗黒面というと言い過ぎかもしれない。そしてフレームワーク云々ではなく自ら今回の挙動を引き起こすようなモジュールを作成して悦に浸る輩は絶えなさそう・・・。
Re: (スコア:0)
Re:あえて言ってしまうと (スコア:1)
ごめん (スコア:1)
もっと解りやすく説明できる猛者はいますか？
クッキーを保存させるサイトを訪問した時に保存されたクッキーの内容を改竄して
サーバにＳＱＬを送りつけることができるってことですか？
その時に％を紛れ込ませることで
$res = str_replace("select","ERR",$res); みたいな小細工をすりぬけされて
se%le%ct ac,pw fro%m tblpwd; とかをサーバに実行させるって話なの？
アホすぎてごめん
Re:ごめん (スコア:1)
GETやPOSTの代わりにCookieで渡すだけです。
Re: (スコア:0)
・コード上は、今までのSQLインジェクションと同じ。
・ただし、言語によっては、POSTのパラメータやGETのパラメータを表す変数が、（利便の為か）REQUESTとしてまとめられているのだが、そのREQUESTの内容は、えてして、COOKIEも混じっている、という話。
（COOKIEまで混じっているのは、REQUESTの意味合いが、外部からのパラメータ、という意味だからかな？）
POST: name=hogehoge, value=fugafuga
COOKIE: name=root, value=password
という風になっていた場合、hogehoge fugafuga が、root passwordに置き換えられてしまう、という事。
# と、理解したんだが、間違ってたら修正プリーズ
%の話は、また別の話ね。
Re: (スコア:0)
言語によってはcookieもget/postパラメータと同様と見なされるから、もしかしたらやばいんじゃないの？
って意味でしょ。
cookieで送られれば、必ずSQLインジェクションが成功しちゃうってわけでもない。
どこから出たパラメータかによらず、パラメータはパラメータとしてちゃんと処理してやればいいわけで。
Re: (スコア:0)
>言語によってはcookieもget/postパラメータと同様と見なされるから、もしかしたらやばいんじゃないの？
get/postとcookieとを区別しないなら、
get/postのチェックをすれば、必然的にcookieもチェックしてしまうのではないでしょうか。
ファイアウォールとかプログラム以外のチェックだけにまかせているなら、
cookie が同列に扱われないのは分かるけれど、それはそれで問題だと思います。
あとget より post や cookie で Webサーバーのログに残りづらいのはあると思います。
Re: (スコア:0)
まさに今回はそれを問題にしてるんでしょう。
なので、方々で言われてるとおり、アプリ内でちゃんとチェックしてれば関係のない話。
「ＩＩＳ／ＡＳＰとの付き合い方を考える時期」とのことで (スコア:0)
つーか、ASP,ASP.NET,PHPと並ぶということは、JSPはそんなにマイナーなのか
Re:「ＩＩＳ／ＡＳＰとの付き合い方を考える時期」とのことで (スコア:1)
Re: (スコア:0)
Re:「ＩＩＳ／ＡＳＰとの付き合い方を考える時期」とのことで (スコア:1)
PHPではWebServerとのやりとりの為のインターフェースは
CGI(Common Gateway Interface)ではないのですか？
Servletの場合、Servletコンテナは１つのアプリケーションで
Apacheとtomcatの場合はajp [hatena.ne.jp]というプロトコルがインターフェースですが．．．
Re: (スコア:0)
そうじゃない作り方もできるけど。
Re: (スコア:0)
Re:「ＩＩＳ／ＡＳＰとの付き合い方を考える時期」とのことで (スコア:1)
＃もっとマイナーでごじゃるが。
Re: (スコア:0)
でもGAEのほうはWebObってやつの派生みたいだから似てるだけか。
そんで肝心の今回の脆弱性は、、、cookieとは区別されてるっぽいからいいのかな。まあ元々SQLじゃなくてGQLとか、独特なインターフェースなので直接比較しにくいですが
Python なら (スコア:1)
＃決して PSP を勧めているわけではありません。
IEカコイイ (スコア:0)
どうでもいいけど (スコア:0)
というか
だと思うんだよ。
通じるから全然問題ないんだけど。
Re: (スコア:0)
CGIってWebサーバーのソフトウェアが
他のソフトウェアを動かすインターフェースですよね。
ASPもPHPもWebサーバー自身に組み込まれているのでCGIという気がしません。
(たしか chmod a+x みたいなのも不要じゃなかったでしたっけ？)
Re:どうでもいいけど (スコア:1)
外部プログラムであるかは関係ありません。
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.
> スクリプト
> このインタフェースに従ってサーバにより起動されるソフトウェア。
> 独立したプログラムである必要はなく、動的にロードされるライブラリ、
> 共有ライブラリ、さらにはサーバ内のサブルーチンの場合もあり得る。
ウェブもダイエットが必要 (スコア:0)
＞「クッキー」 (スコア:0)
捻くれ者 (スコア:0)
「詳細が明らかに」？ (スコア:0)
前回のストーリーのときに既に明らかになってたことばかりのようだけど？