2009/02/27(金)金曜日ー。（名古屋で猫に囲まれてます？(*^^*) ）
[セキュリティ] * 続:SQLのバインド機構は「エスケープ処理された値」をはめ込むのか
について思うところがあったので、久しぶりに技術ネタです♪
```概ねよいのだが、『ブラウザ上には、処理が失敗したことが分かる程度の簡単なエラーメッセージを表示』という部分がよくない。処理が『失敗した』ことが分かれば、攻撃に対するヒントになり、ブラインドSQLインジェクションに利用される場合もあるだろう。処理が失敗したのか、入力値検証ではじいたのかを含めて、もっと大雑把なメッセージにしたほうがよい。
```まず、ThinkIT の元記事に書かれている、エラーメッセージによって必要以上の情報を攻撃者に与えることが無いようにするという対策は、そのとおりだと思います。 次に、徳丸さんの “処理が失敗したのか、入力値検証ではじいたのかを含めて、もっと大雑把なメッセージにしたほうがよい” というお作法についても、私は大いに同意します。 ……ただ、その理由として、お二方ともブラインドSQLインジェクションを引き合いに出しているところが、「はて？」と思ってしまうのです。そもそも、ブラインドSQLインジェクションにエラーメッセージを利用することがありますでしょうか？ 通常、ブラインドSQLインジェクションと言えば、* こちらで星野君が解説している
ような、"正常な遷移"と"それ以外"との応答の違いだけでデータを取得する手法のことを指します。 もしかして、神戸デジタル・ラボさんでは、“* エラーメッセージを利用したデータの窃取
”**[pdf]** (8ページの(2)-ア) のことも含めてブラインドSQLインジェクションと呼んでいるのかも知れません。 それとも、エラーメッセージの中にSQL文が含まれているなどして、それが攻撃のヒントになるという、そういう次元の話をしているのかも知れません。 セキュリティ業界の中でも各所で方言がありますので、ここらへんは仕方の無いことなのかも知れませんね。ところで、この手法の場合、たとえ、“もっと大雑把なメッセージ” にしたところで、特に効果は見込めないような気がします。 なぜなら、正常な遷移をしたのか、そうでない応答なのかは、エラーメッセージの内容によらずとも一目瞭然だからです。 例えば、「productid=123」で、ある商品の情報が表示されるWebアプリの場合、「123」の代わりに、「123 and 1=2」を送信したら商品の情報は表示されないでしょう。 では、次に、「123 and 1=1」を送信したら？ ……この種の確認をいくつか行うだけで、処理が失敗したのか、入力値検証ではじかれたのかは攻撃者に理解されてしまいます。 そして、その応答の違いさえ分かれば、ブラインドSQLインジェクションの手法で攻撃を行うことが可能なのです。とは言え、明らかに “処理が『失敗した』” ことが分かるメッセージを表示してしまうと、攻撃者や攻撃者予備軍の興味を引いてしまいますし、検索エンジンなどを経由して余計な"お客さん"を呼び込んでしまう恐れもあります。 また、そもそも余計なメッセージがなければ、攻撃者が「ここにツールをかけてみよう！」と思わないかも知れないので、（根本的なSQLインジェクション対策を実施した上での、）保険的対策として、“もっと大雑把なメッセージ” にしておくことには賛成です。[雑談] いろいろ。
←まにあっく過ぎる!!ｗ
- こちらの徳丸さんのエントリ
について思うところがあったので、久しぶりに技術ネタです♪
textile(4)エラーメッセージ2ページ目。textileアプリケーションで作成したエラーメッセージを表示するのはよいが、エラーメッセージに必要以上の情報を表示したり、状態に応じてエラーメッセージの種類や表示内容を変えたりしてはいけない。攻撃者はそれらの情報を観察し、ブラインドSQLインジェクションを仕掛ける可能性があるからだ。ブラウザ上には、処理が失敗したことが分かる程度の簡単なエラーメッセージを表示し、詳しくはログファイルなどに出力し、ユーザーに見せないようにすべきである。
```概ねよいのだが、『ブラウザ上には、処理が失敗したことが分かる程度の簡単なエラーメッセージを表示』という部分がよくない。処理が『失敗した』ことが分かれば、攻撃に対するヒントになり、ブラインドSQLインジェクションに利用される場合もあるだろう。処理が失敗したのか、入力値検証ではじいたのかを含めて、もっと大雑把なメッセージにしたほうがよい。
```まず、ThinkIT の元記事に書かれている、エラーメッセージによって必要以上の情報を攻撃者に与えることが無いようにするという対策は、そのとおりだと思います。 次に、徳丸さんの “処理が失敗したのか、入力値検証ではじいたのかを含めて、もっと大雑把なメッセージにしたほうがよい” というお作法についても、私は大いに同意します。 ……ただ、その理由として、お二方ともブラインドSQLインジェクションを引き合いに出しているところが、「はて？」と思ってしまうのです。そもそも、ブラインドSQLインジェクションにエラーメッセージを利用することがありますでしょうか？ 通常、ブラインドSQLインジェクションと言えば、* こちらで星野君が解説している
ような、"正常な遷移"と"それ以外"との応答の違いだけでデータを取得する手法のことを指します。 もしかして、神戸デジタル・ラボさんでは、“* エラーメッセージを利用したデータの窃取
”**[pdf]** (8ページの(2)-ア) のことも含めてブラインドSQLインジェクションと呼んでいるのかも知れません。 それとも、エラーメッセージの中にSQL文が含まれているなどして、それが攻撃のヒントになるという、そういう次元の話をしているのかも知れません。 セキュリティ業界の中でも各所で方言がありますので、ここらへんは仕方の無いことなのかも知れませんね。ところで、この手法の場合、たとえ、“もっと大雑把なメッセージ” にしたところで、特に効果は見込めないような気がします。 なぜなら、正常な遷移をしたのか、そうでない応答なのかは、エラーメッセージの内容によらずとも一目瞭然だからです。 例えば、「productid=123」で、ある商品の情報が表示されるWebアプリの場合、「123」の代わりに、「123 and 1=2」を送信したら商品の情報は表示されないでしょう。 では、次に、「123 and 1=1」を送信したら？ ……この種の確認をいくつか行うだけで、処理が失敗したのか、入力値検証ではじかれたのかは攻撃者に理解されてしまいます。 そして、その応答の違いさえ分かれば、ブラインドSQLインジェクションの手法で攻撃を行うことが可能なのです。とは言え、明らかに “処理が『失敗した』” ことが分かるメッセージを表示してしまうと、攻撃者や攻撃者予備軍の興味を引いてしまいますし、検索エンジンなどを経由して余計な"お客さん"を呼び込んでしまう恐れもあります。 また、そもそも余計なメッセージがなければ、攻撃者が「ここにツールをかけてみよう！」と思わないかも知れないので、（根本的なSQLインジェクション対策を実施した上での、）保険的対策として、“もっと大雑把なメッセージ” にしておくことには賛成です。[雑談] いろいろ。
- 相乗りするケースも：詐欺サイトの7割強が攻撃されたコンピュータに存在 (ITmedia)
- ［これはひどい］IEの引用符の解釈 (＠IT)
←まにあっく過ぎる!!ｗ
- Gmail障害に便乗の悪質サイト、「gmail down」で検索するとトップに (ITpro)
- 3分LifeHacking：Gmailが落ちたときに“アクセス”する方法を考える (ITmedia)
- Apache Tomcatにパスワードなどの機密情報を奪取される脆弱性 (CNET)
- 不正アクセスはネットオークションが最多--国家公安委員会まとめ (CNET)
- 辞めた会社のＨＰ消す 男を逮捕 (MSN産経ニュース)
- IT人材「量は十分、質が足りない」―IPA調査 (＠IT)
- ネットに出回る偽の求人広告にご用心 (ITmedia)
- カード・暗証番号…分担して入手、歌舞伎町に昏睡強盗組織 (読売新聞)
- 「派遣切りに」話し好き強盗、女子大生宅１時間…被害２万円 (読売新聞)
- 魔王？ 倒しちゃって、みたいな。「あたし勇者。」みたいな (ITmedia)
- 宇宙船が壊れてしまって帰れなくなった人がパーツを募集中 (GIGAZINE)
- これが米第七艦隊の実力！ 不沈空母「やまと」で極東の戦力は十分 (bogusnews)
- 多分ナシだと思う、プロポーズ用iPhoneアプリ (GIZMODO)
- レジなのに電卓で代金を見せられる理由って？ (ExciteBit)
- “ヘソクリ”が23万1000円も多いのは……夫？ それとも妻？ (BIZ誠)
- 女性美容師との会話が地雷原のようなものである件 (Kousyoublog)
- メルアド使い分け、女性の3割弱が単なる「知人」に無料メールアドレス使用 (MYCOM)
- 【働く女子の実態】働く女子500人に聞いた「私たちの結婚観」 (escala cafe)