web-dev-qa-db-ja.com

反映されたXSSは現在も関連していますか？

私はXSSについてもっと学びました（不慣れな人にとっては Excess XSS は素晴らしいリソースです）。私は手を汚して、Reflected XSSをローカル環境で試してみることにしました。非常に単純な脆弱なPHPページをApache2で実行するように設定しました。これはURLパラメータを受け取り、コンテンツをページにダンプします：

<!DOCTYPE html>
<html>
<head>
    <title>VULNERABLE WEBSITE</title>
</head>
<body style="background-color:#98FB98">
    <h1>VULNERABLE WEBSITE</h1>
    <p>Search results for <?php echo $_GET['query']; ?>:</p>
</body>
</html>

次に、次のようなURLを使用して、「悪意のある」JavaScriptをページに埋め込もうとしました。

http://localhost:8082/?query=<script>alert('Hello!');</script>

ブラウザ自体がこれを防ぐのに気づきました。 Firefoxでは、これによりGoogle検索ページが表示されました。 Chromiumでは、XSSが明確に検出され、ブロックされました。

enter image description here

だから、理論から実践に移って、私は今疑問に思っています：Reflected XSSは今日でも関連するセキュリティ問題ですか？

これは明らかに、悪意のあるコンテンツがWebサイト自体によって直接提供される永続的なXSSには適用されません。

xssjavascriptreflected-xss
33
Gigi

反映されたXSSはGETだけではありません。 POSTでも可能です。また、ブラウザによって常に防止されるわけではありません。もちろん、依然として関連性があります。

いくつかの定義：

そして、Checkmarxナレッジベースから、「最も一般的に見られるXSS」と書かれています。 here から抽出。だから、もし最も一般的に見つかるなら、私はまだ関係があると思います。

20
OscarAkaElvis

はい、すべての形式のXSSが現在も関連しています。

あなたが試みた特定の攻撃は、ブラウザがヒューリスティックを見つけることが明らかでしたが、より微妙な注入によって生成されたコードはそうではない可能性があります。開発者が<form action="{$_SERVER['PHP_SELF']}"を使用したためにフォームの送信URLを変更するとどうなりますか？エラーメッセージを確認メッセージに変更するとどうなりますか？ダウンロードしたLinuxディストリビューションの表示されるSHA1ハッシュを変更するとどうなりますか？

ユーザーにセキュリティを提供するために、クライアント側の機能（特にWebブラウザ）に依存しないでください。

16
dotancohen

反映されたXSSの最も一般的で些細なケース—提供されたもの（_<?php echo $_GET['query']; ?>_）を文字どおり正確に出力し、現状のまま実行されます—は、デフォルトでは最近のブラウザーに実質的に関連していません。

ただし、カテゴリーとしての「反映されたXSS」は、それよりも少し広いです。また、入力が何らかの方法でエンコードされている場合も含まれます。私が実際に目にした1つの例は、<?php echo base64_decode($_GET['query']); ?>などのbase64でエンコードされたHTMLのリフレクションです。ブラウザのフィルタはおそらくそれをキャッチしません。

また、コードが単独で実行されない場合も考慮する必要がありますが、後で実行される原因となる他のJavaScriptもあります。これが発生する最も一般的な方法は、クライアント側のテンプレートライブラリで、それがなければ静的テキストであるものの式を解釈します。たとえば、_dyn-_属性がいくつかのモデルデータを使用してクライアント側で評価されるこのケースを考えます。

_<img dyn-src="model.get('<?php echo $_GET['name']; ?>')" />
<script>
  let model = { something... };
  for (let el of document.querySelectorAll('[dyn-src]')) {
    el.src = eval(el.getAttribute('dyn-src'));
  }
</script>
_

これにより、?name=', alert('xss'), 'のようなものを備えた、反映されたXSSの形式が可能になります。これも、ブラウザーではおそらくキャッチされません。

9
Jeremy Banks

すべてのブラウザーが同じ方法で同じフィルターを実装するわけではないため、反映されたXSSは依然として関連しています。一部の実装ではバイパスが検出される場合があり、監査者はそれをブロックしない場合があります。

一部のサイトにはX-XSS-Protectionヘッダーが有効になっているため、これらのサイトも脆弱です

そして、他の回答で述べたように、ペイロードはPOSTではなくGETを介して配信される可能性があり、監査人が悪意のある注入をブロックするのを防ぎます

最後に、すべてが正しく構成されていて、フィルター実装のための既知のバイパスがない場合でも、それは単なるフィルターです。特定の反映されたXSSをブロックしますが、誤検知があるため、誤検知が多すぎるため、ペイロードは検出されないままになります

5
Mr. E

はい。

1つには、FirefoxにはまだXSSフィルターがないため、このブラウザーで反映された攻撃が実行される可能性があります。

