SQLインジェクション対策に正解はない

最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ

[cubed-l]

ご自身が書かれているとおり、バインド機構を使えない、あるいは他の要件を優先するために使わない箇所だけエスケープを使う、が正解でしょ

[tmatsuu]

柔軟な検索についてはWHERE (? OR 検索条件1) AND (? OR 検索条件2) AND…として?にTRUEかFALSEを設定すれば組み合わせ爆発にならんけどね。もちろん限界があるのは百も承知。

[ghostbass]

Linqで解決。あるいは同等のクエリービルダーを実装する。そんなに難しいことじゃない。

[kmaebashi]

組み合わせ爆発が起きるようなwhereを組み立てる場合、SQLを組み立てるよりは、「プリペアドステートメントの元になる文字列を動的に組み立てる」方がはるかに安全だと思う。文字列連結する以上絶対ではないにせよ。

[Caligari]

“[{"key1":"val1"},{"key2":"val2"},...]という配列をリクエストで受け取り、WHERE key1 = ? AND key2 = ? ...というようなSQLへ変換してしまうとどうなるだろうか”どうなるの？

[tyru]

いくつか追加条件を指定できる検索画面では組み立てていくしかないって話／ライブラリ(O/Rマッパー)での対処例としてはこういうのがいいと思う http://doma.seasar.org/reference/sqlfile.html#条件コメント

[kanno_kanno]

“SQLインジェクションについても同様にテストが重要”

[te2u]

この手の話題に「正解」「間違い」を安易に持ち込むのはどうかと思う。それぞれの利点・欠点をおさえて、対象の環境を鑑みて一つ一つ判断するしかない。あとはその環境の範囲内でルール化して、手法の分散を防ぐ。

[nemoba]

ORMでクエリーが自由に飛ぶ時代だし、全てのクエリー検証は確かに理想だけど、実装設計の段階で優先順位や利用方針を決めておかないと、フリーダムに混在してテストが困難になって諦められてしまうよー

[akio0911]

漢(オトコ)のコンピュータ道: SQLインジェクション対策に正解はない

[akasata]

ふむふむ

[terazzo]

そうか、SQLインジェクションがない事を証明出来ればいいのか＞テストせよ

[k-holy]

これはいいまとめ。どのような場合に使えないかを知らない人が多い印象

[uunfo]

ついにまとまるか？

[t-wada]

バランスの取れた意見だと思う

[atsushifx]

どこかでブックマークしたけどSQLというプログラミング言語を誰かの入力を元に組み立てる必要がある時点で完全なセキュリティは無理だと思う。ホワイトリスト／ブラックリストや全文検索エンジンも組み合わせるべき

[m_shige1979]

SQLインジェクションは結構複雑だけど、穴を見つける方法って何があるんだろう。複雑なパターンの網羅がしにくい。権限などで抑制するけど

[muchonov]

そーそー、まさにそれで悩んでた＞「入力した条件だけが使われる検索」／わたくしも「foreach + case〜switchで個別のPOST値があるかどうかを判定しながらprepared statementの断片を積んでゆく」路線に落ち着きました。

[girled]

臨機応変に使い分けるってことになるよなあ。実装の話だけでなく保守、メンテ性とかも含めて考えるとなおさら。

[jt_noSke]

"どのようにすればSQLインジェクションを防げるかという要件さえ満たしていればそれで良いのではないだろうか。"フムー