SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論

ROCA @rocaz

SQLインジェクション対策に限ればプリペアドステートメントはそれだけで十分究極のSQL文対策だよ。だって@yohgaki 氏の主張では「SQL文全体に影響が出るからこそのエスケープ処理」だよね。プリペアド前提で「SQLインジェクション対策のために」エスケープが必要な例ってあるの？

ROCA @rocaz

これ http://t.co/1uIaqo82td は読んだ。「検索仕様上様々なSQLパターンが必要な場合プリペアドだけではパターンが多すぎることもある」はその通り。但し常にそうでは無いし汎的に「エスケープの絶対的必然性」を主張するには弱すぎる @yohgaki

ROCA @rocaz

そもそもRDB特にOracleでの静的SQLと動的SQLの歴史について学んだ方がいいのでは。そもそも動的SQLはRDBとしては正統では無く、当初大量に当然のように利用されたのはWEB出現が生み出した一時的な鬼っ子に過ぎない @yohgaki

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz 絶対にエスケープを使えと言っているのでは無いですよ。エスケープでなければならない場合もあるし、API実装が「正確」であるか判断する為には正確なテキスト処理の知識が必要です。それにSQLインジェクション対策には識別子のエスケープとかは必須でしょ？という話です。

ROCA @rocaz

@yohgaki では「プリペアドステートメントを第一位に推奨しない理由」は何ですか？

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz プリペアードクエリの欠点はブログに書いた通りです。セキュリティ対策は完璧を求める物ではありませんが、処理を完璧にできるなら、全ての「穴」を塞ぐ対策や注意事項の知識は必要です。プレイスホルダさえ使えばOK！という考え方が脆弱であるのは事実です。

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz RDBに限らず全ての出力先に利用できる対策だからであること、エスケープを利用したAPIが「正確」であること、を検証できるからです。フレームワーク、ライブラリの実装が正確であるか確認することはセキュリティのベストプラクティスの1つですから。

ROCA @rocaz

@yohgaki それが「プリペアドを否定する理由」にはなり得ないでしょう。プリペアドにはSQLインジェクションを抑制する効果は無いとお考えですか。ブログなどで書かれている例は「多くの場合開発者が遭遇しない例」です

ROCA @rocaz

@yohgaki 最初に書いたとおりここでは「SQLインジェクション」について議論しているつもりです。またことSQLインジェクション対策においてはエスケープ以外の対策ではAPIは関係ないです。SQLインジェクション対策と例えばXSS対策を同じに見なすのは危険でしょう

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz http://t.co/sMHUsU7nt3 を見れば分かりますが、「正確なテキスト管理」は結構難しかったりします。私もSJIS＋非マルチバイト文字関数の件を使ってないので失念していました。APIを使えばOK、だけではダメで制限事項・条件などの知識も必要ですね。

ROCA @rocaz

@yohgaki 違いますよ。それはエスケープしたいから問題になるだけで、他の方法を用いていてエスケープしないなら何のリスクにもなりません

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz 出力のセキュリティ対策は出力先に限らず同じ原則が利用可能です。セキュリティ対策はできるだけシンプルである方が良い。出力先のセキュリティ対策三原則は全ての出力先に適用できます。Webセキュリティ対策 ≠ SQLインジェクション対策ですよ。

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz 他の方法を用いて？言語の文字リテラルをどうやってエスケープ処理しないで安全に出力するのですか？

ROCA @rocaz

@yohgaki シンプルでよいのはその具体的な対策方法の内容に関しては、です。異なる脆弱性に関しては別々に対策は想定されることが望ましい。これは当たり前ですよね。で最初の質問に戻りますが、であるならSQLインジェクションの第一位の対策はプリペアドであるべきでは？

ROCA @rocaz

@yohgaki ここでは「SQLインジェクション対策としてプリペアドステートメントで対策することを想定しています。安全に出力できますよね

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz プリペアードクエリには欠陥があるのでセキュリティ対策”教育”の第一番にはなりません。識別子、SQL語句の分離ができない。仕組みとして変数埋め込みを禁止できない。この欠陥はどうしようもないです。

ROCA @rocaz

@yohgaki それは単なる「レアケース」です。数十程度のプリペアドSQLを用意することも別に問題にはなりませんよ。それよりも、先ほどあなたも間違えたように「SQLインジェクションのためのエスケープ処理の複雑さ」の方が欠陥でしょう。シンプルな方がいいのでしたよね

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz 多分、色んな言語のソースコード検査を100本くらいすれば理解できると思います。「プリペアードクエリを使えばOK」と教える事の害を。Webアプリセキュリティ対策”教育”の基本は「正確なテキスト管理」です。

ROCA @rocaz

@yohgaki 自分の世界に逃げ込まず、具体的に議論しませんか。 「SQLインジェクションのためのエスケープ処理の複雑さ」の方が欠陥でしょう。シンプルな方がいいのでしたよね。そう思いませんか

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz セキュリティ対策はできるだけ漏れ無く行う必要があります。エスケープ処理、正確なテキスト処理をセキュリティ対策の基礎知識として知っておく事、教育する事が難しいことでしょうか？

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz プリペアードクエリの欠陥をどうするのかお答え下さい。なにか妙案はありますか？

ROCA @rocaz

@yohgaki 何度も書いていますが「SQLインジェクションでの対策」として話して下さい。あなたが先ほど間違えて指摘されブログに追記したほどには難しいのでは？プリペアドはそれより何が難しいですか？

ROCA @rocaz

@yohgaki 先ほど書きましたよ https://t.co/V8GU7qgH8G

Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz プリペアードクエリの欠陥を無くし「プリペアードクエリさえ使えばOK」と教えても安全、という根拠になっていません。なぜ不完全な対策にこだわるのでしょうか？それとも欠陥対策の名案ありますか？

ROCA @rocaz

@yohgaki 欠陥を無くしとワークアラウンドは異なりますよ。欠陥はエスケープでも無くならないでしょう。こういう対策の何が問題になりますか？ またこの対応の前提で「「プリペアードクエリさえ使えばOK」と教えても安全」と「ならない」という根拠は何ですか