SSTI to XSS using curly braces {} から学ぶ

対象シナリオ

  • XSS に対して脆弱なエンドポイントを見つけるために何時間も苦労した結果、最終的に興味深いと思われるエンドポイントを見つけました。
  • それはサインアップページを公開していました。
    これの興味深い点は、それが隠されていたことです。
    URL は次のようになりました。

https://www.redacted.com/engine/signup/create.php

  • そこで XSS ペイロードを試しましたが、すべてがフィルタリングされていました。
    そこで私は、姓、名、住所のフィールドに中括弧 {} を追加することを思いつきました。
  • 驚いたことに、3 つのフィールドすべてで中括弧に対する特定のフィルタリングが実行されていませんでした。
  • 次のペイロードを試しました:-

{{ <svg/onload=prompt("XSS")> }}

  • ペイロードが複雑に見えることはわかっています。 すべてのエンティティが URL エンコードされているというだけです。
    デコードされたペイロードは次のようになります。

{{ <svg/onload=prompt(“XSS”)> }}

 

自己 XSS から保存された XSS

  • 対象の Web サイトには、プロジェクトを作成できるセクションがありました。 プロジェクトは、ファイルを保存できるフォルダーであると考えてください。
  • プロジェクト管理者は、これを他の「認証されたユーザー」と共有できます。
  • プロジェクトには名前を付け、リンクを使用して共有する必要があります。
  • さて、私はプロジェクトにペイロードを付けて名前を付けました。
    したがって、ファイル名は次のようになります:-

{{ &lt;svg/onload=prompt(&quot;XSS&quot;)&gt; }}

 

  • ファイル名の制限は維持されず、好きなようにプロジェクトに名前を付けることができました。
  • プロジェクトの共有リンクをコピーし、他の認証されたユーザーに送信します。 前に述べたように、認証されたユーザーのみがプロジェクトを表示できます。
    したがって、アプリケーションは、共有プロジェクトを表示する前にユーザーにログインを強制します。
  • 認証されたユーザーがリンクをクリックすると、出来上がりです。 XSS ポップアップ。

 

簡単な要約

  • SSTI ベースの Self-XSS ペイロードが作成されました。
  • Self-XSS は Reflected XSSエスカレーションされました (攻撃シナリオによって異なります)。
  • SSTI → 自己 XSS → 反射型 XSS
  • 実際、これはさらに深刻になる可能性があります。 攻撃者はプロジェクトを作成し、そのリンクをソーシャル メディアで共有するだけで済みます。 認証されたユーザーが偶然リンクをクリックすると、XSS がトリガーされる可能性があります。

 

ほなほな。