8

私たちは最近、DOM XSS 攻撃についてテストされ、失敗した他の誰かのコードを搭載しました。基本的に、URL フラグメントは jQuery セレクターに直接渡され、次のように JavaScript を挿入できるようになっています。

"http://website.com/#%3Cimg%20src=x%20onerror=alert%28/XSSed/%29%3E)"
$(".selector [thing="+window.location.hash.substr(1)+"]");

問題は、これがスクリプト全体で発生しており、修正するために多くの回帰テストが必要になることです。たとえば、データをエスケープした場合、if ステートメントはデータが一致しないため true を返さなくなります。

問題の JavaScript ファイルは、ビルド時に多数の小さなファイルから連結されるため、修正がさらに困難になります。

各インスタンスを調べてデバッグすることなく、いくつかのグローバルコードでこれらの DOM XSS 攻撃を防ぐ方法はありますか?

スクリプトの先頭に少し正規表現を追加して、XSS 攻撃で使用される一般的な文字を検出し、true が返された場合は単純にスクリプトを強制終了することを提案しました。

 var xss = window.location.href.match(/(javascript|src|onerror|%|<|>)/g);

if(xss != null) return;

これは機能しているように見えますが、私はこのソリューションに 100% 満足しているわけではありません。誰かが提供できるより良い解決策や有用な洞察を持っていますか?

4

2 に答える 2

6

正規表現ソリューションに固執する場合、これは理想からはほど遠いですが、制約を考慮すると最良の選択である可能性があります。

悪意のあるハッシュ（/(javascript|src|onerror|%|<|>)/g）に一致する正規表現を定義するのではなく、サウンドハッシュ（例/^[\w_-]*$/）に一致する正規表現を定義します。

誤検知エラー（例src_records）を回避し、許可されているものと許可されていないものを明確にし、より複雑なインジェクションメカニズムをブロックします。

于 2012-11-08T14:53:31.947 に答える
0

あなたの問題は、jQueryの入力文字列がセレクターとしてだけでなくHTMLとして扱われる可能性があることが原因です。

document.querySelector()jQueryの代わりにネイティブを使用してください。

IE7-のサポートが重要な場合は、Sizzleセレクターエンジンを試すことができます。これは、jQueryとは異なり、ネイティブとは異なり、querySelector()入力文字列をセレクターとは異なるものとして解釈しない可能性があります。

于 2012-11-08T14:35:26.820 に答える