我正在阅读 OWASP 的安全编码实践清单，在他们的“输入验证”部分下，他们有一个项目如下：
验证来自重定向的数据（攻击者可能会直接向重定向目标提交恶意内容，从而绕过应用程序逻辑和重定向之前执行的任何验证）。
我对他们在这里的意思完全空白！
他们是说攻击者可以将重定向请求放入 HTTP 请求中，然后让网络服务器执行重定向，绕过请求将转到的正常 URL（以及伴随它的任何服务器端验证）？如果是这样，这种嵌入式重定向会是什么样子以及如何检测它？验证它是什么意思（正如他们所说）？
而且，如果我的解释完全错误，他们在说什么，有人可以给我一个具体的例子吗？提前致谢！
alexwen 的回答很好，虽然我认为他的回答更像是一个通用的参数清理问题，而不是 OWASP 所指的。我认为 OWASP 可能指的是以下任何概念。
从重定向重新验证数据
OWASP 讨论的是另一种方案，其中一个 URL 进行一些处理（即验证），然后重定向到另一个 URL 以完成。例如，假设有两个 URL，一个是 /checkout，另一个是 /ship。/checkout URL 检查信用卡信息，检查零件是否有库存等，然后重定向到 /ship。/ship URL 实际上创建了一个工作票来拉取零件并运送它们。
如果攻击者知道这个设置，那么攻击者可以直接将相关的运输数据发布到 /ship URL，绕过在第一个 URL 中执行的所有验证，并免费获得一些产品。
我个人从未见过如此愚蠢的验证方案，但这似乎是 OWASP 所指的。
重定向后获取模式
PRG 模式意味着在成功处理 POST 后重定向到 GET 请求。这用于避免用户单击浏览器中的后退按钮以及浏览器向用户询问有关是否“重新发布表单数据”的模糊问题的可怕可用性问题。（我已经看到这么多用户的这次旅行，这甚至都不好笑。）
我从未见过这种容易受到攻击的使用方式，但理论上一个糟糕的身份验证方案可能会使用 PRG 来处理身份验证凭据，然后重定向到“仅限会员”页面或类似的愚蠢的东西。再说一次，我个人从未在野外见过这种情况，所以我也不能 100% 确定 OWASP 所说的就是这个。
盲重定向
我不确定这就是 OWASP 所说的，但这实际上是一个常见的漏洞。与我描述的前两个漏洞不同，我实际上已经多次看到这个漏洞。这个常见的错误是要重定向到的 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和一个天真的用户查看链接并认为他要去纽约时报网站。（根据脚本的确切性质，攻击者可能能够对部分或全部目标 URL 进行 URL 编码，以进一步混淆它。）
重定向脚本应该检查目标 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 攻击。
因为编写这个虚构网站的人假设它只能通过表单发布访问，并且在重定向之后他们没有对消息参数进行适当的检查，以防止恶意人员用脚本标签代替良性成功消息。
您应该始终验证/转义来自浏览器、URL 参数或表单帖子的任何内容，无论它是否出现在重定向之后。以怀疑的态度对待所有输入，您将在保护自己免受这种攻击方面大有帮助。