Hello there, ('ω')ノ
CSRF を使用したサイト攻撃を。
脆弱性：
XSS
CSRF
記事：
https://josephmusando8.medium.com/attacking-sites-using-csrf-8b15801b8bb1
CSRFからユーザー情報漏洩、XSS、アカウント完全乗っ取りまで。
CSRF 脆弱性の重大度は、脆弱性が存在する場所に大きく依存。
場合によっては、CSRF 保護メカニズムに欠陥があると、不正な設定変更や
ユーザのカートを空にするなどの重要でない問題が発生することがあり。
また、ユーザ情報の漏洩、XSS、さらにはワンクリックでの
アカウント乗っ取りなど、さらに大きな問題につながることもあり。
ここでは、CSRF の現場で私が遭遇した、深刻なセキュリティ問題に
つながるケースをいくつか紹介して。
多くの場合、これらは CSRF とその他の小さな設計上の欠陥の組み合わせで。
重要な CSRF #1: CSRFP を使用したユーザー情報の漏洩パーマリンク
CSRF は副作用として情報漏洩を引き起こすことがあり。
アプリケーションは多くの場合、ユーザの好みに応じて情報を送信または開示し。
これらの設定エンドポイントが CSRF から保護されていない場合、
機密情報の漏洩に道が開かれる可能性があり。
CSRF ベースの情報漏洩を達成する 1 つの方法は、
これらのリクエストを操作することで。
たとえば、Web アプリの有料サービスでは、毎月の請求メールがユーザが指定した
メール アドレスに送信され。
これらの電子メールには、ユーザの住所、電話番号、および限定された
クレジット カード情報が含まれ。
これらの請求メールの送信先メール アドレスは、
次のリクエストを通じて変更できて。
POST /change_billing_email
REQUEST BODY:
email=NEW_EMAIL &csrftok=12345
このエンドポイントの CSRF 検証は壊れていて。
サーバは空のトークンを受け入れ、csrftok フィールドが空のままでも
リクエストは成功し。
被害者に次のリクエストを送信させると、今後のすべての請求メールは
(被害者が不正な変更に気づくまで) ATTACKER_EMAIL に送信され、
アカウントに関連付けられている住所と電話番号が攻撃者に漏洩して。
POST /change_billing_email
REQUEST BODY:
email=ATTACKER_EMAIL &csrftok=
クリティカル CSRF #2: CSRFP を使用して保存された自己 XSS パーマリンク
Self-XSS は悪用が難しいため、セキュリティ チームからはほとんどの場合
問題ではないと考えられていて。
ただし、CSRF と組み合わせると、多くの場合、自己 XSS を保存済み
XSS に変えることができ。
たとえば、金融サイトでは、ユーザはリンクされた銀行口座ごとに
ニックネームを作成することができ。
アカウントのニックネーム フィールドはセルフ XSS に対して脆弱で。
フィールドへのユーザ入力にはサニタイズ、検証、エスケープがなく。
ただし、これは許可されたユーザのみが編集および表示できるフィールドであるため
攻撃者が XSS を直接トリガーする方法はなく。
残念ながら、アカウントのニックネームを変更するために使用される
エンドポイントにも CSRF バグが存在し。
アプリケーションは CSRF トークンの存在を適切に検証しないため、
リクエスト内のトークン パラメータを省略するだけで CSRF 保護がバイパスされ。
例えば：
POST /change_account_nicknameREQUEST BODY:
nickname=<XSS PAYLOAD> &csrftok=WRONG_TOKEN
このリクエストは失敗し。
POST /change_account_nicknameREQUEST BODY:
nickname=<XSS PAYLOAD>
このリクエストはユーザのアカウントのニックネームを正常に変更し、
XSS ペイロードを保存し。
次回ユーザーがアカウントにログインしてダッシュボードを表示すると、
XSS がトリガーされて。
重要な CSRF #3: CSRFP を使用したユーザー アカウントの引き継ぎパーマリンク
これらは、最も簡単なアカウント乗っ取りの一部で。
そして、こうした状況も珍しいことではなく。
アカウント乗っ取りの問題は、パスワードの作成、パスワードの変更、
電子メール アドレスの変更、パスワードのリセットなどのアカウント検証機能に
CSRF の問題がある場合に発生して。
たとえば、これはクライアントの Web アプリで発見したバグで。
Web アプリではソーシャル メディアへのサインアップが可能で。
ユーザはソーシャル メディア経由でサインアップした後、次のリクエストを通じて
パスワードを設定するオプションを利用でき。
POST /password_changeREQUEST BODY:
oldpassword= &newpassword=XXXXX &csrftok=12345
ユーザはソーシャル メディア アカウント経由でサインアップしたため、
新しいパスワードを設定するために古いパスワードは必要なく。
そのため、このエンドポイントで CSRF 保護が失敗した場合、
攻撃者はソーシャル メディア アカウント経由でサインアップし、
パスワードを設定していないユーザーに対してパスワードを設定できるようになり。
そして残念なことに、それがまさにこの特定のエンドポイントで起こったことで。
アプリケーションは CSRF トークンを適切に検証せず、
csrftok パラメータとして空の値を受け入れ。
したがって、基本的に、次のリクエストは、
(まだパスワードを設定していない) 全員のパスワードを ATTACKER_PASS に設定し。
POST /password_changeREQUEST BODY:
oldpassword= &newpassword=ATTACKER_PASS &csrftok=
攻撃者が行う必要があるのは、サイトのユーザが頻繁にアクセスするページに
このリクエストを埋め込むことだけであり、これらのページにアクセスする
ユーザのパスワードを ATTACKER_PASS に自動的に割り当てることができて。
その後、攻撃者は新しく割り当てられたパスワードを使用して、
任意の被害者として自由にログインできるようになり。
結論パーマリンク
CSRF は非常に一般的であり、非常に簡単に悪用され。
CSRF の大部分は重大度の低い問題であることが判明しましたが、
重要なエンドポイントの見落としが重大な結果につながる場合があり。
開発者の場合は、重要なエンドポイントに導入されている CSRF 保護メカニズムに
特に注意して。
あなたがハッカーであれば、CSRF に遭遇したときに、
その機能がアプリケーション全体のコンテキストでどのような役割を果たすかを
考えて。
エンドポイントはアプリケーションの残りの部分にどのような影響を与えるか。
その知識に基づいて脆弱性を拡大するにはどうすればよいか。
Best regards, (^^ゞ
