web-dev-qa-db-ja.com

XSSはjQuery（location.hash）で可能ですか？

次のコードでXSSを悪用することは可能ですか？

jQuery(window.location.hash)

それは私には思われる window.location.hashは常にハッシュで始まります#、そして最新のjQueryは常にこれをIDセレクターとして解釈します。これは正しいです？

xssjquery
9
Sjoerd

はい、jQuery(window.location.hash)を使用して悪意のあることを行うことが可能です。別のSEの質問の an answer へのコメントで言及された このアーカイブされたブログ投稿 を参照してください。ブログの投稿で説明されているように、CSSタイミング攻撃を行うことができます。

セレクタ*:has(:has(:has(*)) :has(*) :has(*)) input[name=authenticity_token][value^='x']を実行すると、authenticity_tokenが 'x'で始まる場合にのみ時間がかかります。

悪意のあるサイトがiframe内のターゲットサイトを開き、セレクターが一致するまでに長い時間がかかるかどうかを確認できます。 _input[name=authenticity_token][value^='x']_が一致しない場合、セレクターは短絡され、jQueryはよりコストのかかる:has(...) sをチェックしません。

ブログの投稿で述べたように、これが両方のサイトを同じプロセスで実行するブラウザーで実行されている場合、被害者のサイトを呼び出すサイトの遅延を簡単に測定できます。 （プロセスが個別にスケジュールされている場合でも、一般にコンピューターの速度が低下する可能性があるため、個別のプロセスでもタイミング攻撃が発生する可能性があるように思われます。 URLの何かが秘密の文字列と一致するかどうかに基づいて、多くの処理を実行する可能性があることに注意してください。）

1
Jacob C. says Reinstate Monica

パッチ 9521 および 1129 数年前にこの問題を軽減しようとしましたが、XSSの可能性を完全に排除することを主張していません。私はjQuery 2.xで実行していますが、エクスプロイトの一部はまだ存在すると主張していますが、機能していないようです。そのため、提供したコードがエクスプロイトに十分かどうかを確実に否定することはできません。

それだけの価値があるのですが、jQueryオブジェクトで何かをした場合にも、このエクスプロイトが発生する可能性があります。顧客がHTMLを送信することを許可し、顧客が以下を送信したとします。

_<div id="xss">alert('xss');<div>
_

そして、おかしな理由で、このHTMLを表示するページに次のコードが含まれています。

_eval(jQuery(window.location.hash).text());
_

_#xss_のURLハッシュにより、アラートがトリガーされます。

したがって、これが可能であることを確認できます。ただし、特に脆弱になるようにコードを記述せずにこの特定の方法を悪用することは非常に困難です。

_window.location.hash_の値を検証するか、特殊文字を取り除いてからjQuery()に渡すことをお勧めします。また、jQueryオブジェクトで何をするかを常に考慮してください。

1
Goose

Gooseの回答が言及しているように、これに脆弱なsome以前のバージョンのjQueryがあったようです。

JQuery関数はこのように文字列をDOM要素に変換できるので...

$(‘<p>Something</p>’);

あなたのコードが：

$(location.hash);

そして、攻撃者により、次のようなハッシュフラグメントで終わる特別に細工されたURLでページにアクセスさせられました。

#p=<img src%3D/%20onerror%3Dalert(1)>

次に、jQueryはハッシュをHTMLとして解釈し、必要なDOM要素を作成し、プロセスで実際にそれらに接続されているJSハンドラーを実行します。

JQueryの将来のバージョンでは、HTMLよりもIDセレクターを優先することでこれを軽減したようです。そのため、ハッシュで始まるものはすべて、HTMLではなくCSSセレクターとして扱われます。

0
Simon East

なぜ推測するのですか？最初に\ wでサニタイズするだけで、とても簡単です。それらがハッシュで始まる必要がある場合でも、jQuery行を完全に制御できるかどうかはかなり恐ろしいようです。グースのリンク 9521 の言葉で、

問題は、これが一般的な骨の折れる動きであり、この場合、HTMLよりもIDセレクターを優先する必要があるかどうかだと思います。私は納得できた。

そして

しかし、一般的にどのようにこれを防ぐことができるかはわかりません。ハッシュ記号は単なるテキストであり、文字列は有効なHTMLです。スクリプトを含む可能性のある$（）に信頼できない入力を渡してはいけません。

したがって、少なくとも1人のjQuery開発者によると、これは脆弱性とはまったく見なされていません。そして、これを行わないようにプログラマーに任せたいと考えています。ここで追加しない場合でも、後のメンテナはおそらくこれに気付き、window.location.hash.replace(/[^\w]/g, "")を追加します。 （または[^\w-]（ハイフンを使用する場合）。それを避けることによって実際に救われるものはありません。確かに彼らはそれを軽減することができますが、私はこの態度があなたのウェブセキュリティの背後にある主要な力になることはないでしょう。

ユーザー入力の目的は、すべてのサニタイズ入力を処理し、window.location.hashのようなものを既にサニタイズされている「UserHash」変数に保存する特別なJSファイルです。 。これを行わないと、必然的に後で脆弱性につながることがわかりました。誰かが「ああ、ここは安全なのでここで安全だ」と考え、半安全の最前線にあるものを実際の脆弱性に分類します。

0
Nicholas Pipitone