10
ログインして広告を非表示にする
  • ROCA @rocaz 2013-12-09 16:34:06
    SQLインジェクション対策に限ればプリペアドステートメントはそれだけで十分究極のSQL文対策だよ。だって@yohgaki 氏の主張では「SQL文全体に影響が出るからこそのエスケープ処理」だよね。プリペアド前提で「SQLインジェクション対策のために」エスケープが必要な例ってあるの?
  • ROCA @rocaz 2013-12-09 16:40:36
    これ http://t.co/1uIaqo82td は読んだ。「検索仕様上様々なSQLパターンが必要な場合プリペアドだけではパターンが多すぎることもある」はその通り。但し常にそうでは無いし汎的に「エスケープの絶対的必然性」を主張するには弱すぎる @yohgaki
  • ROCA @rocaz 2013-12-09 16:45:46
    そもそもRDB特にOracleでの静的SQLと動的SQLの歴史について学んだ方がいいのでは。そもそも動的SQLはRDBとしては正統では無く、当初大量に当然のように利用されたのはWEB出現が生み出した一時的な鬼っ子に過ぎない @yohgaki
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 16:48:57
    @rocaz 絶対にエスケープを使えと言っているのでは無いですよ。エスケープでなければならない場合もあるし、API実装が「正確」であるか判断する為には正確なテキスト処理の知識が必要です。それにSQLインジェクション対策には識別子のエスケープとかは必須でしょ?という話です。
  • ROCA @rocaz 2013-12-09 16:54:07
    @yohgaki では「プリペアドステートメントを第一位に推奨しない理由」は何ですか?
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 16:55:18
    @rocaz プリペアードクエリの欠点はブログに書いた通りです。セキュリティ対策は完璧を求める物ではありませんが、処理を完璧にできるなら、全ての「穴」を塞ぐ対策や注意事項の知識は必要です。プレイスホルダさえ使えばOK!という考え方が脆弱であるのは事実です。
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 16:57:13
    @rocaz RDBに限らず全ての出力先に利用できる対策だからであること、エスケープを利用したAPIが「正確」であること、を検証できるからです。フレームワーク、ライブラリの実装が正確であるか確認することはセキュリティのベストプラクティスの1つですから。
  • ROCA @rocaz 2013-12-09 16:59:43
    @yohgaki それが「プリペアドを否定する理由」にはなり得ないでしょう。プリペアドにはSQLインジェクションを抑制する効果は無いとお考えですか。ブログなどで書かれている例は「多くの場合開発者が遭遇しない例」です
  • ROCA @rocaz 2013-12-09 17:02:36
    @yohgaki 最初に書いたとおりここでは「SQLインジェクション」について議論しているつもりです。またことSQLインジェクション対策においてはエスケープ以外の対策ではAPIは関係ないです。SQLインジェクション対策と例えばXSS対策を同じに見なすのは危険でしょう
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:03:03
    @rocaz http://t.co/sMHUsU7nt3 を見れば分かりますが、「正確なテキスト管理」は結構難しかったりします。私もSJIS+非マルチバイト文字関数の件を使ってないので失念していました。APIを使えばOK、だけではダメで制限事項・条件などの知識も必要ですね。
  • ROCA @rocaz 2013-12-09 17:05:03
    @yohgaki 違いますよ。それはエスケープしたいから問題になるだけで、他の方法を用いていてエスケープしないなら何のリスクにもなりません
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:05:39
    @rocaz 出力のセキュリティ対策は出力先に限らず同じ原則が利用可能です。セキュリティ対策はできるだけシンプルである方が良い。出力先のセキュリティ対策三原則は全ての出力先に適用できます。Webセキュリティ対策 ≠ SQLインジェクション対策ですよ。
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:07:14
    @rocaz 他の方法を用いて?言語の文字リテラルをどうやってエスケープ処理しないで安全に出力するのですか?
  • ROCA @rocaz 2013-12-09 17:10:57
    @yohgaki シンプルでよいのはその具体的な対策方法の内容に関しては、です。異なる脆弱性に関しては別々に対策は想定されることが望ましい。これは当たり前ですよね。で最初の質問に戻りますが、であるならSQLインジェクションの第一位の対策はプリペアドであるべきでは?
  • ROCA @rocaz 2013-12-09 17:12:44
    @yohgaki ここでは「SQLインジェクション対策としてプリペアドステートメントで対策することを想定しています。安全に出力できますよね
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:18:32
    @rocaz プリペアードクエリには欠陥があるのでセキュリティ対策”教育”の第一番にはなりません。識別子、SQL語句の分離ができない。仕組みとして変数埋め込みを禁止できない。この欠陥はどうしようもないです。
  • ROCA @rocaz 2013-12-09 17:26:22
    @yohgaki それは単なる「レアケース」です。数十程度のプリペアドSQLを用意することも別に問題にはなりませんよ。それよりも、先ほどあなたも間違えたように「SQLインジェクションのためのエスケープ処理の複雑さ」の方が欠陥でしょう。シンプルな方がいいのでしたよね
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:32:39
    @rocaz 多分、色んな言語のソースコード検査を100本くらいすれば理解できると思います。「プリペアードクエリを使えばOK」と教える事の害を。Webアプリセキュリティ対策”教育”の基本は「正確なテキスト管理」です。
  • ROCA @rocaz 2013-12-09 17:36:02
    @yohgaki 自分の世界に逃げ込まず、具体的に議論しませんか。 「SQLインジェクションのためのエスケープ処理の複雑さ」の方が欠陥でしょう。シンプルな方がいいのでしたよね。そう思いませんか
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:38:04
    @rocaz セキュリティ対策はできるだけ漏れ無く行う必要があります。エスケープ処理、正確なテキスト処理をセキュリティ対策の基礎知識として知っておく事、教育する事が難しいことでしょうか?
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:39:12
    @rocaz プリペアードクエリの欠陥をどうするのかお答え下さい。なにか妙案はありますか?
  • ROCA @rocaz 2013-12-09 17:41:18
    @yohgaki 何度も書いていますが「SQLインジェクションでの対策」として話して下さい。あなたが先ほど間違えて指摘されブログに追記したほどには難しいのでは?プリペアドはそれより何が難しいですか?
  • Yasuo Ohgaki (大垣靖男) @yohgaki 2013-12-09 17:44:34
    @rocaz プリペアードクエリの欠陥を無くし「プリペアードクエリさえ使えばOK」と教えても安全、という根拠になっていません。なぜ不完全な対策にこだわるのでしょうか?それとも欠陥対策の名案ありますか?
  • ROCA @rocaz 2013-12-09 17:48:34
    @yohgaki 欠陥を無くしとワークアラウンドは異なりますよ。欠陥はエスケープでも無くならないでしょう。こういう対策の何が問題になりますか? またこの対応の前提で「「プリペアードクエリさえ使えばOK」と教えても安全」と「ならない」という根拠は何ですか

