ログイン後に発生する保存されたXSSが脆弱性であることを正当化する方法

Question

Webアプリケーションでセキュリティテストを実行しました。以下はシナリオです。

有効な認証情報でアプリケーションにログインしました。
ログイン後にのみ表示される特定の機能には2つのフィールドがあります。
Cookie情報、ドメイン情報を含むアラートボックスを生成するXSSペイロードを提供し、その機能を保存しました。
ユーザーがその機能にアクセスするたびに、提供されたスクリプトが実行され、Cookie情報を含むアラートボックスが継続的に生成されます。

しかし、開発チームによると、ログインしない限り、スクリプトを入力として与えることはできないため、これは無効なシナリオです。

それでは、それが有効なシナリオであり、アプリケーションにとって潜在的なリスクであることをどのように正当化できますか？

tim · Answer

開発チームは間違っています。ここでの影響は、水平および垂直の特権昇格です。

認証後のXSSは、認証前のXSSと同じように有効です。一般に、あなたはwant被害者の現在の認証を利用したいので、とにかくログインする必要があります。唯一の問題を緩和する要素は、攻撃者がアカウントを必要とすることです。どれだけ簡単に取得できるかに応じて、問題の影響度は下がりますが、それでも脆弱性です[*]。

攻撃者はXSSを使用して、ペイロードを含むページにアクセスするユーザーの名前で任意のアクションを実行し、それらのユーザーがアクセスできるデータを読み取ることができます。

_{[*]一部のユーザーにとって、これは許容されるリスクである可能性があることに注意してください。たとえば、一部のアプリケーションでは、XSSがなくても無制限にアクセスできるため、管理者はフィルタリングされていないHTMLを投稿できます。}

_{ペイロードが自分で挿入するユーザーにのみ表示される場合は、別の問題になります。（クリックジャッキングやCSRFを介して）ユーザーにデータを入力させるか、または（セッションの固定やCSRFへのログインを介して）ペイロードを配置したアカウントにユーザーをログインさせることによってのみ、悪用できます。}

Omer Iqbal · Answer

アプリをハングさせるスクリプトを作成し、ログインしているすべてのユーザーに対して実行できるようにします。

より高度な攻撃を行う場合は、APIを呼び出してユーザーのプロファイル情報またはその他のデータを変更するスクリプトを挿入します（スクリプトはCookieにアクセスできるため、Cookieに依存するそのドメインで呼び出しを行うことができます認証）。また、ユーザーのプロファイル情報を取得して画面に表示することもできます（攻撃者がこのすべてのデータにアクセスできることを示すため）。

さらに別の手順として、ユーザー名とパスワードを要求するUI（「セッションの有効期限が切れました。続行するにはユーザー名とパスワードを入力してください」などのメッセージが表示されます）を表示し、それまではアプリの使用をユーザーに許可しません。パスワードが正しいことを確認しました（たとえば、一部の認証エンドポイントに対して）。パスワードをどこにも保存する必要はありません。この時点で、スクリプト作成者が自分のサーバーにパスワードを送信できることを示しているだけです。

どれだけ構築する必要があるかは、どれだけ説得力のあることを行う必要があるかによって異なります。また、悪意のあるユーザーがこれを行う必要がないことを伝えることで、自分がいいことをしていることを彼らに知らせることもできます。

アプリが任意のユーザーに開かれていて（つまり、誰でも登録できる）、攻撃を実行する場合は、新しいユーザーを謎めいた名前で登録し、デモするだけです。

ログインしたユーザーが内部の従業員のみの場合、それは従業員間の信頼に帰着します。インサイダー脅威は非常に正当な懸念事項です。

TBridges42 · Answer

唯一の優れた防御は、深層防御です。現時点では、認証スキームは安全に思えるかもしれません。しかし、いつの日か、攻撃者、あなた、またはすでに認証されている不満のある内部関係者によって、脆弱性が見つかるでしょう。

彼らが適切な多層防御を実行している場合、その敵対的なエージェントがシステムにアクセスできるようになると、彼らが行うことができる損害は、さらなるセキュリティメカニズムによって制限されます。ただし、脆弱性は外部の脅威によって実行される場合にのみカウントされるという彼らの態度で、追加の防御ラインを作成する機会を完全に捨てています。

したがって、たとえば、制限付きのユーザーアクセスしか取得できなかった攻撃者は、管理者の資格情報を取得する可能性があります。彼らの認可スキームは脆弱です。または、低給の従業員が、すべてのユーザーのクライアントでJSベースの暗号通貨マイナーを実行して、少し余分な現金を獲得することを決定することができます。または、財務/管理の外部のユーザーが、内部の取引のために内部情報にアクセスする可能性があります。

ログインする必要があるので、XSSと言っても問題ありません。機能的には、ログインしているすべてのユーザーが、他のすべてのログインユーザーが行うことをすべて表示および実行する権限を持っている必要があるということです。ユーザー対管理者、部門のプライバシー、ユーザーの否認防止はありません。すべてのユーザー、機能的に区別できません。それが彼らのユースケースに当てはまらない場合、XSSは彼らが心配すべき悪用可能な脆弱性です。

編集：上記のいずれも起こり得ないと確信している場合は、認証スキームに対するソーシャルエンジニアリング攻撃に切り替えることをお勧めします。最も安全な認証スキームは依然として人間の相互作用を必要とするため、憂慮すべきほど脆弱です。