web-dev-qa-db-ja.com

予期しないクエリパラメータを拒否する際の厳格さはどの程度ですか？

TL; DRリクエストで追加のパラメータが送信された場合にHTTP 400 Bad Requestレスポンスを返すことは「ベストプラクティス」ですか？

私はWebアプリをまとめて、OWASP ZAPでいくつかのテストを行っています。結果にかなり満足しています。発生したエラーはすべて信頼性が低いようで、エラーを詳細に調べたところ、ZAPツールがリクエストで実際には何も変更しなかったことがわかりました。しかし、それは私を「より高いレベル」の質問に導きます。それは例で最もよく説明されています：

OWASP ZAPは、次のURLのSQLインジェクションを発見したとされています：

http://example.com/api/client/1?query=%27+AND+%271%27%35%271%27+--+

「人間が読める」形式、つまり：

http://example.com/api/client/1?query=query' AND '1'='1' --

かなり標準的なSQLインジェクション攻撃のように見えます。現在、このエンドポイントはclientオブジェクトをJSON形式で返すことを目的としています。これが、OWASP ZAPを介してこのリクエストが行うことです。サーバーは期待どおりの結果を返し、ID = 1のクライアントが返しました。 OWASP ZAPドキュメントがSQLインジェクションに関して推奨するすべてを実行しているので、さらに何をする必要がありますか？

私は、OWASP ZAPがこの種の攻撃（エラー応答）に応じて何を受信することを期待しているのかわからないことに気づきました。 「これはデータベースとのインターフェース方法です」という種類のドキュメントは役に立ちますが、エラーで応答する必要があるかどうかはわかりません。

不適切なクエリパラメータが指定された場合、400 Bad Requestエラーを返す必要がありますか？

httpzap
1
Kryten

いいえ、予期しない追加のクエリパラメータがある場合、400を返すべきではありません。

理由：実際にアプリケーションを攻撃しやすくしています。特定のパラメーターが無効であることを攻撃者に通知することで、簡単にパラメーターの推測を開始でき、400ではなく200を受け取ったときに、他の方法で攻撃できる有効なパラメーターを見つけたことがわかります。さらに、誤検知が報告された場合、アプリケーションのセキュリティも低下しません。 400を返すロジックを追加すると、追加のペイオフなしでより多くの作業が必要になります

2
Dan Landberg

不適切なクエリパラメータが指定された場合、400 Bad Requestエラーを返す必要がありますか？

これは悪い考えではなく、ホワイトリストアプローチと共に、さまざまなシナリオで使用できます。

HTTP 400 Bad Requestを返すのは「ベストプラクティス」ですか

まあそれはトリッキーな質問であり、さまざまなWebアプリケーション攻撃を検討する必要があり、それらのどれもそれが解決策であることを教えてくれないことに答えるには答えてください。ホワイトリストは良いアプローチですが、多くの攻撃では「ベストプラクティス」が異なります。SQLインジェクションについて具体的に質問します。SQLインジェクションのベストプラクティスは、準備されたステートメント（パラメーター化クエリを使用）を使用することです。ホワイトリストを使用してSQLインジェクションを解決してみてください。あなたは単にできません。

だから私は何をすべきですか？

「Webアプリケーションのセキュリティへの取り組み方？」

自動化された攻撃は簡単なバグをもたらす可能性が高いことを理解する必要があります。また、アプリケーションが持つ可能性のあるロジック攻撃もカバーしません。安全なWebアプリケーションコードを作成するために、OWASPチートシートシリーズ（ https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets ）。まだもっと良いものを見つける必要があります。ハッピーコーディング！.

1
Vipul Nair