-
- いいね！16
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
@kazuho セキュアなコードを書けるようになる教育と、実際の現場での優先順位は順序が違います。実務ではあまり良く解って無くてもより簡単に安全に書ける方を優先しますが、セキュリティ教育としては優先順位を変えざるを得ません。
2013-12-09 18:28:07
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho JSX使っていても、JavaScriptの基本くらいは知っておいてね、という感じかな？
2013-12-09 18:30:06
Kazuho Oku
@kazuho
.@yohgaki その点は同意できません。例外的な場合の処理に触れるのも必要ですが、教育においても「確実に安全に書ける」方法を推奨すべきです。安全なエスケープ関数を自分で実装しろとか、教育してどうこうなる問題ではありません
2013-12-09 18:38:02
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho 電卓使ってもよいけど、掛け算は暗記してね。と同じですよ。教育と実務では違う場合がよくあります。別に珍しい事ではありません。
2013-12-09 18:44:14
Yasuo Ohgaki (大垣靖男)
@yohgaki
プリペアードクエリはたかがAPIです。しかも、セキュリティ対策として欠陥があるAPIです。なぜ欠陥APIを一番に教えるべき！と拘るのか理解できません。欠陥APIでないこと、セキュリティ教育として合理的であることを論理的に説明して教えていただける方が居たらお聞きします！
2013-12-09 19:42:47
Kazuho Oku
@kazuho
.@yohgaki いい質問だと思います。プリペアードクエリを優先すべきなのは、正しいコードの書き方が一定に定まるからです（エスケープの場合は、エスケープした位置とクエリを発行する位置が分かれる等の可能性がある）。これにより、可読性と検証性が向上します。（続く）
2013-12-10 13:11:05
Kazuho Oku
@kazuho
.@kazuho @yohgaki （続き）さらに安全性や検証可能性を高めるにあたっては、プリペアードステートメントの一種として、SQLをソースコード以外のファイルに記述するという手法もあります。たとえば S2Dao がそうですね
2013-12-10 13:12:25
Yasuo Ohgaki (大垣靖男)
@yohgaki
昨日、ツイッターでセキュリティ対策としてのセキュリティ教育をなかなか理解してもらえなかったので書きました。勿論ですが既にセキュリティ対策の基本を知っている前提なら実務ではAPIファーストで良いです。 http://t.co/ZQTZqaOmgy
2013-12-10 13:14:14
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho 多分セキュリティ教育の方法論として論じている、という点を見落とされているのだと思います。 http://t.co/Gv9vLm0VrX まとめて書くとこういう事です。実務でAPIファーストは当然だと思っています。実務では筆算より電卓／エクセルです。
2013-12-10 15:09:34
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho まあ、気持ちは分からないことは無いのですがMSとかはエスケープ関数を無くしたので、大量のレガシーコードを持っている会社は「自作エスケープ関数」です。どうしてこうなった？という感想です。
2013-12-10 18:16:53
Kazuho Oku
@kazuho
.@yohgaki えぇ。SQLを動的に組み立てるケースもあるので、エスケープAPIはあるべきです。そこは異論ないです。エスケープAPIがないならコード量が増えてもプレースホルダを使うべきだと思いますが、既存コードをそのように改変するのは手間がかかるでしょうね
2013-12-10 18:19:53
Yasuo Ohgaki (大垣靖男)
@yohgaki
あとOracleとかは自作（サイトに載ってるから公式か？）エスケープ関数が載ってたりしるなあ。SQLite3もエスケープ関数が無いから、DB抽象化レイヤーが自作している。
2013-12-10 18:20:53
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho 移行時に書き換えの工数まで取れるリッチな会社ばかりではないのですからね。。書き換えたら大幅工数アップです。
2013-12-10 18:22:50
Kazuho Oku
@kazuho
.@yohgaki SQLite3 にエスケープ関数がなくても問題にならないのは、文字コードが Unicode のみに限定されているからでは？ 複数の文字コードに対応するエスケープ関数を書く必要がある場合と同列に扱うべきではないと重い舞うs
2013-12-10 18:26:42
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho PHPのバグレポートには”SQLite3でquoteメソッド使ったらデータが壊れる！" バイナリデータをPDOが自作しているquoteメソッド通してました。Not a bug なんてのもありました。出力見れば分かるのですが。。。
2013-12-10 18:27:35
Kazuho Oku
@kazuho
.@yohgaki そういうことが起こるからこそ、エスケープ関数の使用をユーザーに推奨してはいけないんですよ。エスケープについて基礎的な理解があるべきなのはもちろんですが
2013-12-10 18:30:24
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho DB抽象化レイヤーはメソッド作らない訳にいかないですから。。で、プロでも「動かない＝バグだ、レポートだ」となって他人の時間を消費したり。識別子エスケープが無い物もあったり。エスケープは基礎知識として知っておいて損は無いのでプロの常識として知っていてほしい。
2013-12-10 18:42:10
Yasuo Ohgaki (大垣靖男)
@yohgaki
@kazuho Oracleのストアドプロシージャの解説ページとかは意図的なのかquotenameというエスケープ関数が多用してあったりします。多分、エスケープしないでインジェクションに脆弱になったケースが多かったのでは？と推測しています。
2013-12-10 18:44:09