Exploiting an IDOR that deletes Victim’s job alert から学ぶ

ソース:

medium.com

脆弱性:IDOR

 

訳:

のプログラムのスコープには「app.target.com」と「api.target.com」のみが含まれていました。
そのため、特徴や機能を直接理解するのは非常に簡単でした。
の Web アプリは、ユーザーが希望の求人を検索して、お気に入りの求人に応募する、求人ポータルのようなものでした。
アプリケーションの機能を少し試してみたところ、ユーザーは将来興味を持ちそうな仕事に関する電子メール アラートを作成できることがわかりました。
そこで、ジョブの 1 つに対して電子メール アラートを作成し、リクエストをインターセプトして、その作成方法を理解しました。 ここには何もありません。
CSRF トークンでは正常に動作しており、セッション検証も適切に実装されていて。 

 

ジョブアラートが正常に作成されました

ジョブ アラート機能の作成は正常に機能していたので、ジョブ アラート リクエストの削除がどのように見えるかを確認したいと思い。
そこで、ゲップ インターセプトをオンにし、ジョブ アラートの 1 つを削除して、リクエストをキャプチャし。
リクエストは GET ベースであり、長い文字列がエンコードされていました。
私にとって理解するのが難しかったのは、パラメータやアラート ID を渡さずに GET リクエストでジョブ アラートがどのように削除されるかということで。
GET リクエストは次のようなものでした。 

 

GET /csr/index.cgi?SID=bW9kZT1kZWxldGUmcGFnZWNsYXNzPUFsZXJ0cyZhZ2VudF9jb2RlPTI2
NjAzOTMmcGFnZWFjdGlvbj1zdW1tYXJ5Jm93bmVyPTUwNzAwMDAmb3duZXJ0eXBlPWZhaXImcmVxc2
lnPTE3MDY1MTI1NTMtZjgwZTc4NmU2YzlhMGQ0NDgxNjkyMzI0YjNlZmVlYjFiMjViMDFmNg== HTTP/1.1
Host: target.com
Cookie: cookie-value
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close

残っているのは、これらのエンコードされた文字列をデコードすることだけで。
形式を見ると、おそらく Base64エンコードされていると思われ。
それで、げっぷデコーダーに行き、文字列をデコードしました。
デコードされた値は次のとおりでした:

[mode=delete&pageclass=Alerts&agent_code=2660393&pageaction=summary&owner=5070000&ownertype=fair&reqsig=1706512553-f80e786e6c9a0d4481692324b3efeeb1b25b01f6]


これで、GET リクエストが mode=delete パラメーターを介してどのようにアラートを削除していたのかがわかり。
Agent_code を見ると、それは削除されるはずだったジョブのアラート ID です。
ここでは、2 番目のテスト アカウントから別のジョブ アラートを作成し、agent_code を置き換えてリクエストを送信しました。

しかし、残念ながらその要求は失敗しました。
アラートが実際に削除されたかどうかを確認するために 2 番目のテスト アカウントを確認しましたが、アラートは存在していました。
アラートIDをもう一度確認しましたが、それは正しかったです。
ここで、パラメータをbase64エンコードに再度エンコードするのを忘れています。
実際のリクエストはエンコードされた形式であったためです。
ここで、再び別のアカウントのアラート ID を置き換え、文字列をエンコードしてリクエストを送信します。
今度はリクエストが成功しました。
次に、2 番目のテスト アカウントに移動して、アラートが実際に削除されたかどうかを確認しました。
はい、リストは空でした。

アラート ID は数値であるため、攻撃者は burp スイートの侵入者を使用するだけで、大量の人々のジョブ アラートを簡単に削除できます。

 

ほなほな。