Hello there, ('ω')ノ
脆弱な暗号化によりオープンリダイレクトが発生するを。
脆弱性：
オープンリダイレクト
記事：
https://medium.com/bugbountywriteup/weak-cryptography-leads-to-open-redirect-3fe052c12995
オープンリダイレクトの脆弱性は、アプリケーションが安全でない方法で
ユーザ制御可能なデータをリダイレクトのターゲットに組み込むときに発生して。
攻撃者は、アプリケーション内で任意の外部ドメインへのリダイレクトを
引き起こす URL を構築する可能性があり。
この動作を利用して、アプリケーションのユーザに対するフィッシング攻撃を
容易にすることができ。
正しいドメインをターゲットにし、有効な SSL 証明書 (SSL が使用されている場合) を
使用して、本物のアプリケーション URL を使用できる機能は、
多くのユーザがこれらの機能を確認したとしても、
その後、別のドメインへのリダイレクトに気付かないため、
フィッシング攻撃の信頼性を高めて。
ターゲットを target.com と呼び。
最初のステップは、偵察を常に行うことで。
偵察はバグを発見する上で重要な役割を果たし。
waybackurls ツールを通じてターゲットの多くのエンドポイントを取得し、
grep コマンドを通じて「redirect」パラメータを持つ URL をフィルタ処理すると、
結果は次のようになり。
まず、リダイレクト値をコピーし、「%3D」を「=」（URL デコード）に
変更したので、次のようになり。
aHR0cHM6Ly9hcHAudGFyZ2V0LmNvbS9kYXNoYm9hcmR8MzJ8YUhSMGNITTZMeTloY0hBdWRHRnlaMlYwTG1OdmJTOWtZWE5vWW05aGNtUT0=
Base64 でエンコードされた値のように見えるので、
簡単にデコードすると次のようになり。
https://app.target.com/dashboard|32|aHR0cHM6Ly9hcHAudGFyZ2V0LmNvbS9kYXNoYm9hcmQ=
数秒間、URL の後にあるのは一体何だろうと考えていて。
その後、「32」が URL の長さで、「https」の最初の「h」から
「dashboard」の最後の「d」までで、
そしてその後がURL の Base64 エンコード値にすぎないトークンを与えていて。
サーバ バックエンド フロー：
ユーザログイン ⇨ リダイレクト値をBase64デコード
⇨ URLの長さとエンコードされた値による整合性のチェック
⇨ 問題がなければ、リダイレクト
次のステップは、悪意のあるサイトへのリダイレクトを作成することで。
このための最初のステップは、URL の長さをカウントし、
URL を Base64 にエンコードすることで。
作成手順：
１．まず、URL 内の文字、記号、数字などの数を数えて。
https://evil.com ⇨ 16
２．URL を Base64 エンコードするだけで。
https://evil.com ⇨ aHR0cHM6Ly9ldmlsLmNvbQ==
３．パイプを区切り文字として使用し、両方の値と悪意のある URL を組み合わせると
ペイロードは次のようになり。
https://evil.com|16|aHR0cHM6Ly9ldmlsLmNvbQ==
４．次に、ペイロードを Base64 でエンコードして。
aHR0cHM6Ly9ldmlsLmNvbXwxNnxhSFIwY0hNNkx5OWxkbWxzTG1OdmJRPT0=
５．「=」、つまり「%3D」を URL エンコードして。
最終的な Base64 でエンコードされた値を脆弱な URL の
「リダイレクト」パラメータに入力するだけで、実行の準備が整って。
ログイン後、サイトはスムーズに EVIL.COM にリダイレクトされて。
Best regards, (^^ゞ
