【问题标题】:Is HttpServletRequest.getRequestURL() spoofable?HttpServletRequest.getRequestURL() 是可欺骗的吗?
【发布时间】:2015-09-15 16:46:38
【问题描述】:

我希望这个问题是不言自明的。我正在使用 CAS 服务器设置 Spring Security 环境。因为完全相同的应用程序部署在同一台服务器上,但服务器可以通过不同的主机名(.de 域、.com 域,可能不止这些)访问,我们希望在测试系统和本地系统上部署相同的应用程序同样,我构建了一个动态服务,其中服务 URL 是从请求 URL 派生的。

public static String makeDynamicUrlFromRequest(ServiceProperties serviceProperties, HttpServletRequest request) {
        String serviceUrl = "https://backup-url.de/login";
        URI uri = null;
        try {
            uri = new URI(request.getRequestURL().toString());
        } catch (URISyntaxException e) {
            logger.error("Someone tried accessing a disallowed service!", e);
        }

        if(uri != null){
            serviceUrl = uri.getScheme() + "://" + uri.getHost() + "/login";
        }

        return serviceUrl;
    }

这可以欺骗吗?如果是,额外的正则表达式检查是否为我提供了必要的安全措施?

【问题讨论】:

  • 欺骗是什么意思?你想防御什么样的攻击?
  • 我还不完全确定。如果有人能够修改 requestURL,CAS-Server 将重定向回他们自己的服务器。我不确定他们能用这个做什么,但我在 spring-security 的 JIRA 中发现了一个问题,解释说他们出于安全原因将 ServiceProperties.getService() 作为最终方法。
  • 如果他们修改了请求 url,你将如何获得请求?
  • 可能是他们请求了正确的 URL 并以某种方式修改了我收到的值,这就是为什么我问它是否可欺骗。我想这回答了我的问题——事实上,它不是。我认为它可能像一个可修改的标题或其他东西。我不确定,因此提出了问题。

标签: java jakarta-ee servlets httprequest spring-security-cas


【解决方案1】:

@developerwjk
“如果他们修改了请求 URL,您将如何获得请求?”
HTTP 服务器只是一个侦听 TCP 端口、等待一些传入文本并写出一些文本作为响应的程序。 (一个普通的 Web 服务器可以用 20 行代码编写。)它只能看到连接到它的任何东西的 IP 地址和端口。这甚至可以是一个代理,或者某种其他类型的中间件。如果您不告诉程序“顺便说一句,我通过 URL http://my.com/myapp/servlet 联系到您”,那么它就是不知道,例如浏览器将如何访问它。

@沙卡 我不知道您的特定设置,但对于 jetty9,getRequestURL 的结果由请求标头中的请求 URL 确定,并且 - 如果前者缺失 - Host 参数中的 URL。也就是说,如果你连接到my.com 并发送以下请求:

POST http://spoofed1.tld/myapp/servlet HTTP/1.1
Host: spoofed2.tld

(请记住,Host 参数是必需的。)
然后getRequestURL 将返回http://spoofed1.tld/myapp/servlet

如果你发送这个:

POST /myapp/servlet HTTP/1.1
Host: spoofed2.tld

然后码头本身会回应

HTTP/1.1 302 Found
Location: http://spoofed2.tld/myapp/servlet
Content-Length: 0
Server: Jetty(<some version number>)

所以答案是是的,HttpServletRequest.getRequestURL() 是可欺骗的!通过修改请求 URL 和/或 Host 请求标头。

【讨论】:

  • 是的,这个问题已经有 6 年的历史了,但是我无法通过谷歌搜索找到任何答案,所以我必须自己找出它是如何工作的。希望这能帮助其他人减少浪费时间。
  • 是的......但我不确定这算作欺骗,或者如何利用它。
  • @StephenC 它可用于将客户端重定向到欺骗位置。它是渗透测试期间检查的常见项目(您可能会猜到我为什么知道......)。例如。 “服务器是否以包含欺骗地址的 302 响应,就好像它是有效数据一样。”安全服务器应拒绝此类请求。
  • @StephenC 欺骗只是意味着欺骗你的沟通伙伴相信 B,实际上它是 A。所以是的,这就是欺骗。是否可以利用它取决于你用它做什么。如果您使用来自getRequestURL 的结果生成链接,将其存储在数据库中,然后将该链接显示给另一个用户,那么您就有漏洞。 (即使没有编码/注入/净化问题。)
猜你喜欢
  • 2018-07-27
  • 1970-01-01
  • 1970-01-01
  • 2023-03-09
  • 1970-01-01
  • 1970-01-01
  • 2010-10-12
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多