('ω')ノ統合サービスでIDORを使用した機密データの漏洩を。Dorksこのブログ投稿全体を通して、Redacted.comとすることに。理解を深めるために、調査やクイズなどのフォームを生成して。それらのフォームから回答を収集して。他のサービスと統合するためのアプリであることをお伝えしておいて。ほとんどの場合、ハンティング中にビジネスロジック、IDOR、および。サーバ側のバグを探して。事前に定義された方法や固定された方法には従わず、基本的な調整を行って。通常のアプリケーションの流れを理解してから、ハンティングに進むことに。このバグは統合機能にあって。最初にこの機能の基本的なフローについて説明して。次にこのバグをどのように見つけたかを段階的に説明するこに。さまざまなプラットフォームに接続するセクションがあって。所有者は、この機能を使用して自分のフォームをこのアプリの1つに統合して。統合されたアプリでフォームの応答を受け取ることができて。統合に利用できるすべてのプラットフォームを調べているときに。Sellと統合するオプションに出くわすことに。Sellは、連絡先などの販売データを分析するためのアプリケーションで。したがって、この機能のフローは統合プロセスが開始されると。フォームIDを受け取って、リクエストフローを。サードパーティのアプリケーションに転送して。サードパーティアプリケーションでは。Sellアカウントの設定、承認の付与、フォームの質問のマップを。Sellのフィールドに要求して。これが正常に行われると。Sellのフィールドにマッピングされて。https://www.zendesk.com/リクエストフローを確認したところ。統合を開始するための最初のGETリクエストが生成されて。次にサードパーティに認証とマッピングを構成するリクエストが生成されて。最後に統合を有効にするための。PATCH要求が生成されていることがわかって。GET要求とPATCH要求はどちらも、form_idパラメータのIDORに対して脆弱だったので。アプリケーションをテストするために2つのアカウントを作成して。1つは攻撃者として、もう1つは被害者として作成しまして。下記のように、統合を開始してGETリクエストを傍受して。form_idを被害者のform_idに置き換えることに。form_id=o310DGform_idを被害者のform_idに置き換えた後に傍受をオフにして。認証とマッピングのページに移動して。Sellアカウントを攻撃者として構成して、権限を付与して。下記は、被害者フォームの質問を。Sellアカウントフィールドにマッピングされたところで。この構成を完了した後に、統合を有効にするための。PATCH要求である次の要求をインターセプトして。form_idを被害者のform_idに置き換えて。攻撃者のアカウントでこの統合プロセスを完了した後に。動作するかどうかを確認するために、被害者のアカウントにログインしたところ。統合が有効になっていることがわかって。form_id=o310DGさらにテストするために、私は訪問者としてフォームに記入して。Sellアカウントで。受け取った応答を確認すると。Sellアカウントでフォーム応答を受け取って。Sellアカウントに対する被害者フォームの。受信応答で作成されていて。問題は、form_idを列挙してフォームをZendeskアカウントと統合する方法で。このフォームを共有するためのリンクには、Zendeskアカウントと統合して。これらのフォームに入力されたすべての機密データを。受信するために使用できるform_id値が含まれていたため。列挙は非常に単純なタスクで。dorkでform_idを公開して。要約すると、この統合プロセスでIDORを使用すると。Sellアカウントを。任意のフォームと統合して、フォーム応答として。受信したすべての機密データをフェッチできて。あなたの最後の息までハックを。(3)引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。