web-services - 予想よりも長い URL を拒否する必要がありますか?

Question

アプリケーションを開発しており、URL の形式はwww.example.com/some_url/some_parameter/some_keyword. これらの URL には最大長があることを設計上知っています (それでも有効です)。バッファ オーバーフロー/インジェクション攻撃から保護するために、すべてのリクエストで URL の長さを検証する必要がありますか? これは明らかなイエスだと思いますが、私はセキュリティの専門家ではないので、何かが欠けている可能性があります。

Answer 1

その入力を期待していない場合は、拒否してください。

常に入力を検証し、予想される範囲外のものは確実に破棄する必要があります。URL が正直なところ一定の長さを超えないことがすでにわかっている場合は、アプリケーションに到達する前に URL を拒否するのが賢明に思えます。

Answer 2

多層防御は優れた原則です。しかし、誤ったセキュリティ対策は悪い原則です。違いは多くの詳細に依存します。

N を超える URL が無効であると本当に確信している場合は、それを拒否することもできます。しかし、それが真であり、残りの入力検証が正しければ、とにかく後で拒否されます。したがって、このチェックが行うことは、コード内の他のバグによって引き起こされる損害を潜在的に軽減することです。N が何であるかを考えるよりも、これらのバグを回避する方法を考えることに時間を費やす方がよい場合がよくあります。

長さを確認する場合でも、コードの他の場所でこの長さ制限に依存しないことが最善です。これにより、さまざまなチェックがより緊密に結合され、仕様を変更してより長い URL を受け入れる必要がある場合に、次のバージョンで制限を変更することが難しくなります。たとえば、長さ制限が十分な注意と注意を払わずに URL をスタックに置く言い訳になる場合は、誰かを失敗に追い込んでいる可能性があります。

Answer 3

Safari、Internet Explorer、および Firefox はすべて、受け入れられる最大長が異なります。

私は 3 つの中で短い方に投票します。

http://www.boutell.com/newfaq/misc/urllength.html

リンクから引っ張ってきた -

" Microsoft Internet Explorer (ブラウザ) - 2,083 文字

Firefox (ブラウザ) - 65,536 文字を超えると、Windows Firefox 1.5.x でロケーション バーに URL が表示されなくなりました。ただし、より長い URL も機能します。100,000 文字でテストを停止しました。

Safari (ブラウザ) - 少なくとも 80,000 文字が動作します。"

Answer 4

N より長いすべてのURL が無効であるとどのように確信していますか? 確信が持てれば、サニティ チェックとして制限しても問題はありませんが、悪用のクラスを防いだと勘違いしてはいけません。

Answer 5

問題を引き起こす可能性がある唯一のことは、現在 URL が N を超えることはありませんが、それが永遠に続くとは保証できないということです。そして 1 年後に、URL の長さが N+y になるように編集を行うために戻ったときに、URL 拒否コードを変更するのを忘れる可能性があります。

URL パラメータを使用する前に、それらを確認することをお勧めします。

Answer 6

ああ、たくさんの答え、たくさんの良い点がありますが、散らばっているので、これらすべてをまとめてみましょう。tl;dr imo、これはアプリケーション層のコードにとっては低レベルの懸念事項です。

はい、URL は任意の長さにすることができますが、実際にはブラウザーには制限があります。もちろん、それは、自分自身をそれらのベクトルに制限しようとする人々によるブラウザベースの攻撃からあなたを保護するだけなので、アクティブな攻撃の試みを処理する何らかの方法が必要です.

わかりました、バッファ オーバーフローを防ぐことができます。まあ、あなたが低レベルで働いていて、そのような懸念について考えていない場合に限ります. 最近のほとんどの言語は文字列を適切にサポートしており、文字列がオーバーフローすることはありません。非常に低レベルのシステムを扱っていて、実際にデータをバイトとして読み取って「文字列」型に入れている場合は、これを検出して処理する方法が必要ですが、メモリを割り当てるのはそれほど難しくありません。一度に既知の量を転送します。確保したメモリの量を追跡してください。率直に言って、その低レベルを扱っている場合は、別のものを使用する必要があります。

