强化不安全重定向...但重定向到您自己？
我有一个 ASP.NET Web 应用程序项目，我通过 Fortify Source Analyzer v3.1 对其进行扫描。
该 Web 项目包含一个 ASPX，该 ASPX 存在重定向到自身的情况。
代码为：
Response.Redirect(Request.Url.ToString());
Fortify 将其归类为 OWASP A10 和 CWE / SANS ID 601 问题。 我不明白这个漏洞——我们似乎正在重定向到一个非常特定的地方……当前的 URL。
为什么这被认为是不好的？
提前致谢。
I've an ASP.NET web application project that I scan through the Fortify Source Analyzer v3.1.
The web project contains an ASPX that has a case where it redirects to itself.
The code is:
Response.Redirect(Request.Url.ToString());
Fortify classifies that as OWASP A10 and CWE / SANS ID 601 issue.
I don't understand the vulnerability -- it seems that we're redirecting to a very specific place ... the current URL.
Why is that considered bad?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
验证来自 Request.Url 的数据是否正常不会有什么坏处。我对 .NET 的了解不够，无法真正明智地回答，但 URL 通常包含用户提供的内容。可能有一个查询字符串吗？后面是否有包含更多数据的片段 (#foo)？路径的一部分是否完全可替代，例如“http://server/search/foo”？它是精美的国际化 URL 之一吗？如果是这样，返回给您的字符串是什么字符集？远程攻击者是否可以指定不同的主机名和/或主机标头？
我对这是一个彻底的误报感到不舒服。希望我们能找一个聪明的人来插话......
It wouldn't hurt to validate the data coming out of Request.Url is sane. I don't know enough about .NET to answer real intelligently, but often URLs contain user provided content. Could there be a QueryString? Is there a fragment (#foo) with further data after it? Is part of the path completely fungible, like in "http://server/search/foo"? Is it one of the fancy internationalized URLs? and if so, what character set is the string returned to you in? Could the remote attacker have specified a different hostname and/or Host header?
I don't feel comfortable that this is a drop-dead false positive. Hopefully we can get somebody smart to chime in...
一般来说，SCA 正在寻找来自用户的任何未经验证的数据，这些数据未以任何方式验证并直接使用。它匹配的模式看到来自
Request.Url.ToString()的数据，然后使用Response.Redirect(*)。在这种情况下，具体来源很可能无关紧要；只有用户提供的数据在使用时才被验证。如果您可以提供 RuleID，我也许可以给您更具体的答案。
In general, SCA is looking for ANY unvalidated data coming from the user that is not validated in any way and used directly. The pattern it matched saw data coming in
Request.Url.ToString()and then usedResponse.Redirect(*). The specific source is more than likely irrelevant in this case; only that user supplied data was unvalidated when it was used.If you could provide the RuleID I may be able to give you a more specific answer.