XSSとSQLiの両方に対して脆弱なサイトで達成できること
別の質問に対するコメント（かなり単純に）：
XSSとSQLiを一緒に使用する方法はいくつかあります。
これは私にとっては初めてのことであり、これらの攻撃の両方に対して二重に脆弱なWebサイトで追加の攻撃ベクトルが開かれる可能性があることを知りたいです。私が考えることができる唯一の使用例は、SQLiの脆弱性が許可されたユーザーのみがアクセスできるページに存在する場合です。その場合、XSSはSQLiを実行するために必要な特権を取得する可能性があります。ただし、自分で認証されない限りこのような脆弱性を見つけることはおそらく不可能になるでしょう（その場合、XSSは必要ありません）。そのため、元のコメント投稿者が考えていたシナリオとは思えません。
これら2つがどのようにして相互に構築され、これらの脆弱性の1つでは個別に不可能であるかもしれない何かを一緒に達成するかについての他の考えはありますか？
XSSとSQLiが相互作用する方法は2つあります。あなたが引用したコメントは this 質問からのものであり、明らかに最初の点に関してです。
XSS経由のSQLi
アプリケーションがSQLインジェクションに対して脆弱であることがわかっているが、脆弱なコンポーネントにアクセスするために必要な権限がない場合、既存のXSS脆弱性を利用して、より特権のあるユーザーにSQLインジェクションを実行させることができる場合があります。 。
ご指摘のとおり、アクセスできないコンポーネントの脆弱性を見つけることはそれほど簡単ではないかもしれません。ただし、これが簡単に発生するケースは少なくとも2つあります。
- オープンソースソフトウェア
- ソースコードへの一時的なアクセス（おそらく、外部監査人、メールリーク、不満を持つ元従業員、ソース管理の脆弱性など）
非常に単純なインジェクションの場合、攻撃者は攻撃を推測することもできます（おそらく攻撃者は、アプリケーションがSQLiに対してまったく防御しないことを知っていますが、アクセスできるコンポーネントのすべてのインジェクションは、制限された権限を持つデータベースユーザーを使用しています。ここでは、実際には、他のコンポーネントのスクリプト名とパラメーター名を推測し、XSSを介してそれらを悪用できる可能性があります。
理論的には、より特権のあるユーザーが常により特権のあるデータベースユーザーとのデータベース接続を使用しているセットアップを想像することもできます。そのため、XSSを介してより特権のあるユーザーを介して悪用されると、パブリックコンポーネントへのインジェクションでもより強力になる可能性があります。
最後の例は少し工夫されていますが、確かに可能です。他の例も考えられます。
SQLi経由のXSS
この場合、SQLインジェクションがありますが、実際にそれを使用して興味深いことを達成することはできません。インジェクションは、非常に制限されたデータベースユーザーで行われる可能性があります。たとえば、既に公開されているデータのみを読み取ることができます（ただし、他のデータの読み取り、データの書き込み、システムファイルの書き込みまたは読み取り、コマンドの実行などはできません。脆弱性もありません）。利用できるdbmsで）。
この場合、SQLiを介して反射または保存されたXSS攻撃を実行できる可能性があります。
一例：
- みんながコメントを投稿できるフォーラム
- コメントはデータベースに入れられる前にサニタイズされます。つまり、スクリプトを含める試みはすべて検出されます。
- SQLiではDBに直接アクセスできるため、この方法で既存のコメントを無害化または変更しないコメントを追加できます。これにより、コメントにスクリプトを追加できます。
- フォーラムシステムは、DB内のサニタイズされたコメントを想定しており、DBに保存されているとおりにコメントを表示します。つまり、スクリプトを含む->保存されたXSS