web-dev-qa-db-ja.com

ApacheログファイルからXSS攻撃を識別するための一般的な機能は何ですか？

Webgoat、OWASP mutillidae、bWAPPなどのWebアプリケーションでXSSの脆弱性を試しました。知りたい機能/キーワード/フットプリント Apacheログファイルでのクロスサイトスクリプティング攻撃の=およびこれらのフットプリントから、XSS攻撃が実行されたことを特定できます。すべての種類のXSS攻撃がログファイルから検出できるわけではないことを知っています。しかし、私は可能な限りのXSSタイプの機能をログファイルに保存したいと考えています。以下のように、ログファイルに保存されているフットプリントの例をいくつか示します。

ログファイルのフットプリントは、

1）<script>

2）<img>

3）<iframe>

これらの機能（またはフットプリント）は正しいですか？ XSS攻撃が実行されたことを識別するためにログファイルに保存される他の可能な機能を知っていてもよいですか？アクセスログファイルからXSSを検出するためのアルゴリズムをさらに記述したいと思います。

xssowaspreflected-xssowasp-bwa
2
Shree

ログでクロスサイトスクリプティング（XSS）プローブの一般的な特性を見つけるための一般的なアドバイスをする前に、最初に確立したいことがいくつかあります。

  1. ログを手動で検査することを想定しています。
  2. 一般性を失うことなく、ログのエントリの数についていくことができると仮定しましょう。したがって、特定の瞬間に何千ものリクエストがサーバーにヒットすることはありません。

これらのポイントにより、XSSペイロードをログで見つけることができるプロセスを説明しやすくなります。

私が取り組む最初の問題は、共通の特性を少数のペイロードにまで減らすことです。 XSSは非常に大規模な攻撃ベクトルとシナリオのグループであり、有名なセキュリティ研究者でさえ、特定のタイプのXSS脆弱性を説明するのに適切な用語に同意するのに苦労することがよくあります。これは実際に質問で見ることができます。XSSを3つの特定のペイロード（<script>、<img>、および<iframe>）に削減しようとしています。そこで見つけることができる多くのXSSペイロードリストのいずれかを選択すると、膨大な数のペイロード（たとえば、これ payload.txtリスト ）があることがすぐにわかります。

その上、XSS脆弱性の2つのカテゴリのみをリストしました。

XSSには2つのタイプがあります。つまり、反映されて保存されます。

2種類だけではありません。たとえば、 self-XSS および DOM-based XSS はリストに含まれていません。これらの2つの欠落しているタイプは特に興味深い課題です。これがなぜそうであるのかについては、後で詳しく説明します。

ペイロードのタイプとコンテキスト

XSSベクトルを小さなリストに減らすのは非常に難しいことがわかったので、XSSの脆弱性が発生する一般的なコンテキストをいくつか見てみましょう。ここでの目標は、非常に小さなコンテキストのリストから、一般的な特性がほとんどないか、まったくないさまざまなペイロードを構築する方法を示すことです。

最も注目に値するコンテキストは、HTMLベースとJavaScriptコンテキストです（ここでも、ここで説明を簡略化していますが、さらに多くのコンテキストがあります）。ペイロードと干渉するファイアウォールまたはフィルターがないと仮定すると、これらの前述のコンテキストは通常​​、コンテキストから抜け出すため、またはコンテキスト内でクライアント側のコードを実行するためにペイロードに特定の文字を必要とします。これらのケースのいくつかをよりよく説明するために、私は @ Filedescriptor のXSSポリグロットチャレンジリストを参照します ここ 。 1つ1つすべてを通過するわけではないので、コンテキストに基づいてXSSペイロードを構築する方法を示すためにいくつかを選択することを計画しています。

