Shikata Ga Nai

Private? There is no such things.

Break the Logic: Insecure Parameters (€300)を訳してみた

Hello there, ('ω')ノ

 

論理を破る: 安全でないパラメータを。

 

脆弱性:

 パラメータ操作

 ロジック欠陥

 質量割り当て

 

記事:

 https://infosecwriteups.com/break-the-logic-insecure-parameters-300-e655cc4fcc42

 

今回は、同じプログラムで発見した安全でないパラメータに基づく 2 つの。

マイナーな脆弱性について。

これを「redacted.com」と呼ぶことに。

 

Ⅰ.安全でないパラメータを使用したメール検証のバイパス

redacted.com には、プライマリ メールと追加メールの 2 つのメール機能があり。

プライマリ メールを持つユーザは、追加のメールを追加でき。

ただし、追加のメールをプライマリ メールにするには。

アプリが確認コードを追加のメールに送信する必要があって。

そのため、追加のメールを確認なしにプライマリ メールに変換することはできず。

まず、このプロセスが通常の条件下でどのように行われるかを分析することに。

 

1.追加のメール セクションにメールを入力しましたが。

  そのメールには確認が必要であることに気付いて。

 

 

写真でわかるように、確認メールが送信され。

フィールドの横にある 2 つのオプションはメールの「再送信」または「削除」で。

 

2.Burp Suite を実行し、ページに戻り。

  再度メールを入力し、リクエストを受け取り。

 

 

3.「activated」と「for student verification」という2の安全でないパラメータは。

  falseを返すため、両方をtrueに変更してリクエストを送信して。

 

4.redacted.com に戻ると、メール フィールドの横に。

  チェックボタンが表示されていて。

  チェックボタンをクリックして、ページを更新して。

 

 

最後に、追加メールはプライマリ メール セクションに移動し。

古いプライマリ メールは追加メールになって。

 

Ⅱ.隠れた安全でないパラメータを使用したスタディ検証のバイパス

redacted.com では、ユーザはカスタムの「調査」情報を追加でき。

ただし、このためには、最初に管理者によって研究情報が検証および。

承認されなければならず。

つまり、ユーザが独自の調査情報を追加する際に検証プロセスがあり。

検証は、redacted.com の管理者によって直接行われ。

しかし、隠れた安全でないパラメータにより、ユーザのカスタム調査情報が。

承認済みのように見え、最終的に実際に承認される可能性があって。

分析することに。

 

1.「I study」フィールドで、独自の特別な学習情報を追加することができて。

  たとえば、「admin」と入力してリクエストを送信してみると。

 

 

2.Burp Suite を実行し、「admin」と入力してリクエストを再送信して。

 

 

3.リクエストは上記のとおりで。

  興味のあるものは何も見当たらなかったので、リクエストを送信して。

  レスポンスを確認して。

  それに応じて、パラメータ「isVisible:」が false に設定されていることが。

  わかって。

 

4.リクエストを再送信し、パラメータ「isVisible:true」をリクエストの末尾に。

  追加して。

 

 

ページを更新すると、追加した情報がプロファイルに直接表示されていることが。

わかって。

 

 

このようにして、攻撃者は検証をバイパスして、必要な情報を追加できて。

 

Best regards, (^^ゞ