OWASP TOP10 - ＃10未検証のリダイレクトとフォワード

Question

私はオープンリダイレクトについてOWASP PAGEとGoogle blog articleを含め、このトピックへの記事の多くを読む...
私もopen redirects here on stack overflowにこの質問を見つけましたが、それは別のもの

です

なぜ私はリダイレクトしてはいけないのか知っています...これは私にとって完全に意味をなさないものです。

しかし、私が実際に理解していないこと：リダイレクトとこれを通常の<a hrefリンクに置くことの違いはどこですか？
ユーザの中にはステータスバーを見ている人がいるかもしれませんが、リンクをクリックしたときにステータスバーを見ている人はほとんどいないと思います。
これは本当に唯一の理由ですか？ articleこの上のように、彼らは書いた：

<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a> 

をユーザーがURLがその信頼される銀行、bank.example.comで始まるので、リンクが安全であることを仮定してもよいです。ただし、ユーザーは攻撃者のWebサイト（attacker.example.net）にリダイレクトされ、攻撃者はbank.example.comと非常によく似ている可能性があります。ユーザは、無意識のうちに、攻撃者のウェブページに信任状を入力し、銀行口座を盗む可能性がある。 Javaサーブレットは、リダイレクトアドレスが信頼できるサイトであることを確認せずに、ユーザーをURLにリダイレクトしてはなりません。

ゲストブックのように、ホームページにリンクを張ることができるのであれば、唯一の違いはリンクがリダイレクトされないことですが、それでも邪悪なウェブページに行きます。

私はこの問題を正しく見ていますか？

Answer 1

私の理解では、リダイレクトが問題ではありません。ここでの主な問題は、絶対URLを含むリダイレクト（ユーザーが潜在的に制御可能なターゲット）を許可することです。

URLが絶対アドレス（つまり、http://host/etcが始まること）であるという事実は、意図的にドメイン間のリダイレクトを許可していることを意味します。これは、古典的なXSSの脆弱性に非常によく似ています。これにより、クロスドメインコール（ドメインの情報漏えい）を行うためにJavaScriptが反映されます。

私が理解しているように、これらの問題のほとんどを解決する方法は、サーバーに対するリダイレクトがルートに対して行われるようにすることです。そうすれば、ユーザー制御のクエリ文字列値が別の場所に移動する方法はありません。

あなたの質問にお答えしますか、それとももっと作成しますか？

Answer 2

主な問題は、攻撃者が実際には犠牲者が信頼するウェブサイトのURLであるため、URLを信頼できると見なす可能性があることです。 e。 bank.example.com。

リダイレクト先は、例のように明白である必要はありません。実際には、攻撃者は、特殊なエンコード、parameter pollutioningなどの正当なURLをスプーフィングするために、必要に応じてユーザと場合によってはWebアプリケーションの両方をさらに欺く技術をおそらく使用します。

したがって、犠牲者がセキュリティを意識してリンクをクリックしたり、リソースを要求したりする前に、URLが信頼できるWebサイトbank.exampleを指しているかどうかを確認するだけです。com。そしてそれだけで十分すぎるほどです。