この記事では主にPHPにおけるSQLインジェクションを防ぐ方法を紹介します。とても良い参考値です
1. SQLインジェクション攻撃とは
いわゆるSQLインジェクション攻撃とは、攻撃者がWebフォームの入力フィールドや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 login = '' or '1'='1' AND passwd = '' or '1'='1' になります。
⑸ サーバーはクエリまたはストアド プロシージャを作成し、ユーザー入力を変換します。 ID 情報をサーバーに保存されている ID 情報と比較します。
⑹ SQL コマンドは実際にはインジェクション攻撃によって変更されているため、ユーザーの身元を真に検証することができず、システムは攻撃者を誤って承認します。
アプリケーションがフォームに入力された内容を本人確認クエリに直接使用することを攻撃者が知っている場合、攻撃者は特別な SQL 文字列を入力してクエリを改ざんし、元の機能を変更し、システムを騙して認証を試みます。アクセス許可。
システム環境に応じて、攻撃者が引き起こす可能性のある被害も異なります。これは主に、データベースにアクセスするためのアプリケーションのセキュリティ権限によって決まります。ユーザーのアカウントに管理者またはその他の比較的高度な権限がある場合、攻撃者は、データの追加、削除、更新、さらにはテーブルの直接削除など、データベース テーブルに対してさまざまな操作を実行する可能性があります。
2. それを防ぐ方法
幸いなことに、入力された内容を使用して SQL コマンドを構築する前にすべての入力が入力されている限り、ASP.NET アプリケーションへの侵入を防ぐことは特に難しくありません。フォームでコンテンツをフィルターするだけです。入力のフィルタリングはさまざまな方法で実行できます。
(1) SQL クエリを動的に構築するには、次のテクノロジを使用できます:
最初: 一重引用符を置き換えます。つまり、単独で表示されるすべての一重引用符を 2 つの一重引用符に変更します。攻撃者が SQL コマンドの意味を変更するのを防ぎます。前の例をもう一度見てみると、「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 コマンドの実行に使用されるのを防ぎます。
(2) ストアド プロシージャを使用してすべてのクエリを実行します。 SQL パラメータの受け渡し方法により、攻撃者が一重引用符やハイフンを使用して攻撃を実行することを防ぎます。さらに、特定のストアド プロシージャの実行のみを許可するようにデータベースのアクセス許可を制限することもできるため、インジェクション攻撃が発生しにくくなるように、すべてのユーザー入力が呼び出されたストアド プロシージャのセキュリティ コンテキストに準拠する必要があります。
(3) フォームまたはクエリ文字列の入力の長さを制限します。ユーザーのログイン名が最大 10 文字しかない場合は、フォームに 10 文字を超える文字を入力しないでください。これにより、攻撃者が SQL コマンドに有害なコードを挿入することが大幅に困難になります。
(4) ユーザー入力の合法性をチェックし、入力内容に正当なデータのみが含まれていることを確認します。データ検査はクライアント側とサーバー側の両方で実行する必要があります。サーバー側の検証は、クライアント側の検証メカニズムの脆弱なセキュリティを補うために実行されます。
クライアント側では、攻撃者が Web ページのソース コードを取得し、合法性を検証するスクリプトを変更し (またはスクリプトを直接削除し)、その後、違法なコンテンツをサーバーに送信することが完全に可能です。修正されたフォーム。したがって、検証操作が実際に実行されたことを確認する唯一の方法は、サーバー側でも検証を実行することです。検証用のクライアント側スクリプトを自動的に生成できる RegularExpressionValidator など、多くの組み込み検証オブジェクトを使用できます。もちろん、サーバー側のメソッド呼び出しを挿入することもできます。既製の検証オブジェクトが見つからない場合は、CustomValidator を使用して自分で作成できます。
(5) ユーザーのログイン名、パスワードなどのデータを暗号化して保存します。ユーザーが入力したデータを暗号化し、データベースに保存されているデータと比較することは、ユーザーが入力したデータを「殺菌」することと同等であり、ユーザーが入力したデータはデータベースにとって特別な意味を持たなくなります。攻撃者が SQL コマンドを挿入するのを防ぎます。 System.Web.Security.FormsAuthentication クラスには HashPasswordForStoringInConfigFile があり、入力データのサニタイズに非常に適しています。
(6) データを抽出したクエリによって返されたレコードの数を確認します。プログラムで返されるレコードが 1 つだけであるにもかかわらず、実際に返されるレコードが複数行である場合、エラーとして扱われます。
(7) プリペアドステートメントの使い方
以上がこの記事の全内容となりますが、皆様の学習のお役に立てれば幸いです。
関連する推奨事項:
PHP オブジェクトインジェクションの深い理解 php インジェクションツール php ウェブサイトインジェクションスキャンツール php手動注射
以上がPHPでのSQLインジェクションを防ぐ方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。