<div class="{{payload}}"></div>
<div class='{{payload}}'></div>
<title>{{payload}}</title>
<textarea>{{payload}}</textarea>
<style>{{payload}}</style>
<noscript>{{payload}}</noscript>
<noembed>{{payload}}</noembed>
<template>{{payload}}</template>
<frameset>{{payload}}</frameset>
<select><option>{{payload}}</option></select>
<script type="text/template">{{payload}}</script>
<!--{{payload}}-->
<iframe src="{{payload}}"></iframe> (" → )
<iframe srcdoc="{{payload}}"></iframe> (" →  < → )
<script>"{{payload}}"</script> (</script → <\/script)
<script>'{{payload}}'</script> (</script → <\/script)
<script>`{{payload}}`</script> (</script → <\/script)
<script>//{{payload}}</script> (</script → <\/script)
<script>/*{{payload}}*/</script> (</script → <\/script)
<script>"{{payload}}"</script> (</script → <\/script " → \")

上記のすべてのコンテキストをカバーする私の結果のペイロードは：

javascript:"/*\"/*`/*' /*</template></textarea></noembed></noscript></title></style></script>-->&lt;svg onload=/*<html/*/onmouseover=alert()//>

このペイロードはポリグロットとして知られています。つまり、ペイロードは一度に複数のコンテキストをカバーします。最初のコンテキスト（<div class="{{payload}}"></div>）から抜け出すには、二重引用符を使用する必要がありました。 "><svg onload=alert(1)>だけでこのコンテキストで機能します。

次に、最後から2番目のケース<script>/*{{payload}}*/</script>を選択します。物事をシンプルに保つために、チャレンジで実装されたフィルターは無視します。これはJavaScriptコンテキストであり、*/alert(1)/*は複数行コメントから抜け出します。

最後に取り上げるケースについては、フィルターを含めたいと思います。 <iframe srcdoc="{{payload}}"></iframe> (" → < → )は、二重引用符と<文字を置き換えます。このフィルターをバイパスするには、<文字をHTMLエンコードするだけです：&lt;img/src=x onerror=alert(1)>。これは<iframe srcdoc="&lt;img/src=x onerror=alert(1)>"></iframe>になります。このケースでは、コンテキストから抜け出す必要はありませんでした。

3つのコンテキストだけで、3つの非常に異なるペイロードを表示できたことに注意してください。そのため、ログを使用してXSSペイロードを見つける前に、いくつかの一般的なコンテキストをよく理解してください。

+-----------------------------------------------------+----------------------------------+
| Context                                             | Example payload                  |
+-----------------------------------------------------+----------------------------------+
| <div class="{{payload}}"></div>                     | "><svg onload=alert(1)>          |
+-----------------------------------------------------+----------------------------------+
| <script>/*{{payload}}*/</script>                    | */alert(1)/*                     |
+-----------------------------------------------------+----------------------------------+
| <iframe srcdoc="{{payload}}"></iframe> (" →  < → )` | &lt;img/src=x onerror=alert(1)> |
+-----------------------------------------------------+----------------------------------+

攻撃者の視点からの調査

このセクションでは、私が敵対者（より正確には、バグバウンティハンターとしての個人的な経験）がアプリケーションのXSS脆弱性を調査する方法と、これがログでどのように見えるかについて説明します。

ユーザーの入力がどこに反映されているかを手動で判断するために非常に基本的なプロービングベクトルを使用すると考えられる最も注目すべきバグバウンティハンター。したがって、これらのペイロードを反映するさまざまなエンドポイントをすばやく収集するために、'">foobarまたは'"><u>foobarに沿って何かを使用する場合があります。 foobarビットは実際には非常に重要であることに注意してください。ソースコードでペイロードをすばやく検索できるようにしたいので、ハンターはペイロードで一意の文字列を使用することを好みます。あなたの視点から見ると、これはXSSの脆弱性をテストしている場所を確認するために追跡できる指紋の痕跡を残すことを意味します。

これにより、次のプロービング特性が得られます。誰かが単一のエンドポイントを一度テストしてから放棄することはほとんどありません。攻撃者がXSSの脆弱性をスキャンまたは手動でテストしている場合、それらは通常非常に永続的であり、ログにポップアップされた一連の結果的なXSSペイロードが表示されます。

上記のすべてのプロービング特性に加えて、言及しなければならない最後の非常に重要な特性が1つあります。それは、alert、Prompt、confirm。 XSSについて読んでいる間に、これらに遭遇したことは間違いありません。 XSSの脆弱性をテストする場合、脆弱性を即座に示すことが必要になる場合があります。これを行う最も簡単な方法は、顔の前で大きなプロンプトを発射することです。モーダルが表示されたときに、XSSの脆弱性があることがすぐにわかります。また、そのように発砲したペイロードから得たラッシュは古くなることはありません。 :)

enter image description here

alert、Prompt、confirmなどのキーワードのログをgrepできます。とは言っても、コンテキストによっては、ペイロードを調整してこのキーワードをマスクすることが可能なため、これは絶対に確実なことではありません。これは、Webアプリケーションのファイアウォールやフィルターを回避しようとするときによく見られます。

自己XSSとDOMベースのペイロードの特定に関する問題

この問題は、次のように簡単に要約できます。ペイロードが常にログに表示されるとは限りません。このDOMベースのXSS脆弱性の例を見てみましょう：

<!-- test.html -->
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>DOM-based XSS example</title>
</head>
<body>
  <script>
    // Fetch the redirect parameter
    redirect = window.location.hash.substring(1);
    // URL-decode the value
    redirect = decodeURIComponent(redirect);
    if (redirect !== 'UNDEFINED' && redirect !== "") {
        // Redirect to the value
        location.href = redirect;
    }
  </script>
</body>
</html>

http://example.com/test.html#javascript:alert(1)に移動すると、ペイロードにalertボックスが表示されますが、ログを確認すると、パスのみが表示されます。

GET /test.html HTTP/1.1

うまくいけば、この例は、ログで特定のXSSペイロードを見つけようとするときに直面する可能性がある問題のいくつかをよりよく示しています。

この問題に取り組むために私があなたに与えることができる最良のアドバイスは、 report-to ディレクティブで コンテンツセキュリティポリシー （CSP）を実装することです。これで、CSPがポリシー違反を検出するたびに、report-toエンドポイントで通知されます（report-toディレクティブを介してこれらのエラーをログに記録するサービスについては https://report-uri.com/ を参照してください）。エラーのロギングのみに関心がある場合は、Content-Security-Policy-Report-Onlyヘッダーを実装することもできます。

ログでXSSペイロードを手動で見つけるための感覚を得るための小さなアイデア

ここに、私が上で説明したことのすべてを実際に見るのを助けるかもしれない楽しいアイデアがあります。小さなXSS Capture the Flag競争 （CTF）を作成し、アプリケーションのXSS脆弱性を見つけようとするセキュリティ志向の友人のグループを取得します。この間、ログを確認してください。次に、同じことを行いますが、Burp Suiteなどのスキャナーを使用します。しばらくすると、（特定の数のXSSベクトルの）基本的なXSSプローブがログにどのように表示されるかがわかるはずです。

4
EdOverflow

XSSの可能な機能がログファイルに保存される場合は、それらの機能が必要です。

その場合、私は次のようなものに行きます。

grep -ahiP '[{}%<>]+' /var/log/httpd/access_log* | php -R 'print(urldecode(urldecode($argn))."\n");' | grep -aiP "(?:<[\w/?]+)|(?:['\"\s/]*\bon[a-z]+?\s*=['\"\s]*)"

すでに述べたように、コンテキストがありません。ただし、かなりの量のXSSペイロードをカバーしていると確信しています。

さらに、Angularのように、関数呼び出しと式の正規表現（またはその他）を構築する必要があります。

0
1lastBr3ath