つまり、明らかにSQLインジェクション攻撃などのリクエストをWebアプリケーションに受け取っていることがわかったとします。「いたずらな」文字列のリクエスト変数をチェックするための短いテストを作成します。見つかった場合、どのコードで応答する必要がありますか?
「403Forbidden」を返してコンテンツを返さないことを考えていますが、よくわかりません。
つまり、明らかにSQLインジェクション攻撃などのリクエストをWebアプリケーションに受け取っていることがわかったとします。「いたずらな」文字列のリクエスト変数をチェックするための短いテストを作成します。見つかった場合、どのコードで応答する必要がありますか?
「403Forbidden」を返してコンテンツを返さないことを考えていますが、よくわかりません。
403 Forbidden
リソースにアクセスしてはいけないという意味だと思います。
したがって、400 Bad Request
代わりに使用します。結局のところ、ユーザーは正当な要求をしている限り、そのページにアクセスできます。
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
私には、「400:Badrequest」が最も論理的なオプションのようです。
編集:多分それは文脈にもっと依存します。
スクリプトを続行することが本当に不可能な場合は、400または404コードを返します。
他のすべての状況では、コードが悪意のある試みを「検出」したときに、ユーザー(ハッカー)に通知されるべきではありません。検証は、悪意のある試みではなく、無効な入力を検出する種類のものである必要があります。
唯一の例外はブルートフォース攻撃です(Webサイトでのブルートフォースログインの防止でそれらを防ぐ方法の詳細)。
例:
フォームにユーザー名のテキストボックスが含まれていて、ユーザー(ハッカー)が引用符で囲まれたSQLステートメントを使用してログイン/登録しようとした場合、検証では自動的に「無効なユーザー名」と表示されます。
一方、ログインの目的では、リンクに記載されているオプションを使用して、ブルートフォース攻撃からアプリケーションを保護する必要があります。
リクエストの問題を特定でき、許可されたものを求めている場合は、卑劣な方法で、それらによる損傷を防ぎ、処理することができるはずです。ただし、リクエストに意味がない場合は、400BadRequestがおそらく最良の選択です。