1

この質問は、セキュリティの脅威に関するものです。以下の使用法で、クライアント側で選択された DropDownList の値が変更され、サーバー側に影響を与えることができるのだろうか?

ここで使用法（aspx定義）

  <asp:DropDownList AutoPostBack="true" ID="dropDownListDrawingArtists" CssClass="DropDownArtists"
                runat="server">
  </asp:DropDownList>

サーバー側の充填

    if (IsPostBack == false)
    {
        if (srLang == "tr")
        {
            dropDownListDrawingArtists.Items.Add("Çizen Artist Filtresi: Bütün Çizen Artistler");
        }
        else
        {
            dropDownListDrawingArtists.Items.Add("Drawing Artist Filter: All Drawing Artists");
        }

        DataSet dsDrawingArtists = DbConnection.db_Select_Query("select DrawingArtist,COUNT(PokemonId) as Pokecount from tblPokedex group by DrawingArtist order by Pokecount desc,DrawingArtist asc");

        for (int i = 0; i < dsDrawingArtists.Tables[0].Rows.Count; i++)
        {
            dropDownListDrawingArtists.Items.Add(dsDrawingArtists.Tables[0].Rows[i]["DrawingArtist"].ToString());
        }

        if (Session["FilterByArtist"] != null)
        {
            dropDownListDrawingArtists.SelectedIndex = Convert.ToInt32(Session["FilterByArtist"].ToString());
        }
    }

そして、ポストバックでの最終的な使用法

    if (dropDownListDrawingArtists.SelectedIndex > 0)
    {
        srFilterByDrawingArtist = " and DrawingArtist='" + dropDownListDrawingArtists.SelectedItem.ToString() + "'";
        Session["FilterByArtist"] = dropDownListDrawingArtists.SelectedIndex.ToString();
    }

ご覧のとおり、SQL クエリで直接使用しています。私はグーグルクロームで自分自身をテストしました。dropDownListDrawingArtists の値を変更し、ポストバックを行いました。サーバー側の値は影響を受けませんでした。念のために

答えてくれてありがとう

asp.net 4.0 C# 4.0

4

3 に答える 3

2

現在可能かどうかは関係ありません。stgringsを連結する代わりに、パラメータ化されたクエリを使用する必要があります。

この理由は、OWASPが文字のエスケープをパラメーター化されたクエリやパラメーター化されたストアドプロシージャと比較して「弱い」と定義している理由、およびホワイトリストがブラックリストよりも優れている理由と同じです。

OWASPチートシートからSQLインジェクションの防止まで：

この3番目の手法は、クエリに入力する前にユーザー入力をエスケープすることです。動的クエリをプリペアドステートメントまたはストアドプロシージャとして書き直すと、アプリケーションが破損したり、パフォーマンスに悪影響を及ぼしたりすることが懸念される場合は、これが最善のアプローチとなる可能性があります。ただし、この方法論は、パラメーター化されたクエリ（強調私のもの）を使用する場合に比べて脆弱であり、すべての状況ですべてのSQLインジェクションを防ぐことを保証することはできません。この手法は、費用効果の高い方法でレガシーコードを改良する場合にのみ、注意して使用する必要があります。ゼロから構築されたアプリケーション、またはリスク許容度の低いアプリケーションは、パラメーター化されたクエリを使用して構築または再作成する必要があります。

それが脆弱である理由は、誰かが潜在的な穴を悪用するための新しい方法に常に取り組んでいるためです。今日の改ざんを防ぐために機能するものは、明日回避される可能性があります。

とは言うものの、現在、ViewState保護はこれに対する保護を提供します。誰かがリストを改ざんすると、通常、自動的に生成された「無効なビューステート」エラーが発生し、コードは処理されません。

http://msdn.microsoft.com/en-us/magazine/ff797918.aspx

しかし、その振る舞いに頼らないでください。オフにすることができますが、Jr。開発者がエラーを解決するためにオフにするのを見てきました。（コードレビューに感謝します。）

于 2012-12-11T16:17:01.753 に答える
1

見た目からすると、SQLインジェクション攻撃に対して非常にオープンです。データベースと通信するために文字列連結を使用しないでください。ユーザーがサイト/アプリケーションとの通信にプログラムを使用していないことをどのように知っていますか？あらゆる種類の操作が可能です。

ドアを開けると、いろいろなことが通り抜けます。

于 2012-12-11T16:13:11.203 に答える
0

はい、あらゆる種類のユーザー入力を受け取り、それをSQLクエリに直接パッチするときはいつでも、リスクがあります。

まず、特定の形式またはいくつかの既知の値である必要があるすべての入力を確認する必要があります。

次に、クエリを作成する代わりに、SQLクエリ引数を使用します。

于 2012-12-11T16:13:14.080 に答える