奇安信攻防社区-CVE-2024-22243与Java中常见获取host的方式

CVE-2024-22243与Java中常见获取host的方式

Spring官方近期披露了CVE-2024-22243，在受影响版本中，由于 UriComponentsBuilder 处理URL时未正确处理用户信息中的方括号，攻击者可构造包含方括号的恶意URL绕过主机名验证。如果应用程序依赖UriComponentsBuilder.fromUriString()等方法对URL进行解析和校验，则可能导致验证绕过，出现开放重定向或SSRF漏洞。本质上还是安全检查的工具类与组件库解析host发起请求的解析逻辑导致的绕过问题。

0x00 前言
=======

在实际业务场景中，Open Redirect以及SSRF是比较常见的安全问题。通常情况下会通过解析请求URL中的host，并检查在不在可允许的域名范围或者ip内，来避免相关的安全风险。例如通过相关的工具类（例如java.net.URL的getHost方法）获取URL中的host进行检查，然后再调用HTTP组件库（Apache Httpclient、okhttp等）进行请求。

这里存在着一个解析差异的问题，**如果检查的工具类与组件库解析host发起请求的解析逻辑不一样的话，可能会存在绕过安全防护的问题。**

0x01 CVE-2024-22243
===================

开发中我们经常会操作 URL，比如提取端口、提取路径以及最常用的提取参数等等。很多时候需要借助于一些第三方类库或者自己编写工具类来实现。在Spring Web中提供了一个用于构建和操作URI的工具类UriComponentsBuilder。

1.1 漏洞描述
--------

Spring官方近期披露了CVE-2024-22243，在受影响版本中，由于 UriComponentsBuilder 处理URL时未正确处理用户信息中的方括号 `[` ，攻击者可构造包含方括号的恶意URL绕过主机名验证。如果应用程序依赖UriComponentsBuilder.fromUriString()等方法对URL进行解析和校验，则可能导致验证绕过，出现开放重定向或SSRF漏洞。

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-57d6db9645aa7f0f6bbacf7a715075932b125758.png)

1.2 影响版本
--------

Spring Framework

- 6.1.0 - 6.1.3
- 6.0.0 - 6.0.16
- 5.3.0 - 5.3.31
- Older, unsupported versions are also affected

1.3 漏洞分析及复现
-----------

根据对应的漏洞描述，问题主要在URI的工具类UriComponentsBuilder中。

UriComponentsBuilder 提供了一种简单而强大的方式来构建和处理 URI，避免了手动拼接字符串的繁琐和容易出错的问题。通过添加路径、查询参数、片段等组件来构建完整的 URI：

```Java
UriComponents uri =UriComponentsBuilder.fromHttpUrl(url).build();
```

除了上面的fromHttpUrl方法以外，比较常用的有：

- fromUri
- fromHttpUrl
- fromUriString

通过返回的UriComponents可以轻松的获取URI中类似协议、端口、host等各部分内容。例如可以通过getHost方法获取当前请求的host，结合实际的业务场景检查在不在可允许的域名范围或者ip内，来避免类似SSRF/Open Redirect等安全风险：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-d93df8f2a91b543c7c8894dd2bc5ea982d747c85.png)

以org.springframework.web.util.UriComponentsBuilder#fromUriString方法为例，查看具体的解析过程，整个逻辑比较简单，主要是通过正则匹配URI中各个部分的内容，然后完成对应的封装：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-7df3e0194a6308c5812c7aba67b2bceab558bca6.png)

具体的正则如下，具体定义了匹配URI的每一个部分内容：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-47d5663451ba7f324d2525af3d41eeb3a95a0614.png)

若未匹配相关信息，会抛出`throw new IllegalArgumentException("[" + uri + "] is not a valid URI");`异常，否则进行进一步的封装，同时这里对scheme和host进行了一定的合法性检查：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-e7886472b0de33e550f41a8f13f8557c755d76ac.png)

其他方法也是类似的，org.springframework.web.util.UriComponentsBuilder#fromHttpUrl方法的类型也是类似的但是使用的是HTTP\_URL\_PATTERN正则：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-e4a1a416a88523d33e1e2810097c07240aa725c6.png)