さて、文字列の長さに基づいて拒否するのはどうですか? これに戻る主な欠点は、誤った安心感の可能性です。つまり、コードの一部の領域が「だらしなく」なり、回避しようとしている悪用に対して脆弱になる可能性があります。この「グローバル」制限が実際に十分であることを確認するように注意する必要があることは明らかですが、URI 形式を考慮すると、これらの「部分」に最大長を報告させ、長さチェックを中心にさせることができる場合があります (両方について)。文字列全体とそのコンポーネント); 少なくともこの方法では、1 つの部分でより長い文字列を許可する必要がある場合、変更を処理する方が簡単です。

もちろん、これにはいくつかの利点があります。たとえば、文字列の長さを比較してすぐにリクエストを拒否できるのは非常に迅速です...しかし、「行儀の良い」サイトであることを忘れないでください。サーバーがこれを拒否している理由を説明する適切な応答を送り返します。しかし、実際には、これらのタイプの「間違った」URL の多くを処理する必要があると本当に思いますか? 確かに、それらは他の多くの点で間違っているでしょう。

なんらかの理由で、使用している言語を言いたくありませんでした。Java や Python などの高水準言語には、「ウェブ関連のもの」を処理するための非常に優れたライブラリがいくつかあります。Java では、そのパターンに正規表現を使用するなど、URI のパターンを指定できるため、URL に名前が必要な場合は@Path("/person/(.{0..100}")、パラメーターを 100 文字に制限するなどの方法があります。Ruby や Python のようなものが同等のものを持っていなかったとしたら、私は驚かれることでしょう。

最後に、長さに関係なく、長さだけでなく、検証する必要があることがたくさんあります。バッファ オーバーフローの原因となる URI の長さを心配する必要があるのは非常に低レベルのことであり、非常に汎用的である必要があります。「アプリケーション層に渡す」ではなく「処理する」と言ったことに注意してください。その低レベルで拒否する可能性があり、システムイベントもトリガーする可能性があります。

Answer 7

これにより、ある程度の安全性が得られ、非常に長い URL が送信された場合に帯域幅が少し節約される可能性があると思いますが、実際のアプリケーションでもデータを検証する必要があります。複数レベルのセキュリティの方が一般的には優れていますが、最初は (弱い) セーフガードを使用しているため、残りの部分で問題が発生しないと誤解しないでください。

Answer 8

いいえと思います。それは単なる偽のセキュリティです。適切にプログラムして、リクエストに問題がないかどうかを確認してください。それで十分なはずです。

また、将来性を保証するものではありません。

Answer 9

はい。長すぎると確信している場合は、できるだけ早く拒否してください。可能であれば、アプリケーションに到達する前に拒否します (たとえば、IISLockdown はこれを行います)。

ただし、文字エンコーディングを考慮することを忘れないでください。

Answer 10

長さをチェックするよりも、中身をチェックしたほうがいいと思います。将来、URL スキーマをどのように使用するかはわかりませんが、いつでも入力をサニタイズできます。非常に複雑なことを非常に簡単に言えば、ユーザー提供のデータを信頼しないでください。DB クエリに直接入れたり、eval() したり、当然のことと考えたりしないでください。

Answer 11

有効な URL がNバイトを超えてはならないことがわかっている場合は、クロスサイト スクリプティングの試みを手間をかけずにすばやく拒否するための良い方法のように思えます。

Answer 12

URL の長さを検証するよりも、リクエストの内容を検証する方が適切です。

将来、ニーズが変わる可能性があります。その時点で、URL の長さの検証を削除または変更する必要があり、バグが発生する可能性があります。

それが証明されたセキュリティの脆弱性になる場合は、それを実装できます。

Answer 13

わかりました、そのような N が存在すると仮定しましょう。onebyone が指摘したように、N 文字より長い不正な URL は、とにかく他の入力検証によって拒否されます。しかし、私の目には、これはまったく新しいことを考えさせてくれます。

この定数を使用して、他の検証を検証できます。ただし、他の検証で特定の URL を無効として検出できなかった場合、その URL が N 文字を超えている場合、この URL はバグを引き起こし、記録する必要があります (また、アプリケーション全体をシャットダウンする必要があります。十分に短い無効な URL)。