SQL インジェクションからの保護をサポートするために、文字列をパラメーターとして受け取り、「クリーンな」文字列を返す関数はありますか?
6 に答える
次のように AddWithValue メソッドでパラメータを追加できます。
SqlCommand cmd = new SqlCommand("Select * From Test Where TestID = @TestID");
cmd.Parameters.AddWithValue("@TestID", 5);
パラメータ、 LINQ to SQLまたはEntity Frameworkを使用する必要があります。
LINQ to SQL
http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx
エンティティ フレームワーク
http://msdn.microsoft.com/en-us/data/ef.aspx
SQL パラメータ
完璧または誰にでもできる機能はありません。他の手段 (つまり、ストアド プロシージャ、SQL パラメーター化など) を通じて SQL インジェクションから保護することを実際に目指す必要があります。
この機能はかなり効果的ですが:)
string CleanString(string s)
{
return string.Empty;
}
Security Stack Exchange でこの質問に対する回答をご覧ください。最適なパスは、OWASP の ESAPIである可能性があります。これは、Java EE、.NET、ASP Classic、PHP、ColdFusion CFML、Python の機能を備えた Enterprise Security API です。 JavaScript、Objective-C、Force com、Ruby、Swingset、C、C++、および Perl は次のとおりです。
プログラマーがリスクの低いアプリケーションを簡単に作成できるようにする、無料のオープン ソース Web アプリケーション セキュリティ コントロール ライブラリです。ESAPI ライブラリは、プログラマが既存のアプリケーションにセキュリティを簡単に組み込むことができるように設計されています。ESAPI ライブラリは、新しい開発の強固な基盤としても機能します。言語固有の違いを考慮して、すべての OWASP ESAPI バージョンは同じ基本設計を持っています: セキュリティ制御インターフェースのセットがあります。たとえば、セキュリティ コントロールのタイプに渡されるパラメータのタイプを定義します。各セキュリティ コントロールの参照実装があります。ロジックは組織固有ではなく、アプリケーション固有でもありません。例: 文字列ベースの入力検証。オプションで、セキュリティ コントロールごとに独自の実装があります。これらのクラスには、組織によって、または組織のために開発されたアプリケーション ロジックが含まれている場合があります。例: エンタープライズ認証。
また、次のドキュメントもお読みください: SQL インジェクション防止チート シート
SQL インジェクションの可能性があるかどうかを判断するのに十分なほど賢い関数は存在しないと思います。
しかし、最善の方法は、すべての可能性を回避することです。たとえば、データ アクセスにタイプ セーフな SQL パラメーターを使用します。
ご覧ください:
私は、SQL インジェクションを避けるためにパラメーターを使用することを強く信じています。ストアド プロシージャまたはパラメーター化されたクエリを記述して、これを回避できます。
パラメーターには、日付や数値に関する多くの問題を処理できるなど、SQL インジェクション以外にも多くの利点があります...