アカウント名:
パスワード:
単純に Prepare サイコーってだけなら、#985433 [srad.jp] で書かれている SqlCommand クラスが普通に Prepare 持ってます。
#985433 は、それをさらに業務的に利用しやすい .NET Framework 上のフレームワークを作ろうって話では?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
SQLインジェクション周知の徹底も重要ですが (スコア:2, 興味深い)
フレームワークの構築とその使用の徹底もより重要と考えます。
#例えば.NETが提供するフレームワークの内データベース処理を担当するADO.NETは
#SQLインジェクションが構造的に不可能なように構築されてたと思います
Re:SQLインジェクション周知の徹底も重要ですが (スコア:0)
生SQLが発行できないってことですかね。
#つまり、うちで納品しているプログラムで
#生SQLをばしばし発行してるのも幻ですよっと。
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
ご指摘の通り、SQLCommand関連のクラスとかを直接叩けば生コードはいくらでも叩けます。
が、ADO.NETで推奨されているように、
発行されたフォームから持ってくる更新当、値の代入には”パラメータ”技術を介するように
徹底するとかでも潜在する危険度はぐっと減る事でしょう。言いたいのはそーゆーことです。
(開発環境で用意されているウィザードを使うと勝手にその辺はやってくれますが
まあ実際は自動生成されたコードいじったりおおむねSQLCommandとかを直接操作するの
ですしね)
#実際にはもっと突き詰めて内部的にそのような処理を行うラッパークラスを
#独自のフレームワーク上で用意し、Web開発者にはそのフレームワークで用意
#したメソッドを使うよう徹底するというのがいいのではないかという事です。
#そうするとSQLインジェクションへの注意をフレームワーク開発上に集中でき
#末端のWeb開発者含めた全員に周知徹底コードの厳密な監視を随時行うという
#あまり現実的でなさそうな工数をある程度削減できるのではないかと。
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
> 徹底するとかでも潜在する危険度はぐっと減る事でしょう
プログラマが意識してそれを選択しなければならないとしたら、「きちんとエスケープすることを徹底すればよい」
というのとあまり変わらないと思いますよ。
パラメタライズドクエリ(変数バインド)自体は大昔からあるわけで。それがきちんと使われないから脆弱性が
減らないのですから。
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
私の手元では(Javaなので)PreparedStatementと静的解析ツールのFindbugs [sourceforge.net]を組み合わせて、多分おっしゃっているようなことを実現してはいるとは思いますが…。
.NET環境では、そういうものって無いのでしょうか?
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
単純に Prepare サイコーってだけなら、#985433 [srad.jp] で書かれている SqlCommand クラスが普通に Prepare 持ってます。
#985433 は、それをさらに業務的に利用しやすい .NET Framework 上のフレームワークを作ろうって話では?
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
せいぜい見つかったのは、SQLCommandオブジェクトを作るときに、生成もとのStringがfinalというかConst宣言したString型変数が渡されたかどうかを検出させる方法がない…と言っている程度に見えたから、「それなら静的解析ツールに頼ったほうがいいんでない?」と思ったのですが、どうでしょう。
# .NET環境用のものもいくつかあるようですね。
# 有料ですけが…。