An Interesting Case of XSS Caused by File Upload から学ぶ

ソース：

medium.com

脆弱性：ファイルアップロード

訳：

今日は、報奨金プロジェクトで発見した、ファイルのアップロードによって引き起こされる XSS という興味深い脆弱性を共有したいと。

脆弱な機能はターゲットのフィードバック セクションにあり、画像ファイルをアップロードできるようになり。

データパケットを見てみましょう。

最初の試み。filename=”1713317086261.jpg” を filename=”1713317086261.svg” に変更

以下のようにうまく動作しなかったようで。（SVGファイルへのパスにアクセスできなかったため） 

そこで、2回目の挑戦をして。

name=”help/フィードバック/6/1aba210f-4f0a-3c4d-bdbf-094478beec61.jpg” を name=”help/フィードバック/6/1aba210f-4f0a-3c4d-bdbf-094478beec61.svg” に変更しました。

すると、エラーになり。

私は努力を続けました。 

svg、html、xmlを試してみましたが、いずれもエラーが発生し。

諦めかけたとき、ふとxhtmlをやってみようと思いつき。

それで、試してみたところ、はい、うまくいきました。

その後、ファイルのコンテンツを XSS ペイロードに変更し、アップロードしてアクセスし。

ほなほな。

XXE with ChatGPT から学ぶ

ソース：

medium.com

脆弱性：XXE

訳：

1. 基本的な XXE

まず、ターゲット Web アプリで使用される特定の XML 構造用にカスタマイズされた基本的な XXE ペイロードから始めて。

プロンプト：

Provide an example of a safe XXE payload that you can use for testing purposes for a blind XXE PoC that uses <burp collaborator> for the domain for the following .xml file and maintain the structure of the XML content:

<insert XML>

使い方：

1. XML ドキュメントは、という新しいエンティティを宣言し。
   xxeこれはBurp Collaboratorサーバー上のリソースを指し。
2. 次に、ドキュメントは子要素でこのエンティティを参照し。
3. アプリケーションはドキュメントを解析するときに、XXE 脆弱性の検出に使用できるリソースの取得を試みて。

2.SVG画像ファイルXXE

SVG (Scalable Vector Graphics) ファイルは XML ベースのベクター画像ファイルであり、XML ファイルと同様に XXE 攻撃に対して脆弱になる可能性があり。

プロンプト：

Provide an example of a safe XXE payload that you can use for testing purposes for a blind XXE PoC that uses <burp collaborator> for the domain for the following .svg file and maintain the structure of the XML content:

<insert XML>

3. Excel ファイル XXE

新しい Microsoft Excel .xlsxファイルには埋め込み XML ファイルが含まれているため、依然として XXE 攻撃に対して脆弱になる可能性があり。

埋め込まれた XML ファイルを変更するには、次の手順を実行し。

1. の内容を抽出します。 .xlsxファイル。
2. ChatGPT プロンプトを使用して、テキスト エディタで XML ファイルを編集し。
3. コンテンツを再圧縮して。
4. の名前を変更します .zipファイルを元に戻す .xlsx.

Provide an example of a safe XXE payload that you can use for testing purposes for a blind XXE PoC that uses <burp collaborator> for the domain for the following sharedStrings.xml extracted from a .xlsx file and maintains the structure of the XML content:

<insert XML>

ほなほな。

Race Condition and Broken Access Control on Developer Dashboard から学ぶ

ソース：

jeewanbhatta.medium.com

脆弱性：RaceCondition、BAC

訳：

このレポートでは、ターゲット Web サイトで発見された 2 つの脆弱性、競合状態とアクセス制御 (BAC) の問題を明らかにして。

つまり、ターゲットは自己ホスト型プログラムであり、報酬は Critical、High、Medium のみで。
サブドメインの列挙からテストを開始し、ライブサブドメインを除外し。
サブドメインを 1 つずつテストした後、ログイン/登録機能のある「developer.target.com」の開発者ダッシュボードを見つけ。
ただし、ログインはメインドメイン「target.com」から行う必要があり、その場合のみユーザーが開発者ダッシュボードにリダイレクトされて。

ここから実際のテストが始まり。
ダッシュボードの [マイ アプリ] タブをクリックすると、ユーザーが SDK アプリの構築をリクエストし、REST API にアクセスするためのフォームが開き。
フォームには、名前、電子メール、会社の URL、その他多くのフィールドを含むさまざまなフィールドが含まれていて。
フォームはログインしたアカウントからアクセスされたため、電子メールフィールドにはログインしたユーザーの電子メールアドレスが自動的に入力され。
したがって、ユーザーはランダムな電子メール アドレスやその他の電子メールアドレスを提供することはできず。

Auto filled user’s email

しかし、リクエストを傍受し、被害者の電子メールに変更すると、その後、被害者に代わってフォームが送信されることになり。
その後、被害者はフォームの送信が成功したことを示す確認メールを受け取り。
これだけでなく、被害者の電子メールからリクエストの送信が成功した場合、リクエストフォームは 1 つのアカウントに対して 1 回のみ利用可能であるため、被害者は自分側から別のフォームリクエストを送信することはできません。
この BAC により、被害者はアプリを作成したり、新しいアプリの作成をリクエストしたりすることができません。

上記の文でお気づきかと思いますが、フォームの送信はアカウントに対して 1 回限りであると述べました。
フォームが一度正常に送信された場合、URL にアクセスすると、次のように表示されることを意味します。

リクエストの送信が成功した後

また、ユーザーはフォームを 2 回送信することはできず。
ここで競合状態の脆弱性をテストしてみてはいかがでしょうか。
次に、げっぷ履歴に移動して、そのフォーム送信リクエストを Burp 侵入者に送信し、同時リクエストを 1 秒あたり 100 リクエストに設定し。
攻撃が成功した後、確認メールがないかメールをチェックし。
そして、500 件の同時リクエストのうち、約 250 件のリクエストが成功したことを推測でき。
また、アカウントごとに複数のアプリ リクエスト フォームを送信することができて。

約 250 件のフォーム送信リクエストが成功

ほなほな。