Hello there, ('ω')ノ
オープン リダイレクト保護をバイパスできた方法を。
脆弱性：
オープンリダイレクト
記事：
ここでは、数か月前に Linkedln で見つけた素晴らしい脆弱性について。
オープンなリダイレクトの脆弱性は、アプリケーションが安全でない方法で
ユーザ制御可能なデータをリダイレクトのターゲットに組み込むときに発生し。
攻撃者は、アプリケーション内で任意の外部ドメインへのリダイレクトを
引き起こす URL を構築する可能性があり。
脆弱な Web サイトのリンクの例は次のようになり。
http://xyz.com/login.html?vulparam =https://xyz.com/next
この例では、「vulparam」パラメータは、ログイン成功時のユーザの送信先を示し。
Web サイトが「vulparam」パラメータ値を検証して、対象の Web ページが
正当で意図されたものであることを確認しない場合、
攻撃者はそのパラメータを操作して、攻撃者が作成した偽のページに
被害者を送信する可能性があり。
https://xyzcom/login.html?vulparam=http://evil.com
しかし、Linkedln オープン リダイレクトをバイパスするのはそれほど簡単ではなく。
脆弱な URL は 下記で。
https://www.linkedin.com/lite/external-redirect?url=http://evilzone.org&urlHash=YKI5
Linkedln には、オープン リダイレクトに対する優れた保護機能が備わっていて。
これは、次のような一般的な手法を使用してバイパスできなかったためで。
url=../evilzone.org
url= ///evilzone.org
url= ///www.linkedln.com@www.evilzone.org/%2f%2e%2e
「url」値を悪意のあるサイトに変更するだけでは、ここでは機能せず。
ご覧のとおり、ユーザーがリダイレクトされる URL のハッシュ値のように見える
追加のパラメータ「urlHash」があり。
したがって、「urlHash」値が「url」の実際の有効なハッシュ値である場合、
成功したリダイレクトのみが行われて。
今までのところ、基本的なテクニックでは何の役にも立たないことが
明らかだったので、ヘルプを見つけるために生のリクエストに戻り。
オープンリダイレクション未加工リクエスト
リクエストには、ユーザが最後にいたページ (リンクをクリックしたページ) を
示す「referer」フィールドが含まれていてここで心に思い浮かんだことがあり。
「リファラ ヘッダの値を変更して、そこで検証が機能するかどうかを
確認してみてはどうか?」と 。
そこでヘッダ値を他のドメインに変更しましたが、それでもうまくいかず。
もう一度試してみて。
LinkedIn Android アプリ リファラを検索し、次のリンクを見つけて。
https://github.com/snowplow/referer-parser/issues/131
すると、LinkedIn Android リファラ値が
「android-app://com.linkedin.android」として見つかり。
「referer」ヘッダフィールドでリファラー値を使用し。
残りは以下の通りで。
リダイレクトが成功し、ついに LinkedIn の Open リダイレクト保護
をバイパスすることができて。
Best regards, (^^ゞ
