0

パラメータ化されたクエリを使用してデータを検証する以外に、SQL インジェクションに対する他の対策があるかどうかを知りたいと思いました。ありがとう!

4

3 に答える 3

0

上記のすべての良い答えで、私がしたことは、すべてのテーブルをスキャンし、テーブル名と列のホワイトリストを作成するスクリプトを作成し、それを使用して、テーブル/列名であるはずのユーザー入力を検証することです。パラメトリック クエリ。それ以外は PDO Bind を介してパラメータ化されます!

于 2011-12-19T23:14:46.757 に答える
0

明らかに、クライアントで行っている可能性があることに加えて、サーバー側でデータを検証していることを確認してください。

また、Web について話している場合は、すべてのデータ、つまり QueryString と Cookie 値、および Form フィールドを検証していることを確認してください。

これが Google での最初のヒットであることは知っていますが、この記事を時々読んで、本当に評価しています (これも Web に関連しています): http://www.securiteam.com/securityreviews/5DP0N1P76E.html

于 2011-07-20T08:41:07.363 に答える
0

私は常にカスタムサニタイザーサーバー側を介してユーザー入力テキストを実行するため、通過した場合に備えて厄介なものをすべて取り除くことができます. (& " = ' など)

私が呼び出したストアド プロシージャを除いて、私のコードには SQL ステートメントがありません。

ストアド プロシージャのパラメータでは、たとえば VARCHAR(10) などのテキスト サイズを制限できるため、通常、文字列 "123456" と "12345' AND UNION SELECT * FROM MEMBERS INNER JOIN MEMBER_ADDRESS ON ID" が送信されると予想される場合、保存された手順はそれを好きではありません。

また、最後のポイントとして、戻ってくるすべての例外をキャッチし、それらを適切に処理するようにしてください。「データベースに接続できませんでした。'USER_ID' は mydatabase.member に存在しません」のような Web サイトが表示されることがあります。データベースのアーキテクチャを誰かに嗅がせれば、エクスプロイトのボールが転がり始めます。

于 2011-07-20T09:02:16.880 に答える