Digging Deep Into Dom XSS からXSS DOM を学ぶ

Bug Report

ソース：

medium.com

脆弱性：XSS DOM

 

訳：

Burp suite pro を使用すると、それがいくらか簡単になりますが、それでもスキャン結果を解釈して脆弱性を悪用できる必要があります。
多くのハッカーが失敗するのはここです。
これは遊びでやるものではなく、真剣なビジネスです。

この脆弱性は検出が難しいため気づかれないことが多く、実稼働環境では非常に一般的であることを意味し。 

ラボがまだ存在しない場合は、DOM XSS ラボがすぐに続きますが、最初にテキストの壁を突破する必要があります。

 

この質問に取り組むには、まず DOM とは何なのかを答える必要があります。
このトピックは非常に複雑になる可能性があり、Web ページの構築方法にまで遡るため、あまり深くは説明しません。
Web ページのソース コードを見る場合、DOM は技術的には DOM を表示することさえありません。
DOM は 1 ステップ戻って Web ページが JavaScript にどのように構築されるかを記述し、JS がその DOM をオブジェクトに変換して操作できるようにします。
DOM を適切に検査するには、 ソースを検査するのではなく、開発者コンソールを使用する必要があることを意味します。

 

DOM XSS の脆弱性は通常、いわゆる「DOM ソース」を介して DOM に渡される入力を制御できる場合に発生します。入力は、動的コード実行をサポートする「DOM シンク」に渡されます。 例としては、 eval() 、 document.write() などがあります。 

 

よく知られているソースベースの XSS と同様に、DOM XSS も、ソースベースの XSS と同じルールに従う反映バリアントと保存バリアントを認識します。
変数が GET または POST パラメーターからこれらのシンクのいずれかに反映されている場合、反映された DOM XSS について話します。
変数が DB に保存されている値に由来する場合、保存された DOM XSS について話します。 

 

DOM シンクについて話すときは、ユーザーが制御するデータが DOM に入る場所について話します。 DOM シンクには 3 種類あり、それらすべてについて説明します。

 

 

someDOMElement.innerHTML

 

この例では、DOM 内の要素の innerHTML について話しています。
ドキュメント内の要素と対話しているため、これはドキュメント シンクです。

通常の「<script>alert(1)</script>」は、他のいくつかの攻撃ベクトル以外では機能しないことに注意することが非常に重要です。
これは、単なる値の反映ではなく DOM の挿入であるためです。
DOM 挿入について話すとき。 これが、ラットおじさんが常に次の方法でテストする理由の 1 つです。

 

<img src=x onerror=confirm()>

 

さらにいくつかの例: 

 

someDOMElement.innerHTML
someDOMElement.outerHTML
someDOMElement.insertAdjacentHTML
document.write()
document.writeln()

 

ロケーションシンク

 

document.domain

 

この例では、ドメインと通信しています。
Document インターフェイスのドメイン プロパティは、現在のドキュメントの元のドメイン部分を取得または設定します。
これは、私たちが位置を制御し、位置シンクと通信していることを意味します。
ロケーションシンクでは通常、JavaScript 疑似プロトコルを使用する必要があります。 

 

疑似プロトコルの例: ( http://blabla.com/test?url=javascirpt:alert() )

 

ロケーション シンクのその他の例。

 

document.location
window.location.assign()
window.location.replace()

 

 

eval()
setTimeout()
setInterval()
Function()

 

実行シンクでは、攻撃者としてシステムに入力したデータで JavaScript コード自体のコードを更新します。

現実には、これらのシンクが保護されていないことに気づくことはほとんどありません。
多くの場合、悪意のあるコードが入力されていないかどうかをチェックするテストをバイパスする必要がありますが、これらのチェックは通常開発者によって構築されるため、ロジックに欠陥がある場合はバイパスできます。そのチェック。

 

ソースは、攻撃者によって制御されている可能性のあるデータを受け入れる JavaScript プロパティです。
ソースの例は location.search プロパティです。
このプロパティはクエリ文字列から入力を読み取るため、攻撃者にとっては比較的簡単に制御できます。
最終的には、攻撃者が制御できるあらゆるプロパティが潜在的なソースとなります。
これには、参照 URL (document.referrer 文字列によって公開される)、ユーザーの Cookie (document.cookie 文字列によって公開される)、および Web メッセージが含まれます。

一般的なソース:

 

document.URL
document.documentURI
document.URLUnencoded
document.baseURI
location
document.cookie
document.referrer
window.name
history.pushState
history.replaceState
localStorage
sessionStorage

 

DOM XSS のテストは、ソースベースの XSS のテストほど単純ではありません。
値はソース コードではなく DOM に表示されるため、これをテストするには開発者ツールを使用する必要があります。

 

ドキュメント シンクをテストするには、以下を行う必要があります。

  • すべてのドキュメント ソース (location.search など) にランダムな値を入力します。
  • 次に、開発者ツールを開いて、ドキュメント シンクが参照されているすべての場所を探す必要があります。
  • 「var x=document.location」のようになります。
  • 次に、変数 x が使用されている場所をすべて調べて、それが HTML シンクに渡されているかどうかを確認する必要があります。
  • これには、開発者コンソールに組み込まれているデバッガーを使用できます。
  • 次に、通常の HTML XSS ルーチンを適用する必要があります

URL エンコードに関してはブラウザーの動作が異なることに注意してください。Chrome、Firefox、Safari は location.search と location.hash を URL エンコードしますが、IE11 と Microsoft Edge (Chromium 以前) はこれらのソースを URL エンコードしません。
データが処理される前に URL エンコードされると、XSS 攻撃が機能する可能性は低くなります。

 

JS 実行シンクのテストは少し難しくなります。
これらのシンクでは、入力が DOM 内のどこにも表示されず、検索が不可能になる場合があります。
この場合、JS デバッガーを使用して、入力がシンクに渡されているかどうかを確認する必要があります。

  • すべてのドキュメント ソース (location.search など) にランダムな値を入力します。
  • ソースから値が読み取られている場所がわかったら、デバッガーを使用してブレークポイントを設定できます。
  • デバッガーでこの変数を追跡し (次のステップまたはステップ オーバー)、DOM シンクに渡されているかどうかを確認します。
  • 途中でソースが複数の変数または他の変数に割り当てられた場合は、それらの変数も追跡する必要があります。
  • シンクが見つかったら、通常の XSS 攻撃戦略が実行されます。

 

ほなほな。