IISで非常に長いクエリ文字列を使用したHTTPリクエストを許可することは有害ですか？
私は非常に長い（最大15,000）文字のHTTPリクエストを生成できる検索機能を備えたウェブサイトを開発しています。ただし、IISのクエリ文字列のデフォルト制限は2048文字です。これは、以下にリストされている設定を使用してweb.configファイルで簡単に変更できます。
system.web > httpRuntime > maxRequestLengthsystem.web > httpRuntime > maxUrlLengthsystem.webServer > security > requestFiltering > maxQueryStringsystem.webServer > security > requestFiltering > maxUrl
私の質問は、HTTPリクエストで非常に長いクエリ文字列を許可する場合に注意すべきセキュリティ上の懸念があるかどうかです。
pdate：ほんの少しの情報を追加する必要があります。
- ウェブサイトは、ウェブサイトにサインインした有料ユーザーのみが利用できます。
- 誰もがURLに2048文字を超える検索を作成する可能性は非常に低いですが、理論的には可能です。
15,000文字のURLはブラウザー間でうまく機能しません： https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url
ASP.NETアプリケーションでは、16,000文字の制限により、リクエストキューバッファー枯渇攻撃に対する脆弱性が8倍になることがすでにわかっていると想定します。現在、8xは、一般にASP.NET Webサイトで開かれているより良いDoS攻撃と比較してそれほど重要ではありません。
正規表現のマッチングはおそらく大きな問題ではありません。ほとんどの正規表現攻撃は、64文字と64,000文字の文字列で同等に機能します。これらは指数バックトラックパターンを悪用し、リクエストのタイムアウトにより、URLの長さは非常に重要ではなくなります。有利な点として、これらの種類の問題のほとんどは、パフォーマンスの問題にすぐに現れます。また、正規表現は通常、クエリ文字列ではなくパスにのみ適用されます。
例外はありますが、パスの正規表現は一般に非常に高速で、通常は最初の整数比較で一致を終了します。
制限を引き上げる場合は、すべてのURL書き換え、ルート、パスマッチング、およびPre-HandleRequestイベントが効率的であり、高速の終了パスがあり、ディスクやdbアクセスのような高遅延の作業を行わないことを確認してください。
免責事項：私はまさしく私が専門家ではないことを認めることによって序文を述べさせてください、しかしとにかくここに私の2セントがあります。
私の見解では、クエリ文字列に制限を設けるのは、アプリで不必要に長い文字列を処理しないようにするためです。たとえば、アプリに非常に複雑なURLルーティングルール（MVC3など）があり、RegExの束で文字列を評価する場合があります。短い文字列の場合、これは大したことではありませんが、大きな文字列を評価している場合は毛むくじゃらになります。他の場合には、あなたの場合のように、そのクエリ文字列を取り、DBルックアップなどのそれを使って何かをする必要があるかもしれません。これらのことは、時間とリソースを消費し、潜在的にbigひずみを加える可能性がありますWebサーバー上。
あなたの場合、ルーティングが何をするか（つまり、クエリ文字列をどのように処理するか）を知らなければ、これがどのような影響を与えるかを知ることは困難です。ルートがすべて、クエリ文字列の長さを返送したとしましょう。もちろん、これは、クエリ文字列のすべての順列を生成する場合ほどDDoSスタイルの攻撃に対して脆弱ではありません。これらは極端な例ですが、検索、DBルックアップなどのようなものは実際の問題を引き起こす可能性があり、DDoSに対して脆弱なままになる可能性があります。