ASP.NET で SQL インジェクション攻撃を防ぐ方法

1. SQL インジェクション攻撃とは何ですか?

SQL インジェクション攻撃とは、攻撃者が Web フォームの入力フィールドまたはページ リクエストのクエリ文字列に SQL コマンドを挿入し、サーバーをだまして悪意のある SQL コマンドを実行させることです。一部のフォームでは、ユーザー入力が動的 SQL コマンドを構築する (または影響を与える) ために直接使用されたり、ストアド プロシージャの入力パラメーターとして使用されたりする場合、そのようなフォームは SQL インジェクション攻撃に対して特に脆弱です。一般的な SQL インジェクション攻撃プロセスは次のとおりです。

⑴ ASP.NET Web アプリケーションにはログイン ページがあり、ユーザーがアプリケーションにアクセスする権限を持っているかどうかを制御します。ユーザーは名前とパスワードを入力する必要があります。

⑵ ログインページに入力された内容は、動的SQLコマンドの構築に直接使用されたり、ストアドプロシージャのパラメータとして直接使用されます。以下は、ASP.NET アプリケーションによって構築されたクエリの例です。

System.Text.StringBuilder query = new System.Text.StringBuilder(
　"SELECT * from Users WHERE login = '")
　.Append(txtLogin.Text).Append("' AND password='")
　.Append(txtPassword.Text).Append("'");

⑶ 攻撃者は、ユーザー名とパスワードの入力ボックスに「' または '1'='1」のようなものを入力します。

⑷ ユーザーが入力したコンテンツがサーバーに送信された後、サーバーは上記の ASP.NET コードを実行してユーザーにクエリを実行する SQL コマンドを構築します。ただし、攻撃者が入力したコンテンツは非常に特殊であるため、最後に実行されます。 SQL コマンドは次のようになります: SELECT * from Users WHERE ログイン = '' または '1'='1' AND パスワード = '' または '1'='1'。

⑸ サーバーは、クエリまたはストアド プロシージャを実行して、ユーザーが入力した ID 情報とサーバーに保存されている ID 情報を比較します。

⑹ SQLコマンドは実際にはインジェクション攻撃によって変更されているため、ユーザーの身元を真に検証することができず、システムは攻撃者を誤って承認します。

アプリケーションがフォームに入力された内容を本人確認クエリに直接使用することを攻撃者が知っている場合、攻撃者は特別な SQL 文字列を入力してクエリを改ざんし、元の機能を変更し、システムを騙してアクセス許可を付与させようとします。 。

システム環境が異なり、攻撃者が引き起こす可能性のある被害も異なります。これは主に、データベースにアクセスするためのアプリケーションのセキュリティ権限によって決まります。ユーザーのアカウントに管理者またはその他の比較的高度な権限がある場合、攻撃者は、データの追加、削除、更新、さらにはテーブルの直接削除など、データベース テーブルに対してさまざまな操作を実行する可能性があります。

2.どうやって防ぐのですか？

幸いなことに、SQL インジェクション攻撃による ASP.NET アプリケーションの侵入を防ぐのは特に難しいことではありません。フォーム入力コンテンツを使用して SQL コマンドを作成する前に、すべての入力コンテンツをフィルターするだけです。入力のフィルタリングはさまざまな方法で実行できます。

⑴ SQL クエリが動的に構築される状況では、次の手法を使用できます:

最初: 一重引用符を置き換えます。つまり、攻撃者が SQL コマンドの意味を変更できないように、すべての 1 つの一重引用符を 2 つの一重引用符に変更します。前の例をもう一度見てみると、「SELECT * from Users WHERE login = ''' or ''1''=''1' AND passwd = ''' or ''1''=''1'」は明らかに取得されます。同じ「SELECT * from Users WHERE login = '' または '1'='1' AND パスワード = '' または '1'='1'」でも結果は異なります。

2 番目: ユーザー入力内のすべてのハイフンを削除して、攻撃者が「SELECT * from Users WHERE login = 'mas' -- AND password =''」などのクエリを作成できないようにします。このようなクエリは後半がコメントアウトされており、は有効ではなくなりました。攻撃者が知っている必要があるのは正当なユーザーのログイン名だけであり、アクセスを成功させるためにユーザーのパスワードを知る必要はありません。

3 番目: クエリの実行に使用されるデータベース アカウントの権限を制限します。別のユーザー アカウントを使用して、クエリ、挿入、更新、削除の操作を実行します。異なるアカウントで実行できる操作を分離することで、元々 SELECT コマンドの実行に使用されていた場所が INSERT、UPDATE、または DELETE コマンドの実行に使用されるのを防ぎます。

⑵ ストアド プロシージャを使用してすべてのクエリを実行します。

SQL パラメータの受け渡し方法により、攻撃者が一重引用符やハイフンを使用して攻撃を実行することを防ぎます。さらに、特定のストアド プロシージャの実行のみを許可するようにデータベースのアクセス許可を制限することもできるため、インジェクション攻撃が発生しにくくなるように、すべてのユーザー入力が呼び出されたストアド プロシージャのセキュリティ コンテキストに準拠する必要があります。

⑶ フォームまたはクエリ文字列入力の長さを制限します。

ユーザーのログイン名が最大 10 文字しかない場合は、フォームに 10 文字を超える文字を入力しないでください。これにより、攻撃者が SQL コマンドに有害なコードを挿入することが大幅に困難になります。

⑷ ユーザー入力の合法性をチェックし、入力内容に合法的なデータのみが含まれていることを確認します。

データチェックはクライアント側とサーバー側の両方で実行する必要があります。サーバー側で検証を実行する理由は、クライアント側検証メカニズムの脆弱なセキュリティを補うためです。

クライアント側では、攻撃者が Web ページのソース コードを取得し、合法性を検証するスクリプトを変更し (またはスクリプトを直接削除し)、変更されたフォームを通じて違法なコンテンツをサーバーに送信することが完全に可能です。 。したがって、検証操作が実際に実行されたことを確認する唯一の方法は、サーバー側でも検証を実行することです。検証用のクライアント側スクリプトを自動的に生成できる RegularExpressionValidator など、多くの組み込み検証オブジェクトを使用できます。もちろん、サーバー側のメソッド呼び出しを挿入することもできます。既製の検証オブジェクトが見つからない場合は、CustomValidator を使用して自分で作成できます。

⑸ ユーザーのログイン名、パスワード、その他のデータを暗号化して保存します。

ユーザーが入力したデータを暗号化し、データベースに保存されているデータと比較することは、ユーザーが入力したデータを「殺菌」することと同じであり、データベースにとって特別な意味を持ちません。したがって、これにより、攻撃者による SQL コマンドの挿入が防止されます。 System.Web.Security.FormsAuthentication クラスには HashPasswordForStoringInConfigFile があり、入力データのサニタイズに非常に適しています。

⑹ データを抽出したクエリによって返されたレコードの数を確認します。

プログラムで返されるレコードが 1 つだけであるにもかかわらず、実際に返されるレコードが複数行である場合、エラーとして扱われます。

上記は ASP.NET が SQL インジェクション攻撃を防ぐ方法です。皆さんの学習に役立つことを願っています。

ASP.NET が SQL インジェクション攻撃を防ぐ方法に関するその他の記事については、PHP 中国語 Web サイトに注目してください。