HTTPリダイレクトを適切に検証する方法は？
私はOWASPのSecure Coding Practices Checklistを読んでおり、「入力の検証」セクションの下に次の項目があります。
リダイレクトからのデータを検証します（攻撃者は悪意のあるコンテンツをリダイレクトのターゲットに直接送信する可能性があるため、リダイレクトの前に実行されるアプリケーションロジックと検証を回避します）。
ここで彼らが何を意味するのかを完全に空白で描いています！
彼らは攻撃者がHTTPリクエスト内にリダイレクトリクエストを入れ、ウェブサーバーにリダイレクトを実行させ、リクエストが行く通常のURL（およびそれに伴うサーバー側の検証）をバイパスする可能性があると言っていますか？もしそうなら、そのような埋め込まれたリダイレクトはどのように見え、どのようにそれを検出するのですか？ （彼らが言うように）それに対して検証することはどういう意味ですか？
そして、私の解釈が完全に間違っている場合、彼らは何を話しているのでしょうか。誰かが具体的な例を教えてくれますか？前もって感謝します！
フォーム投稿後の一般的な方法は、ユーザーを成功ページにリダイレクトすることです。
POST /my-form HTTP/1.1
Host: www.myhost.com
HTTP/1.1 302 Moved Temporarily
Location: https://www.myhost.com/form-success.html?message=%3Cb%3ESuccess!%3C/b%3E
この例では、ユーザーはform-success.htmlページにリダイレクトされ、次のメッセージが表示されます。
<b>Success!</b>
Form-success.htmlには、メッセージを受け取ってドキュメントに追加するJavaScriptがあります。応答をサニタイズせずに、あなたは XSS攻撃 に自分を開放しています。
この架空のWebサイトをコーディングする人は、フォームポストを通じてのみアクセスされると想定し、リダイレクト後、悪意のある人が良性のスクリプトタグを代用することを防ぐために、メッセージパラメータを適切にチェックしませんでした。成功メッセージ。
常にリダイレクトから来たかどうかに関係なく、URLパラメータまたはフォーム投稿でブラウザから来るすべてのコンテンツを検証/エスケープする必要があります。すべての入力を疑いを持って扱い、このスタイルの攻撃から身を守るために長い道のりを進みます。
Alexwenからの良い答えですが、彼の答えはOWASPが正確に言っているものではなく、一般的なパラメーターのサニタイズの問題に近いと思います。 OWASPは次の概念のいずれかを指していると思います。
リダイレクトからのデータの再検証
OWASPは、あるURLが何らかの処理（つまり、検証）を行い、次に別のURLにリダイレクトして完了するという、別の種類のスキームについて話している。たとえば、2つのURLを想像してください。1つは/ checkoutで、もう1つは/ shipです。/checkout URLは、クレジットカード情報をチェックし、部品が在庫にあることをチェックし、その後/ shipにリダイレクトします。/ship URLは、実際にパーツをプルして出荷するための作業チケットを作成します。
攻撃者がこの設定を知っている場合、攻撃者はPOST関連する配送データを/ ship URLに直接送信し、最初のURLで実行されたすべての検証をバイパスして、一部の製品を無料で入手できます。
私は個人的にこのような検証スキームを見たことがありませんが、OWASPが言及しているようです。
Post-Redirect-Get Pattern
PRGパターン は、POSTが正常に処理された後、GET要求にリダイレクトすることを意味します。これは、ユーザーがブラウザーの[戻る]ボタンをクリックし、ブラウザーがユーザーに「フォームデータを再投稿する」かどうかについてあいまいな質問をするという、ひどいユーザビリティの問題を回避するために使用されます。 （私はこの旅行が非常に多くのユーザーに出会ったので、それも面白くありませんでした。）
これが攻撃に対して脆弱になるような方法で使用されたことはありませんが、理論的には、貧弱な認証スキームではPRGを使用して認証資格情報を処理し、「メンバー専用」ページまたはそのような愚かなものにリダイレクトする可能性があります。繰り返しますが、実際にこれを実際に目にしたことは一度もないので、OWASPがそれについて話していることも100％わかりません。
ブラインドリダイレクト
これがOWASPが話していることかどうかはわかりませんが、これは実際には一般的な脆弱性です。私が説明した前の2つの脆弱性とは異なり、実際にこれを実際に何度も目にしました。このよくある間違いは、リダイレクト先のURLが元のURLクエリで指定されており、検証されていないことです。例：
http://my.badsite.com/redirect.php?destination=http://google.com
Redirect.phpが無条件で渡されたすべてのURLにリダイレクトする場合（たとえば、PHPではheader（ "Location：$ location"））、攻撃者は安全に見えるが実際には危険なサイトにつながるURLを構築できます。たとえば、ブラインドリダイレクトスクリプトが http://nytimes.com/redirect.php にある場合、攻撃者は被害者に http://nytimes.com/のようなリンクを送信します。 redirect.php？destination = http：//spyware.malware.xxx/get_pwned そして、世間知らずのユーザーがリンクを見て、NYTのWebサイトにアクセスしようとしていると思います。 （スクリプトの正確な性質によっては、攻撃者は宛先URLの一部またはすべてをURLエンコードして、さらに難読化する可能性があります。）
リダイレクトスクリプトは、おそらく何らかの種類のホワイトリストを通じて、宛先URLを検査して、それが適切であることを確認する必要があります。