打开重定向的黑盒URL匹配机制旁路

Question

我目前正在测试一个web应用程序，该应用程序似乎存在一个开放的重定向漏洞，因为它们通过GET接收参数redirect_url。应用程序稍后将用户重定向到此URL。然而，他们做一些固定的URL，他们接受，并响应与400的任何其他网址。

应用程序所期望的URL如下所示：https://subdomain.example.com/foo/bar。

我试着缩小他们的匹配范围。以下尝试都失败了，因为URL未被接受。

• 方案：http://subdomain.example.com/foo/bar
• 子域：https://foobar.example.com/foo/bar
• 域：https://subdomain.test.com/foo/bar
• 目录1：https://subdomain.example.com/bar/bar
• 目录2：https://subdomain.example.com/foo/foo

此外，我还试图用URI：https://subdomain.example.com@test.com/foo/bar中的用户名欺骗应用程序

总而言之，这似乎执行得很好。

问:我的问题是，如果有其他方法绕过URL匹配机制，我还没有想到。

编辑：

通过@Trickycm的建议，我尝试了以下方法：

• 目录遍历：https://subdomain.example.com/foo/bar/../../../../test
• 目录遍历：https://subdomain.example.com/../../../../test/foo/bar
• 各种编码(例如URL)、更改方案、子域、域、目录
• 空字节填充
• SQL注入
• 极长URL
• 各种字符集网址(如中文、俄文、印度文)
• 上述各种组合

所有这些都没有成功，这似乎是以一种非常安全的方式实施的。

Answer 1

我将尝试以下几点：

1. 目录遍历./../foo/bar
2. 不同的编码、url等
3. 填充空字节和额外字符
4. 一般模糊化，包括极端长度、多个字符集和编码、sql模糊(以防从db中提取有效的redirs )