20

SQLServerデータベースを備えたASP.NETWebアプリケーションがある場合、SQLインジェクション攻撃が行われる場合、それはSqlCommandクラスのインスタンスを通過すると想定しても安全ですか？

バックグラウンド：

SQLインジェクションの脆弱性があるかなり大きなWebアプリケーションを継承している状況にあります。コードを調べて他の問題を探すだけでいくつか見つかりましたが、SQLインジェクションのすべての脆弱性を見つける安全な方法は、すべてのファイルでインスタンスを検索しSqlCommand、それらがパラメーター化されたクエリであるかどうかを確認することでしょうか。これは確かな計画ですか？

4

4 に答える 4

20

特にSqlCommandだけを探すのではなく、コードでDBCommandまたはIDbCommandを使用できます。EF、L2S、NHibernateなどのORMでラップすることができます（すべて、ある程度のrawアクセスを提供します）。「dapper」やsimple.dataのようなものを使用できます。またはDataTable/DataAdapter。従来のOLEDBまたはADODBアクセスを使用するコードがある可能性があります。ちなみに、私たちが知っている限りでは、独自の低レベルTDSAPIを作成できたはずです。

つまり、データアクセスコードをチェックすることになります。これはさまざまな形をとることがあります。部門のアプローチが「SqlCommandを直接使用する」場合、それは状況を変えます。

また、SQLインジェクションは.NETに限定されません。たとえば、TSQLが動的SQLを作成するために何らかの連結を行う場合、パラメータ化した場合でも、生のコマンドテキストまたはストアドプロシージャでSQLインジェクションのリスクを作成できます。 EXECを介して呼び出されます。sp_executesqlがそれを助けることができることに注意してください。

于 2012-11-21T00:25:22.407 に答える
10

データベーススキーマによっては、ストアドプロシージャでの攻撃をチェックする必要がある場合もあります（ストアドプロシージャを使用していると仮定します）。私は人々が彼らのコードでパラメータ化されたストアドプロシージャを使用するのを見てきましたが、procでは彼らは単にEXECを使用してクエリを実行します：

CREATE PROC Dummy
(
   @Str VARCHAR(50)
)
AS
EXEC ('SELECT * FROM Table Where Column = ''' + @Str + '''')
于 2012-11-21T00:24:19.423 に答える
8

また、を使用または含むものを探す必要がありますSqlCommand。これらにはSqlDataAdapter、とりわけが含まれます。

于 2012-11-21T00:19:10.407 に答える
7

パラメータ化されたクエリライブラリを使用しているからといって、それが適切に使用されているとは限りません。コードを監査しているときに、パラメーター化されたクワイアが使用されている場合がありますが、クエリの一部は文字列の連結を使用して構築されています。より具体的には、テーブル名とクエリの制限/順序部分はよくある間違いです。

静的分析に完全に慣れている場合、最善の策は、アプリケーション内のすべてのクエリをgrepしてから、各クエリが適切に構築されていることを確認することです。はい、これには長い時間がかかります、そしてそれは気が遠くなるかもしれません。休憩を取り、メモを取り、を押します。あなたがSQLインジェクションを見つけるとき、それはやりがいがあります！

于 2012-11-21T00:20:13.927 に答える