コメント

  • 狭川 雀 @SagawaSuzume 2013-12-09 23:43:44
    「プリペアードステートメントを文字列結合で変な変数ぶちこんで作れるから危険」という指摘の対義は「エスケープ処理では文字の想定漏れや不適切な置換が発生しうるから危険」だろうかね。結局のところ「どんな方法であれ使い方が間違ってればどうしようもない」だし、逆に話題に出てるような方法は「適切に使えばどれでもOK」なんだが。
  • とげとげ @togetoge10 2013-12-10 00:25:11
    え…。そんなオチだったんですかー!!
  • Masahiro Hayashi @mhayashi1120 2013-12-10 01:32:37
    SQL に変数埋め込めることを知らないってことね。たぶん。
  • ROCA @rocaz 2013-12-10 06:43:19
    彼の主張の原因について考察をまとめてみました http://blog.rocaz.net/2013/12/1660.html
  • narusase @narusase 2013-12-11 01:43:11
    実務上、自分も @yohgaki の言うような酷いSQLを見ることは多々あるので、教育が必要という点については賛同。しかし、教えるべきはSQLインジェクションの基本原理と、どのようなコードで起こるか、どうすれば容易に起こらないように出来るか(正しくプリペアードステートメントつかえ、SQLの組み立てに外部の信用できない値を直接使うな)では?
  • narusase @narusase 2013-12-11 01:51:24
    プリペアードステートメントはたしかに使ってる・・・ だけど、SQLの組み立てで外部から渡される値を使ってるって糞なコードは普通に見る。最近見た酷いのだと、$tablenameがPOSTパラメータから渡された引数で、「'SELECT * FROM '.$tablename.'WHERE hoge = ?'」 みたいなのもごろごろと・・・ 糞なコードに限ってコピペ運用で増殖して酷いことになるんだよな・・・orz
  • chao2suke @chao2suke 2014-02-25 18:36:50
    プリペアードステートメントに変数でテーブル名とかSQL文とかを入れちゃうようなコードを書く人に 「入れちゃダメ」と教えるか 「エスケープしなさい」と教えるかって、もう好みのような気がするけど。

カテゴリーからまとめを探す

「メモ」に関連するカテゴリー