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

11
前へ 1 2 ・・ 5 次へ
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz ソースコード検査を何本もやった結果から「プリペアードクエリさえ使えば安全」は間違いの元である、という結論に達しました。SQLインジェクションなんて完璧に防げる脆弱性が未だに無くならないのは、プリペアードクエリを使ってない、からではありません。

2013-12-09 17:51:27
ROCA @rocaz

@yohgaki その具体性が全く無い、エンジニアとしては理解不能な主張では誰一人納得しませんし、あなたの生徒さん?も不信しか抱かないのでは(エビデンスの無い主張はエンジニアは怪しむだけ)

2013-12-09 17:54:29
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz ソースコードの脆弱性検査の結果が具体的でないと言われるならそれ以上の具体例は無理では?プリペアードクエリの欠陥を無くす方法論をお待ちしているのですが、ありますか?

2013-12-09 17:56:52
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz まず、SQL文への変数埋め込みをどうやって防ぐのですか?

2013-12-09 17:57:48
ROCA @rocaz

@yohgaki 二度も書いたとおりですが理解頂いてないのでしょうか。多パターンの検索・ソート条件のため動的SQLが必要になるなら多パターンに沿った静的SQLをコード上用意して条件により使い分ければいいだけです。これはセキュリティ対策では無く仕様の問題です。これは理解できますか?

2013-12-09 18:13:32
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz 質問を誤解されているのですね。パラメータ、識別子、SQL語句の埋め込みが禁止できない不完全性を問題視しています。実際にある脆弱性です。これを防ぐにはどうすべきでしょうか?教育方法でも構いません。

2013-12-09 18:17:09
ROCA @rocaz

@yohgaki 譲歩・看破して想像しますが、100件コード検査して行き着いたとのことですが、それは恐らくエスケープ不備が脆弱性を招いていたと言うことなのでは。であればそれは対策としてのエスケープの限界なのでは。他の方法論が必要と言うことですよね。決して教育の問題ではありません

2013-12-09 18:17:30
ROCA @rocaz

@yohgaki 誤解していませんよ。単純に「するな」というだけです。静的SQLの不完全性などといった問題ではありません。それで何か問題が出ますか?

2013-12-09 18:20:17
Kazuho Oku @kazuho

ですよね。基本プリペアードクエリで良いということ > 「エスケープ処理を省略できるAPIが用意されている場合が〜これらのAPIの利用を推奨して構わない〜その良い例がプリペアードクエリ」 / “IPAの「安全なSQLの呼び出し方」が…” http://t.co/tWIraJ0p1T

2013-12-09 18:21:26
Kazuho Oku @kazuho

「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」なら誰も異論はないんじゃないの

2013-12-09 18:22:38
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz またブログに挙げた欠陥にもどってしまいますよ。使えない場合があるのですから、セキュリティ対策”教育”として教えないと教育の瑕疵では?

2013-12-09 18:24:11
ROCA @rocaz

@yohgaki 先ほども言いましたが「使えない場合」があるだけのレアケースでしょう。それに私が既にワークアラウンドは提示しました。瑕疵になんてなりませんよ ・・・理解されていないのでは?

2013-12-09 18:27:12
Kazuho Oku @kazuho

.@yohgaki その点は同意できません。例外的な場合の処理に触れるのも必要ですが、教育においても「確実に安全に書ける」方法を推奨すべきです。安全なエスケープ関数を自分で実装しろとか、教育してどうこうなる問題ではありません

2013-12-09 18:38:02
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz アプリセキュリティ対策の根本的な対策は”教育”です。私は教育の為に本を書いているのですが、レアケースだから脆弱になってもOKだから無視します、と書いて読者は納得するでしょうか?禁止すればOKという事ですが、ではどういう理由で禁止するのでしょうか?

2013-12-09 18:42:29
ROCA @rocaz

.@yohgaki @kazuho 少なくとも積極的には言ってないでしょ。「プリペアドクエリは欠陥があるから教えられない・勧められない」と言ってたでは無いですか

2013-12-09 18:43:39
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz @kazuho 薦められない?そんな事は言っていないはずですが、言っていたなら間違いです。制限事項や条件なども教えないと、とは言っています。それに出力セキュリティ対策の三原則はAPIを使うが2番目です。

2013-12-09 18:46:35
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz @kazuho そういう考えではないです。ブログにも実務でAPIを使うを一番の優先順位にするのは構わない、と書いていますよ。

2013-12-09 18:49:26
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz @kazuho 基礎から教えない教育はないでしょ?四則演算を教える前に電卓を教える教育はあり得ないことと同じです。@rocaz さん、私の主張をよく理解されていないようなので関連ブログエントリを見て頂けますか?分からない所、異論がある所はお答えします。

2013-12-09 18:53:41
ROCA @rocaz

@yohgaki 僕はいつから教育の話をしていましたか?それ以前にまず方法論でしょう。教え方なんてそれから考えれば宜しい。 ここでの答えは「静的SQLを使え」です。レアケースと書いているのはワークアラウンドが解決します。何度もお聞きしますがこれで何の問題がありますか

2013-12-09 18:54:13
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz @kazuho 1つ書くべき事を書いておきます。テキストを正確に管理しないとインジェクションできる、はプログラミングを始めたばかりの人には「非常識」です。プリペアードクエリさえ使えばOK、はセキュリティ対策教育的に解決策になっていません。

2013-12-09 18:56:32
ROCA @rocaz

@yohgaki http://t.co/oAR59H8XnB 「セキュリティを維持するための重要度は「エスケープ > API > バリデーション」であることは変わりません」もしやAPIとはプリペアドのことですか

2013-12-09 18:56:53
ROCA @rocaz

@yohgaki 意味が分かりません。僕は最初から「SQLインジェクション対策」において「セキュリティを維持するための重要度は「エスケープ > API > バリデーション」であることは変わりません」に異議を唱えているだけですよ

2013-12-09 18:59:20
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz プリペアードクエリもAPIの1つに入れています。厳密にはエスケープAPIもAPIですけどね。

2013-12-09 19:07:55
Yasuo Ohgaki (大垣靖男) @yohgaki

@rocaz アプリセキュリティ対策の根本的な対策は「開発者が脆弱なコードを書かないようにする教育」です。私が議論しているのも方法論です。プリペアードクエリさえ使えばOK、というのは電卓さえ使えればOK、という教育と同じです。

2013-12-09 19:11:18
ROCA @rocaz

@yohgaki なのでしょうね。ではここで言ってますね https://t.co/tNqKxIE3Xs 前段で条件付けていると言われるかも知れませんが、前段は何のことか分からないですね。

2013-12-09 19:12:18
前へ 1 2 ・・ 5 次へ