0

HTTPModuleを使用していくつかの基本的なMySqlインジェクションを防ぐためのこのコードが見つかりました

public class SampleSqlInjectionScreeningModuleCS : IHttpModule
{
    //Defines the set of characters that will be checked.
    //You can add to this list, or remove items from this list, as appropriate for your site
    public static string[] blackList = {"--",";--",";","/*","*/","@@","@",
                                       "char","nchar","varchar","nvarchar",
                                       "alter","begin","cast","create","cursor","declare","delete","drop","end","exec","execute",
                                       "fetch","insert","kill","open",
                                       "select", "sys","sysobjects","syscolumns",
                                       "table","update"};

    public void Dispose()
    {
        //no-op 
    }

    //Tells ASP.NET that there is code to run during BeginRequest
    public void Init(HttpApplication app)
    {
        app.BeginRequest += new EventHandler(app_BeginRequest);
    }

    //For each incoming request, check the query-string, form and cookie values for suspicious values.
    void app_BeginRequest(object sender, EventArgs e)
    {
        HttpRequest Request = (sender as HttpApplication).Context.Request;

        foreach (string key in Request.QueryString)
            CheckInput(Request.QueryString[key]);
        foreach (string key in Request.Form)
            CheckInput(Request.Form[key]);
        foreach (string key in Request.Cookies)
            CheckInput(Request.Cookies[key].Value);
    }

    //The utility method that performs the blacklist comparisons
    //You can change the error handling, and error redirect location to whatever makes sense for your site.
    private void CheckInput(string parameter)
    {
        for (int i = 0; i < blackList.Length; i++)
        {
            if ((parameter.IndexOf(blackList[i], StringComparison.OrdinalIgnoreCase) >= 0))
            {
                //
                //Handle the discovery of suspicious Sql characters here
                //
                HttpContext.Current.Response.Redirect("~/About.aspx");  //generic error page on your site
            }
        }
    }

}

それは良いコードですか、それともブラックリストにさらに追加する必要があると思いますか、それともこれを忘れて別の方法で注入を防ぐ必要がありますか？

4

4 に答える 4

4

パラメータ化されたクエリがあなたのために（そしてそれ以上に）機能するのに、なぜ文字列検査を実行するのでしょうか?

コードから発行している SQL ステートメントでParameters.Add()orを使用します。Parameters.AddWithValue()

于 2012-10-31T16:42:40.673 に答える
3

データのサンタイズ/フィルタリングに対するブラックリスト アプローチは、データのサンタイズに対する最良のアプローチではありません。(トレードオフによっては適切な場合もありますが)

ここに簡単な説明があります: http://www.testingsecurity.com/whitelists_vs_blacklists

ブラックリストは、否定的な入力のリストに対して目的の入力をテストしています。基本的に、すべての否定的または悪い条件のリストをコンパイルし、受け取った入力が悪いまたは否定的な条件の 1 つでないことを確認します。ホワイトリストは、可能な正しい入力のリストに対して目的の入力をテストしています。これを行うには、すべての適切な入力値/条件のリストをコンパイルし、受け取った入力がこの正しい条件の 1 つであることを確認します。

どちらが良いと思いますか? 攻撃者は、あらゆる手段を使って Web ベースのアプリケーションにアクセスします。これには、あらゆる種類の否定的または悪い条件、さまざまなエンコード方法の試行、有効なデータへの悪意のある入力データの追加が含まれます。発生する可能性のある悪い順列をすべて思いつくことができると思いますか? ホワイトリストは、入力を検証する最良の方法です。何が必要で、悪い型は受け入れられないことを正確に知ることができます。通常、ホワイトリストを作成する最良の方法は、正規表現を使用することです。正規表現を使用すると、可能なすべての正しい値を手動でリストする代わりに、ホワイトリストを抽象化する優れた方法になります。

パラメータ化されたクエリまたはパラメータ化されたストアド プロシージャなど、標準の実証済みの防御策を使用することをお勧めします。

于 2012-10-31T16:42:28.817 に答える
2

いいえ、それは良くありません。

これは有効な入力をブロックし、不正/無効なデータからクエリを構築するコードを保護するものではありません。

受信データが悪いと仮定してクエリを正しく構築するだけで、はるかに良くなります。

于 2012-10-31T16:42:07.413 に答える
2

いいえ、ブラックリストは SQL インジェクションを止めるために機能しません。ブラックリストを回避する方法については、 OWASPページを参照してください。パラメータ化されたクエリを使用する必要があります

于 2012-10-31T16:42:18.993 に答える