Hello there, ('ω')ノ
これを読む前に誰にもメッセージを送らないでくださいを。
脆弱性：
HTTP レスポンス操作
認証回避
アカウント乗っ取り
記事：
Web アプリケーションのセキュリティは、その認証および承認メカニズムの強度と
有効性に大きく依存していて。
これらが慎重に設計、実装、および維持されていない場合、
アプリケーションはさまざまな攻撃に対して脆弱になる可能性があり。
特に危険な攻撃ベクトルの 1 つは、攻撃者が有効な資格情報を提供せずに
システムにアクセスできる認証バイパスで。
最近の侵入テスト中に、標的のシステムに重大なアカウント乗っ取りの
脆弱性があることを発見し。
この脆弱性は、応答操作によって悪用される可能性があり、
被害者が攻撃者にメッセージを送信する必要があって。
ターゲットのプライバシーを保護するために、redacted.comと呼ぶことに。
セキュリティ テスト中に、有効なログイン リクエストへの応答を調べ。
機密情報と見なされる user_id は存在していましたが、
Cookie は設定されておらず。
これに気づいて、誤った資格情報を入力し、
正しい資格情報で応答を変更することで、応答操作を調査して。
驚いたことに、ダッシュボードからすぐにログアウトされる前に、
少しの間アクセスが許可され。
この予期しない動作により、アプリケーションが追加のチェックを
実行していると思って。
さらに調査した結果、user_login_status.php という名前の
エンドポイントを見つけ。
一致と置換機能を利用して、user_signed_out のインスタンスを
user_is_signed_in に変更することで応答を変更し、成功したログインを模倣して。
これにより、自分のアカウントにアクセスできるようになりましたが、
障害に遭遇して。
アカウントの乗っ取りを実行するには、やはり user_id が必要で。
user_login_status.php
編集されたシステムで、get_message リクエストへの応答を処理する方法に
脆弱性があることを発見し。
ユーザが別のユーザにメッセージを送信すると、redacted は
get_message リクエストを送信してメッセージを取得して。
ただし、この要求への応答には、メッセージの内容だけでなく、
sender_id と sender_email も含まれて。
sender_id は実際には user_id で。
user_id とメールアドレスの漏洩
この脆弱性を悪用することで、応答を傍受し、ログイン ページで
sender_email とランダム パスワードを使用してユーザのアカウントに
アクセスすることができて。
下記の応答を
{"user_profile":{"sign_in_status":"invalid_password"}}
下記に変更すると。
{"user_profile":{"sign_in_status":"login_success","user_id":"<user_id_string>"}}
ユーザのアカウントに完全にアクセスできるようになり、
完全な乗っ取りを実行できて。
結論として、redacted の脆弱性により、認証をバイパスして
任意のユーザのアカウントを乗っ取ることができたのは、
アプリケーションのセキュリティに対する深刻な脅威で。
この脆弱性を軽減するには、アプリケーションの認証および
承認メカニズムの設計と実装を改善する必要があって。
アプリケーションは、要求への応答にユーザ ID や電子メール アドレスなどの
機密情報が含まれていないことを確認することから開始できて。
改ざんを防ぐために、応答を適切に検証することも不可欠で。
さらに、多要素認証とセッション管理を実装すると、
アカウント乗っ取りのリスクを軽減できて。
Best regards, (^^ゞ