また、DOMベースのXSSはブラウザーフィルターをバイパスします。 これは厳密に「反映されたXSS」として分類されません ですが、最終結果は同じです。

もう1つ覚えておかなければならないのは、ブラウザーのXSS監査はセキュリティ境界を構成しないことです。 Google から：

いいえ、XSS監査バイパスは、Chrome=セキュリティの脆弱性を構成していません（このため、このバグにSecSeverity-Noneのフラグが付けられています）。重大度のガイドラインは次の場所にあります http：// dev.chromium.org/developers/severity-guidelines

もう少し明確にするために、XSS監査は、Webサイトの一般的なXSS脆弱性からユーザーを保護する多層防御メカニズムです。事実、XSSのすべてのバリアントをキャッチできるわけではないことはわかっています。キャッチできるものは、影響を受けるサイトで修正する必要があります。したがって、監査人は本当にユーザーのための追加のセーフティネットですが、強力なセキュリティメカニズムとして意図されていません。

このようなブラウザのメカニズムには常にバイパスが見られます。 IEの例はこちら 。そして、ここでの別の答えとは反対に、 フィルターはPOSTリクエストも）をブロックしようとします 。ただし、これらのフィルターに依存してすべてのXSSをブロックすることはできません。

その結果、出力エンコーディング、入力フィルタリング/検証（可能な場合）、そしてできれば強力なコンテンツセキュリティポリシーを使用して、WebアプリケーションのXSSを軽減する必要があります。

入力のフィルタリングと検証は難しい場合がありますが、有効な入力が数字と文字のみである入力を行う場合、安全なアプリケーションが必要な場合は、文字セットを有用なものだけに制限することをお勧めします。もちろん、これは、コードスニペットなど、大きな文字セットを使用することを許可しているStack Overflowスタイルのサイトを実行している場合は不可能です。

反映されたXSSでは、ユーザーがURLをたどる、またはURLにリダイレクトされる必要があることに注意してください。したがって、攻撃者が悪用するために少し「ソーシャルエンジニアリング」が必要になる場合があります。私は通常、反射されたXSSを中リスクの脆弱性として分類します。ただし、アプリケーション内から自動的に悪用できる場合（たとえば、自動リダイレクトなど）や、アプリケーション自体が特に機密性が高い場合を除きます。

2
SilverlightFox

はい：

  • 既知のセキュリティ脆弱性を修正しないことは常に悪い考えですが、それだけではありません...
  • 反映されたXSSをブロックしようとした主要なブラウザーは、テクノロジの廃止を検討しています

この質問の出所を理解していますが、残念ながらテクノロジーは完璧ではなく、攻撃者を阻止することはほとんどありません。

過去3か月間に、XSSAuditorをトリガーするすべての内部XSSバグを調査し、それらすべてのバイパスを見つけることができました。

それが Chromium、XSSAuditorを削除するようChromeにアドバイスを発表 のチームです。与えられた理由はこれです：

XSSAuditorがXSSを停止するという証拠は見つかりませんでした。代わりに、大規模な開発者に、ブラウザが攻撃を停止したと言ってもバグを修正する理由を説明するのに苦労しています。

また、修正プログラムを適用する必要があるかどうかを開発者に不思議に思わせるだけでなく、セキュリティテスターの作業効率も低下します。彼らは（時には時間がかかる）バイパスを見つけることなしにそれがリスクであることを正当化するのに苦労しているので：

さらに、セキュリティペンテスターを調査したところ、XSSAuditorのバイパスを見つけられない限り、脆弱性が報告されないことがわかりました。つまり、防御チームは攻撃者よりも多くのハンディキャップを受けることになります（防御チームは、防御チームがスケールアップする必要があるため、防御チームとして）攻撃者は動作するものだけを必要とするが、その修復努力。

マイクロソフトは彼らの推論についてはそれほど控え目ではありませんが、 XSSフィルターを廃止することを昨年6月に発表 ：

廃止されたXSSフィルター：今日のビルドから、Microsoft EdgeのXSSフィルターは廃止されます。 コンテンツセキュリティポリシー のような最新の標準により、お客様は引き続き保護されます コンテンツブラウザーへの高い互換性 。

このトピックに関するもう1つの優れたブログ投稿は次のとおりです。 https://portswigger.net/daily-swig/xss-protection-disappears-from-Microsoft-Edge
たとえば、MSIEのXSSフィルターが、本来なら悪用可能ではなかったであろう脆弱性につながることがあるという研究へのリンクです。

1
Luc

はい、これはまだ関連しています。あなたのサンプルをフォローしてみてください：

http://localhost:8082/?query=<svg onload="alert('Hello!')"/>
0
Aleksandr Ryabov