0

HttpModule着信要求を分析して .NETのような攻撃の可能性をチェックする .NET があるとしますSql Injection。ここで、アプリケーションのユーザーがフォーム フィールドに次のように入力して送信するとします。

&#039&#032&#079&#082&#032&#049&#061&#049

それが の Unicode です' OR 1=1。したがって、リクエストでは次のようなものが得られます。

http://example.com/?q=%26%23039%26%23032%26%23079%26%23082%26%23032%26%23049%26%23061%26%23049

これは問題ないようにHttpModule見えますが (SQL インジェクションはありません)、サーバーはそれを正しくデコードしq=' OR 1=1、フィルターは失敗します。

だから、私の質問は：Is there any way to know at that point what is the encoding used by the request query string, so I can decode it and detect the attack?

ブラウザは、リクエストがどのエンコーディングに含まれているかをサーバーに通知する必要があるため、正しくデコードできると思います。それとも私が間違っていますか？

4

2 に答える 2

1

表示されているのは URL エンコードです。パーセント記号の後に 2 つの 16 進数が続き、1 つのエンコードされたバイト オクテットを表します。HTML では、アンパサンドで始まりセミコロンで終わるエンティティには、エンティティ名または明示的な Unicode コードポイント値が含まれます。

ブラウザとサーバーの間のネットワークを介して送信されるのは ですが、論理的には、受信時にサーバーによってデコードされたときhttp://example.com/?q=%26%23039%26%23032%26%23079%26%23082%26%23032%26%23049%26%23061%26%23049に実際に表されます。http://example.com/?q=&#039&#032&#079&#082&#032&#049&#061&#049コードがクエリ文字列を読み取るとき、受信する必要があります&#039&#032&#079&#082&#032&#049&#061&#049。サーバーはそれ以上 をデコードしない' OR 1=1でください。独自のコードでそれを行う必要があります。

URL クエリ文字列で SQL クエリ フィルタをそのまま指定できるようにしている場合、それはそもそもユーザー側のミスです。これは、パラメータ化された SQL クエリやストアド プロシージャを使用する代わりに、SQL クエリを動的に作成していることを示唆しているため、SQL インジェクション攻撃にさらされていることになります。あなたはそれを使うべきではありません。パラメーター化された SQL クエリとストアド プロシージャはインジェクション攻撃の対象にならないため、クライアントは URL で個々のパラメーター値を送信することのみを許可する必要があります。サーバー コードは、URL クエリから個々の値を抽出し、必要に応じて SQL パラメーターに渡すことができます。SQL エンジンは、攻撃を避けるために、値がサニタイズされ、フォーマットされていることを確認します。それを手動で処理するべきではありません。

于 2012-08-14T23:30:54.943 に答える
1

サーバーはそれを正しくデコードしますq=' OR 1=1

すべきではありません。&#039...アプリケーションが文字列を SQL クエリで使用する前にHTML デコードする正当な理由 (*) はありません。HTML デコードはクライアント側で発生します。

(* 無効な理由があります: アプリケーションの作成者は、自分が何をしているのかについて最も曖昧な考えを持っておらず、入力 HTML エスケープ関数を書き込もうとしています - そもそも見当違いの考えです - そして無能のために入力を書きます-de-escaping 関数の代わりに...しかし、それはありそうもないケースです.うまくいけば.)

その時点で、リクエストクエリ文字列で使用されるエンコーディングを知る方法はありますか

いいえ。一部の Web アプリケーション ファイアウォールは、考えられるすべてのデコード スキームを受信データに適用し、それらのいずれかが疑わしいものと一致した場合にトリガーすることで、これを回避しようとします。入力と脆弱なシステムの間。

これにより、パフォーマンスが低下するだけでなく、誤検出が増加する可能性があり、2 つ以上のデコーダーの可能なすべての組み合わせを試す WAF の場合は、2 倍になります。(たとえばT1IrMQ、base-64 でエンコードされた、URL でエンコードされOR 1た SQL 攻撃ですか、それとも単に車のナンバープレートですか?)

このアイデアをどこまで採用するかは、潜在的な攻撃をいくつキャッチするか、アプリの実際のユーザーにどれだけの悪影響を与えるかのトレードオフです。最終的には、アプリの外側のレイヤーでアプリの脆弱性に対して完全な保護を提供することはできないため、「正しい」ソリューションはありません (別名「WAF は機能しません」)。

于 2012-08-15T23:24:32.533 に答える