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