Articles

DOMベースのクロスサイトスクリプティング

Posted on

あまり知られていないXSS技術

  • DOMはドキュメントオブジェクトモデルの略
  • XSSはクロスサイトスクリプティングの略
  • DOMベースのXSSと他のXSS脆弱性の主な違いは、ペイロードがサーバー側ではなくクライアント側に埋め込まれていることです
  • DOMベースのXSS脆弱性なので、クライアント側で防止する必要があります

クロスサイトスクリプティング(XSS)の脆弱性 これらの脆弱性は以前に悪用されていましたが、CERT Advisory CA-2000-02(クライアントWeb要求に埋め込まれた悪意のあるHTMLタグ)を通じて知られるようになりました。 だから、XSSはすでにしばらくの間、周りされています。 そして、あなたが期待するように、クロスサイトスクリプティング–過小評価された危険とクロスサイトスクリプティングとスクリプト注入の防止-簡単なガイドを含む、このテーマに関する多くのラボの記事がすでにありました。 しかし、この記事では主にDOMベースのクロスサイトスクリプティングに焦点を当てています。 彼はDOMベースのクロスサイトスクリプティング(XSS)の定義を公表し、他のクロスサイトスクリプティングの脆弱性からそれを描写しました。 DOMベースのクロスサイトスクリプティングを理解するには、まずDOMをより深く理解する必要があります。

DOMとは何ですか?

ドキュメントオブジェクトモデルは、ドキュメントの構造を定義するプログラムインターフェイスです。 私たちの目的に関連するのは、DOMがHTML文書のオブジェクト指向表現を提供することです。:

  • HTML要素がオブジェクトとしてどのように表現されるか
  • HTML要素の属性は何ですか
  • HTML要素にアクセスするために使用できるメソッド
  • HTML要素のイベ….. これは、DOMがHTMLページを操作する機会を提供することを意味します。 最近では、JavaScriptは通常、この種の操作に使用されています。

    各ブラウザはDOM標準を別々に実装していることに注意してください。 これは、特定のDOM XSS攻撃が特定のブラウザで動作するかどうかに影響を与える可能性があります。

    DOMベースのXSSとは何ですか?

    domベースのXSSの脆弱性は、チェックせずに処理できるユーザー入力を含む動的コンテンツを生成するためにDOMが使用されている場合に発生します。 この種の攻撃は、ユーザーのブラウザでJavaScriptを使用して実行されます。 ここでは、(悪意のある)ユーザー入力がDOMにもたらす場所がソースとして指定されます。 DOM内で(悪意のある)ユーザー入力が実行される場所は、シンクとして指定されます。

    単純なクロスサイトスクリプティングの脆弱性の例:

    <!DOCTYPE html><html> <body> <script> var source = "Hello " + decodeURIComponent(location.hash.split("#")); //Source var divElement = document.createElement("div"); divElement.innerHTML = source; //Sink document.body.appendChild(divElement); </script> </body></html>

    この脆弱性は、たとえば、次のGET要求でトリガーされる可能性があります:

    GET www.vulnerable-website.example#<img src="test" onerror="alert('XSS')">

    この例では、decodeURIComponentメソッドを使用する必要があることがわかります。 これは、最新のブラウザがURL内の特殊文字をエンコードし、これらの特殊文字がデコードされないと攻撃が機能しないためです。 変数sourceの内容は、innerHTMLを使用してdiv要素に追加されます。 これは、innerHTMLへの代入により、それに含まれる値がHTMLとして解釈されるため、コード内の問題のある要素です。 値にJavaScriptが含まれている場合は、これも実行されます。

    これはサーバーの応答を変更しないことを指摘する必要があります。 悪意のある変更は、JAVASCRIPTコードがクライアント側で実行され、その後DOMが変更された場合にのみ発生します。

    最もよく知られているソースとシンクを以下に示します。 これは決して網羅的なリストではないことに留意すべきである。

    ソース

    • ドキュメント。URL
    • ドキュメント。参照元
    • 場所
    • 場所。href
    • 場所。
    • の場所を検索します。ハッシュ
    • 場所。パス名

    シンク

    • eval
    • setTimeout
    • setInterval
    • ドキュメント。
    • 要素を記述します。innerHTML

    DOMベースのXSSの防止

    ペイロードが実際にサーバーに送信されない場合があるため、この脆弱性を防止することはサーバー側の作業ではありません。 上記の例はそのようなケースの1つです。 その理由は、#文字の後に表示されるコンテンツがブラウザによってサーバーに送信されないためです。

    最初の最も重要な推奨事項は、可能な限りコンテンツの動的生成にユーザー制御データを使用しないようにすることです。 これが完全に避けられない場合、DOMベースのXSSを防ぐ最善の方法は、悪意を持って埋め込まれたコードの実行を防ぐ安全な出力メソッド(シンク)を使用す 上記のコードスニペットでは、コードを安全にする唯一の方法は、.innerHTML.textContentに置き換えることです。 これは、innerHtmlとは異なり、textContentメソッドのHTML要素が実行されないためです。

    OWASPのDOMベースのXSS防止チートシートには、javascriptを使用して安全な動的webサイトを開発するための有用なヒントがたくさんあります。 ここには、安全な出力方法に切り替えることが不可能なときに必要なコンテキスト依存エンコーディングの説明もあります。

    他のXSS脆弱性との違い

    最も重要な違いは、攻撃がコードに埋め込まれている場所です。 他のクロスサイトスクリプティングの脆弱性とは対照的に、コードはサーバー側ではなくクライアント側に埋め込まれています。 これは、ペイロードが応答コード内に見つからないことを意味します。 したがって、DOMベースのXSS脆弱性は、実行時またはwebサイトのDOMを確認することによってのみ検出できます。

    ほとんどの場合、DOMベースのXSSの脆弱性を見つけるのは簡単なことではありません。 静的コード分析アプローチを使用する有用なアプローチの1つは、記事Burp based-xssで説明されています。

    著者について

    アンドレア-ハウザー

    Andrea Hauserは、応用科学大学Rapperswilで情報技術の科学FHOの学士号を取得して卒業しました。 彼女は、webアプリケーションのセキュリティテストとソーシャルエンジニアリングキャンペーンの実現に攻撃的な仕事に焦点を当てています。 彼女の研究の焦点は、deepfakesを作成し、分析しています。 (ORCID0000-0002-5161-8658)

    リンク集

    • http://www.webappsec.org/projects/articles/071105.html
    • https://support.portswigger.net/customer/portal/articles/2325926-using-burp-scanner-to-test-for-dom
    • https://www.cert.org/historical/advisories/CA-2000-02.cfm
    • https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
    • https://www.w3.org/DOM/

コメントを残す

メールアドレスが公開されることはありません。