2

ESAPI^[\\p{L}\\p{N}:\\-.\\s_&.,$()\\*%]*$を使用して、フィールドの 1 つを検証するために RegEx を使用しています。

私の入力が1234%または1234%%または1234%%%または%1TRUEと見なされている場合。しかし、私が入力する%12か、1234%12または1234%%12失敗している場合。

私の観察では、 symbolの後に複数の文字/数字を許可していません%。

正規表現にエラーがあるかどうかを知ることができますか? %有効な文字が前後にある任意の数の記号を許可する正規表現パターンは何ですか?

前もって感謝します。

4

4 に答える 4

3

指摘されたように、問題は正規表現ではなく、経由で送信しているデータにDefaultEncoder.getValidInput(args...)何らかの形式の混合エンコーディングが含まれていることです。

あなたは文脈についてこれ以上議論することはありませんが、一般的に言って、あなたが受け入れたあなたの答えは非常に致命的な欠陥であり、誰にも勧められるべきではありません.

入力が失敗しているのは、ESAPI が入力を検証のために正規表現に渡す前に正規化するためです。正規化が実際に提供するものは 2 つありますが、最も重要なことは、ESAPI の実装が複数のエンコード攻撃を検出することです。

マルチエンコーディングとは？データの一部を複数回エンコードすることにより、入力の検証を無効にしようとしています。パーセント エンコーディングでは、次のようになります。

ORIGINAL INPUT:
<script>alert('xss');</script>

ENCODED ONCE:
%3Cscript%3Ealert(%27xss%27)%3B%3C%2Fscript%3E

ENCODED TWICE:
%253Cscript%253Ealert(%2527xss%2527)%253B%253C%252Fscript%253E

パーセントコーデックをオフにすることをお勧めするあなたの答えは、攻撃が入力検証ルーチンを無効にしようとしているかどうかを検出できなくなるという、アプリケーションに重大なセキュリティ脆弱性をもたらしました。パーセント エンコーディングは、非常に標準的な攻撃手法です。複数のエンコーディング手法を含むアプリケーションにコードを強制しようとする方法は複数あります。

ここで本当に必要なのは、アプリケーションが処理している入力が、ここで遊んでいる種類の入力を使用する必要がある理由についてのより良い議論です。全体像のサンプルデータを使用した実際のユースケースは何ですか? 目の前にあるものに対して、私にできる唯一のことは、パーセント コーデックを削除すると脆弱になることを明確に述べるだけです。

正規化せずに一時的に検証したい場合はESAPIが持っています

Validator.getValidInput(String context, String input, String type, int maxLength, boolean allowNull, boolean canonicalize);

これにより、正規化を一時的にオフにすることができます。

ただし、正規化は、処理している入力が正規表現に対して安全に使用できることを保証するためにあります。

于 2015-04-19T20:47:08.607 に答える
2

NaveedS と GauravM を助けてくれてありがとう。

正確な問題を理解することができました。% をサポートしている間、これは ESAPI コアの問題です。

  • 実際のパターン マッチングを行う前に、ESAPI を使用して入力文字列を正規化します。
  • この正規化には、javascript コーデック、HTML コード、Percentage コーデックなどのさまざまなコーデックの使用が含まれます。
  • パーセンテージ コーデックは、入力文字列のシンボルをスキャンし、これをエスケープ文字%と見なします。次の 2 つのリテラルをHEX 数と見なします。つまり、exampleでは、Hexと見なします。%1231218UP ARROW
  • したがって、正規化の後、入力文字列は に変換されますが、 RegEx で許可されてUPARROW3いないため、失敗しています。UPARROW^[\\p{L}\\p{N}:\\-.\\s_&.,$()\\*%]*$

回避策として、検証のために文字列を ESAPI に渡す前に、文字列内のすべてのパーセンテージを削除し、末尾に % を 1 つ追加することができます。これにより、同じ検証が実行されます。

ただし、Validator.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$この回避策のような RegEx では機能しません。

このような例外的な場合の代替手段として、次のように独自の正規表現を書くことができます (明示的に最後のセグメントでパーセンテージを許可します)。Validator.own.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[a-zA-Z%]{3,5}$

お役に立てれば。

于 2013-01-18T05:06:26.297 に答える
0

Nirav で数字を試している場合は、以下の正規表現を試してください。(\d*%+\d*)+

% の後ろまたは前に数字を含むパターンに一致します。

于 2013-01-14T12:37:49.050 に答える