「Web制作者の常識、開発エンジニアの常識」記事へのコメント

SQLインジェクション周知の徹底も重要ですが

[esumi (15966)]

それに加えてはなからSQLインジェクション実行が不可能な
フレームワークの構築とその使用の徹底もより重要と考えます。

＃例えば.NETが提供するフレームワークの内データベース処理を担当するADO.NETは
＃SQLインジェクションが構造的に不可能なように構築されてたと思います

Re:SQLインジェクション周知の徹底も重要ですが

[Anonymous Coward]

えっと、SQLインジェクションが不可能な構造ってことは
生SQLが発行できないってことですかね。

#つまり、うちで納品しているプログラムで
#生SQLをばしばし発行してるのも幻ですよっと。

Re:SQLインジェクション周知の徹底も重要ですが

[esumi (15966)]

ｽﾝﾏｾﾝ不可能ってのは言い過ぎでした。
ご指摘の通り、SQLCommand関連のクラスとかを直接叩けば生コードはいくらでも叩けます。

が、ADO.NETで推奨されているように、
発行されたフォームから持ってくる更新当、値の代入には”パラメータ”技術を介するように
徹底するとかでも潜在する危険度はぐっと減る事でしょう。言いたいのはそーゆーことです。
（開発環境で用意されているウィザードを使うと勝手にその辺はやってくれますが
まあ実際は自動生成されたコードいじったりおおむねSQLCommandとかを直接操作するの
ですしね）

＃実際にはもっと突き詰めて内部的にそのような処理を行うラッパークラスを
＃独自のフレームワーク上で用意し、Web開発者にはそのフレームワークで用意
＃したメソッドを使うよう徹底するというのがいいのではないかという事です。
＃そうするとSQLインジェクションへの注意をフレームワーク開発上に集中でき
＃末端のWeb開発者含めた全員に周知徹底コードの厳密な監視を随時行うという
＃あまり現実的でなさそうな工数をある程度削減できるのではないかと。

Re:SQLインジェクション周知の徹底も重要ですが

[TarZ (28055)]

> 値の代入には”パラメータ”技術を介するように
> 徹底するとかでも潜在する危険度はぐっと減る事でしょう

プログラマが意識してそれを選択しなければならないとしたら、「きちんとエスケープすることを徹底すればよい」
というのとあまり変わらないと思いますよ。

パラメタライズドクエリ（変数バインド）自体は大昔からあるわけで。それがきちんと使われないから脆弱性が
減らないのですから。

Re:SQLインジェクション周知の徹底も重要ですが

[quabbin (17251)]

いろいろ書かれているけど、一言で言うとPrepareサイコーって話でしょうか？

私の手元では(Javaなので)PreparedStatementと静的解析ツールのFindbugs [sourceforge.net]を組み合わせて、多分おっしゃっているようなことを実現してはいるとは思いますが…。
.NET環境では、そういうものって無いのでしょうか？

Re:SQLインジェクション周知の徹底も重要ですが

[Stealth (5277)]

単純に Prepare サイコーってだけなら、#985433 [srad.jp] で書かれている SqlCommand クラスが普通に Prepare 持ってます。

#985433 は、それをさらに業務的に利用しやすい .NET Framework 上のフレームワークを作ろうって話では?

Re:SQLインジェクション周知の徹底も重要ですが

[quabbin (17251)]

最初はそうかとも思ったのですが、既存線に対する「どこ」が不満というのが見えてこなかったので…
せいぜい見つかったのは、SQLCommandオブジェクトを作るときに、生成もとのStringがfinalというかConst宣言したString型変数が渡されたかどうかを検出させる方法がない…と言っている程度に見えたから、「それなら静的解析ツールに頼ったほうがいいんでない？」と思ったのですが、どうでしょう。

# .NET環境用のものもいくつかあるようですね。
# 有料ですけが…。