org.springframework.web.util.UriComponentsBuilder#fromUri则是直接使用的java.net.URI进行封装：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-2e6b236facb8f3bf7bbba8944bfb920b2337529c.png)

简单了解了具体的使用以后，通过相关的commit记录https://github.com/spring-projects/spring-framework/commit/7ec5c994c147f0e168149498b1c9d4a249d69e87 可以看到，官方提供的修复方式主要是移除了USERINFO中对方括号 `[`的匹配：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-f966c27a06b2f9ca21870343feef8acd90cb30df.png)

在此之前，可选的USERINFO信息由一个或多个非@、`[`、斜杠、问号和#号的字符组成。那么实际利用起来就很简单了，举个例子：

```Java
UriComponents uri =UriComponentsBuilder.fromHttpUrl("http://forum.butian.net[@risk.com").build();
```

解析完成后USERINFO为null，对应的host并不是预期的risk.com，而是forum.butian.net：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-b0928987f234f6752c7bcad82f078491df954ce7.png)

此时若发起请求的http组件能解析上述的URL，且获取到的host存在解析差异的话，以java.net.URL为例，通过HttpURLConnection进行请求，可以看到这里实际获取到的host是risk.com：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-752492a42c6b92dc2ac141c0a9c5589e5baaaf77.png)

以Open Redirect的防护为例，一般会检查请求host是否在白名单范围内来进行拦截，通过上述请求，即可绕过对应的白名单host检查，访问到risk.com，造成对应的风险。

实际上除了`[`以外，通过多个@、问号和#号的字符也能在使用UriComponentsBuilder获取到意料之外的host：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-adcbddc432cb7dbd9efa619a5308dc4cf8832aff.png)

但是前提是发起请求的http组件能解析上述的URL，且获取到的host存在解析差异，才可能导致对应的绕过风险，可以看到通过java.net.URL解析的host是一致的：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-9945689a7a1243994e19b0ad7441a7864e04baec.png)

所以这也是为什么官方最终仅调整了`[`的原因吧？:

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-1ccda8f7781d52e65e64f3f77db54a7e5eebc595.png)

0x02 Java中常见获取host的方式
=====================

前面对SpringWeb提供的工具类UriComponentsBuilder获取host的方式进行了简单的分析，除此之外，在Java中其他的一些获取host方式可能也会存在类似的解析差异导致的绕过问题。下面简单看看Java中常见的获取host的方式：

2.1 java.net
------------

最常见的可以基于URI或者URL对象的getHost方法进行获取。很多组件库也是对其进行封装进行二次处理的：

```Java
URL url = new URL(input);
String host = url.getHost();
```

以URL为例，通过其构造器可以知道，最终调用的是URL(URL context, String spec, URLStreamHandler handler)：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-f8a7f0ba368f8653a99118c23fb9d713b938fec1.png)

首先会解析出来请求的协议，并根据protocol去相应的包里面去加载`Handler`类，然后调用parseURL方法进行解析：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-30ddd29fcdc245a2b082b16f2238650080a9ece8.png)

在parseURL方法中，主要是解析出URL中的字符串信息，最后将这些字符串结果再回设置给URL类中去。可以看到关于host的解析并不是基于正则的，会直接根据@字符的坐标进行切割：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-d3a00f473989cc74b5f3905ddbeb6298797dbe91.png)

2.2 hutool工具类
-------------

Hutool是一个功能强大的Java工具类库，它提供了一系列方便实用的工具类，其中包括解析URL的工具类cn.hutool.core.util.URLUtil，其提供了一系列的方法用于解析URL。

可以看到其获取host的方式是基于java.net.URL上进行处理的：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-c759e65d0b970b36d123e5914878f81bbc5aaea5.png)

2.3 常用HTTP组件库
-------------

