Hello there, ('ω')ノ
同じプログラムで Open Redirect を 3 回バイパスできた方法を。
脆弱性：
オープンリダイレクト
記事：
今回は、細部に注意を払うだけで、同じ問題に対して 3 倍の報酬を獲得できて。
メインストーリー：
サインアップ時にユーザは自分のアカウントを確認するための確認リンクを取得し。
ここで検証リンクを試し始めたところ、デフォルトでは空である
「redirect_after」パラメータがあることがわかり。
しかし、検証リクエストには「redirect_after」フィールドが含まれておらず。
どこでも「redirect_after」を入力し始めましたが、エラーが発生し、
リクエストの形式が正しくなくて。
それをサインアップ URL リンクに使用して。
https://private-site.com/singup?redirect_after=https://evil.com
そしてなんと、evil.com へのリダイレクトが成功して。
彼らがそれを修正したかどうか見ようと思い。
同じ手順を実行して問題を再現したところ、問題は解決されたようで。
サインアップ後、evil.com にはアクセスせず、アプリケーションが停止しただけで。
パッチが適用されてからフィルタリングか
何かが行われているのではないかと思い。
しかし、確認リンクをクリックすると、evil.com にリダイレクトされ。
再び攻撃に成功して。
最近、再度テストしてみて。
今、サインアップ中に POST リクエストが使用されていたことに気づきましたが、
それはgraphQLリクエストで。
実際には別の問題を探していましたが、幸運なことに以前の修正をバイパスでき。
検証リンクがエンコードされ、サードパーティを使用して URL が短縮されて。
それをデコードし、検証リンクで同じ隠しパラメータを再び見つけたことを推測し。
そこで今回は、サインアップの POST リクエストをインターセプトし
隠しパラメータ (POST /graphql?redirect_after=https://evil.com) を追加して。
そして、検証リンクがユーザを evil.com にリダイレクトして。
バグ報奨金を行う際に行うべき主なことは、細部を確認することで。
そして、すべてのリクエストとその応答を研究して。
アプリケーションが厳しくテストされている場合でも、
アプリケーションを新しいものとして扱って。
Best regards, (^^ゞ
