开放重定向加法符号

Question

我知道还有一些关于开放重定向的问题，但是对于这个问题，我还有一些额外的问题。为了不释放资产，我将把资产替换为"exampleeee.com“。

有一个易受攻击的参数redirectURL会导致对资产的开放重定向。当我们说：https://www.exampleeee.com/Test?redirectURL=https://www.exampleeee.com:80@maliciouswebsite.com时，我们将被重定向。所以它是脆弱的。

当我们删除":80“时，我们会得到一个错误页面。所以：https://www.exampleeee.com/Test?redirectURL=https://www.exampleeee.com@maliciouswebsite.com，不起作用。

为什么":80“让它工作，我们有一个SSRF攻击和一个开放的重定向攻击组合？

对不起，这个问题我搞不懂。

提前感谢！

Answer 1

如果没有服务器的源代码，没人能确定到底发生了什么。然而，最有可能的答案是，有些人对URL解析有点着迷，并增加了对URL的一个基本不受欢迎的特性的支持，但在编写重定向验证程序时却没有考虑到这一点。

URL可以在方案和域之间包含用户名和(可选)密码。总体格式如下：

计划：//[username*密码@]domain*港口]path?key=value[&key2=value2[...&keyN=valueN]]

由于密码部分是可选的(而且很少使用；我认为现代浏览器甚至不再支持它了)，即使使用用户名部分(它本身非常罕见)，重定向使用它也很奇怪，但是没有它就失败了。任何理解上述格式的URL解析库都应该能够正确地将"maliciouswebsite.com“识别为您所提供的两个URL中的域。我想可能是有人滚了他们自己的解析器，他们犯了你犯的同样的错误，认为冒号只用于表示端口，因此他们不需要继续扫描@标志？

不过，在公开的重定向上找到的不错。它几乎肯定不是SSRF --服务器可能会直接拒绝URL，或者在Location:头中将其返回给浏览器；在这两种情况下，都不太可能提出请求本身--但您可以对其进行测试。将其指向已设置的侦听器，并查看服务器是否尝试连接。另外，我很好奇，如果您将:443 (HTTPS的实际端口；80用于普通HTTP)是否会改变行为。