Apache Httpclient是一个可以用来提供高效的、最新的、功能丰富的支持 HTTP 协议的客户端编程工具包。相比传统JDK自带的URLConnection，增加了易用性和灵活性，它不仅使客户端发送Http请求变得容易，而且也方便开发人员测试接口（基于Http协议的），提高了开发的效率，也方便提高代码的健壮性。是Java中比较常用的HTTP组件库。

其中其不同版本解析获取host方法方式会有一些区别，下面举例说明：

- **HttpClient3**

以Get请求为例，可以通过如下方法获取请求的host：

```Java
HttpClient httpclient = new HttpClient();
HttpMethod method = new GetMethod("http://127.0.0.1%23.baidu.com/");
String host = method.getURI().getHost();
```

这里主要通过自实现的 URI 类org.apache.commons.httpclient.HttpMethodBase进行解析：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-f38959e73a8ecaa4b7210f6c5d470deadaa9e285.png)

查看URI的具体实现，主要通过org.apache.commons.httpclient.URI#parseUriReference方法进行一些简单的处理:

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-f8f4cdc8f37318faabd54bd70930e498cd88ef68.png)

parseUriReference方法会对不合理的host头进行处理。这里有个关键是会对#进行截断，重新组装后赋值给\_query，将处理后的\_query生成新的URI:

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-abfcae10f0b3a109feebf1e8ac3b68a4855137d1.png)

最后调用HttpMethodBase自身的setURI方法进行处理：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-116e1df94baf885c5bd960239d636e0c4cf20df3.png)

这里新建了HttpHost对象，查看其实例化方法，调用了自定义的uri.getHost方法，这里还会进行一次URL解码：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-c4158b588e035f308d5cefc38d5713ee7d04c948.png)

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-9204b12535c7c991015dae144035df68a86ed946.png)

也就是说类似127.0.0.1#的host会经过二次处理变成127.0.0.1，以解析http://127.0.0.1#forum.butian.net/ 为例（将#进行URL变成成%23也是可以的）：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-721cf637bde27c793731700edc9b3c11a15d54c3.png)

- **HttpClient4(&lt;=4.5.12版本)**

可以通过内嵌的URIUtils#extractHost方法获取当前请求的host。

在解析时候先使用自带的 URL 函数获取 port 和 host，如果通过getHost()获取失败的话，会调用getAuthority()方法来进行调整。然后如果不为null，则进行进一步的处理，首先对@进行截断，获取@后的内容。然后获取:做拆分，一直获取相关的整数，直到为非数字为止：

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-7759c9dc3cde05fb497d0947622cc6b8db746bec.png)

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-bb952052db8468d209d28c1567eab495e872af83.png)

也就是说，类似:80.forum.butian.net最后获取到的值应该为80，作为相关的端口。然后host的内容以:进行substring切割：

```Plaintext
 host = host.substring(0, colon);
```

那么若相关的请求为127.0.0.1:80.forum.butian.net，最终处理的结果为127.0.0.1:80。

除此以外，还可以通过org.apache.http.client.utils.URIBuilder解析url来获取host，本质上解析还是是基于java.net.URL上进行处理的：

```Java
URIBuilder uriBuilder = new URIBuilder("http://127.0.0.1:80.baidu.com");
String host = uriBuilder.build().getHost();
```

![image.png](https://shs3.b.qianxin.com/attack_forum/2024/02/attach-98d004d324cbbc23a2f85a90e5c9ae3ba61302a7.png)

相比自定义的工具类，当使用组件库进行处理时，一般情况下检查的方法与组件库解析的方式是一致的，从一定程度上能避免解析差异导致的绕过问题。

除了Httpclient以外，okhttp也是比较常用的HTTP组件库，具体的解析过程可以参考https://forum.butian.net/share/2427 。

2.4 自定义正则匹配
-----------

实际上UriComponentsBuilder也是一种自定义正则匹配的场景，因为在实际调用时不清楚发起请求的解析库/工具类的解析模式，当安全检查的工具类存在解析差异的便导致了绕过的风险。

发表于 2024-02-27 10:00:02
阅读 ( 22680 )
分类：漏洞分析

CVE-2024-22243与Java中常见获取host的方式

0 条评论