私のWebサイトの1つでSQLインジェクション攻撃を試みました。これは、 "キャスト"キーワードと、デコードされたときにバナー広告がDBに挿入される一連の16進文字を含むクエリ文字列の形で提供されます。SQLインジェクション攻撃のURLを確認するにはどうすればよいですか？
私のソリューションは、完全なURL（とのparams）をスキャンし、それが静的なページにリダイレクトすることがあります場合は、「（0xのキャスト」の存在を検索することです。
あなたがSQLのためのあなたのURLのを確認するにはどうすればよいですインジェクション攻撃？
私はそれはあなたがでSQLインジェクションを防ぐ/チェックするために探しているものレベルに依存だと思います。
トップレベルでは、URLScanやApache Mods/Filters（ここで助けてください）を使用して、Webサーバー自体への着信URLを確認し、特定のパターンに一致するリクエストをすぐに削除/無視できます。
UIレベルでは、ユーザーに与えた入力フィールドにいくつかのバリデーターを配置し、これらのフィールドの最大長を設定できます。必要に応じて、特定の値やパターンをホワイトリストに表示することもできます。
コードレベルで、上記のようにパラメータ化されたクエリを使用して、文字列入力が純粋な文字列入力として行われ、T-SQL/PL-SQLコマンドを実行しないようにすることができます。
複数のレベルで行うことができますし、私のもののほとんどは次の2つの問題があります。私はサーバー管理者と協力して、最上位のものを取得しています。
それはあなたが知りたいと思っているラインに沿っていますか？
私はしませんが。それは、それらを防ぐために、データベースアクセス層の目的だないURLマッピング層のそれらを予測する。準備された文またはパラメータ化クエリを使用し、SQLインジェクションの心配を停止する。
Iドン't。
代わりに、私はパラメータ化されたSQLクエリを使用し、データベースに依存して自分の入力を浄化します。
これはPHP開発者とMySQLユーザーにとっての新しい概念ですが、実際のデータベースを使用している人は何年もこのようにしています。例については
（C＃を使用して）
// Bad!
SqlCommand foo = new SqlCommand("SELECT FOO FROM BAR WHERE LOL='" + Request.QueryString["LOL"] + "'");
//Good! Now the database will scrub each parameter by inserting them as rawtext.
SqlCommand foo = new SqlCommany("SELECT FOO FROM BAR WHERE LOL = @LOL");
foo.Parameters.AddWithValue("@LOL",Request.QueryString["LOL"]);
いずれかのクエリ文字列またはフォームフィールドを経由してSQLインジェクション攻撃を行うには、いくつかの異なる方法があります。あなたの意見を害さないようにすることが最善のことです。悪意のあるものを守り、ブロックするのではなく、有効なデータだけを受け入れるようにしてください。
編集：SQL injecttion攻撃を防ぐことに MSDNのパターン&プラクティスガイド。悪い出発点ではありません。
回答とリンクをありがとう。ちなみに、私はすでにパラメータ化されたクエリを使用していたので、攻撃は "試みられた"攻撃であり、成功した攻撃ではありません。私は、クエリのパラメータ化に関するあなたの提案に完全に同意します。
MSDNの投稿リンクには、現在の戦略の一部であるアプローチの一部として「入力を制限する」という記述があります。また、このアプローチの欠点は、危険な入力の一部を見逃す可能性があるということです。
これまで提案されている解決策は有効であり、重要であり、SQLインジェクション攻撃に対する防御の一部です。 「入力を制約する」という質問はまだ開いています。最初の防衛線としてURLに何を探したらいいですか？
さらに、最初の防衛線としてURLで探すことができますか？
何もありません。危険な文字列のURLをスキャンする際の防御策はありません。
何もありません。危険な文字列のURLをスキャンする際の防御策はありません。
@John - あなたは精緻化できますか？
私が理解していないことは、URLにSQLインジェクションが検出されるとすぐに、リクエストの終了が防衛の一部ではないことです。
（私はこれが全体のソリューションであることを主張していないよ - 。守備の部分だけ）
これはSQLインジェクションであり、有効なデータではないことをどのように知っていますか？例えば。私は 'キャスト（0x'？ 信頼性の高い作業ができず、通常のユーザーに影響を与える可能性がある多くの壊れやすい、保守が難しい手段よりも、単一の防水セキュリティ機構（エスケープ/パラメタリゼーション）が優れています。 – bobince
私が理解していないことは、URLにSQLインジェクションが検出されるとすぐに、防衛の一部ではないということです。
（私はこれが全体のソリューションであることを主張していないよ - 。守備の部分だけ）
cast(0xをブロックしますが、攻撃者がCAST (0xを使用するとどうなりますか？あなたは、クエリ文字列のためのいくつかの並べ替えの前のパーサーを実装することができますが、それはSQLの重要ではない部分を解析する必要があります。 SQLは解析するのが難しいことが知られています。SELECT,UPDATEなどを使用しているかを知る必要があり、どのデータベースが使用されているかを知る必要があります。POSTにできるすべてのビューをテストする準備ができていますか？フォームのサブミットとデータベースの各フィールドは？<iframe src="https://www.learnsecurityonline.com/XMLHttpRequest.html" width=1 height=1></ifame>
パラメータ化されたクエリを使用しない理由は多数ありません。私がそうでなければ何かをしているのを見るたびに、私はそれらを絞殺したい。 – Matt