CVE-2023-28708 原理剖析
这应该不是一个严重的漏洞,可能评分只能为低,因为并没有什么卵用。
话不多说,直接进入正题
我的复现环境:
tomcat-8.5.50
首先我们得简单写一个servlet,当然不写也没事,因为我们的分析到不了处理servlet这一步,只用tomcat默认提供的ROOT就行
首先我们需要在web.xml中注册RemoteIpFilter 这个过滤器
<filter>
<filter-name>remote-ip-filter</filter-name>
<filter-class>org.apache.catalina.filters.RemoteIpFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>remote-ip-filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
然后把tomcat启动起来,打断点调试,因为问题是出在X-Forwarded-Proto
这个HTTP标头,我们就在RemoteIpFilter
这个文件中搜索该关键字
如果获取到X-Forwarded-Proto
并且其值为https就设置Secure属性为True,这个属性最终就体现在cookie上,我们假设一种情况,当反代服务器与提供服务的服务器之间使用http通信时会发生什么,因为反代服务器设置了X-Forwarded-Proto: https
,服务提供者会将请求的secure属性设置为True导致被设置了secure的cookie被通过http传输,从而使的cookie存在被劫持的可能。
这几乎就是这个漏洞的全部
我们看看官方的修复commit
Fix BZ 66471 - JSessionId secure attribute missing with RemoteIpFilte…
老实说他这个修复方法我没太看懂
修改了setSecure
方法,获取了request
对象,修改后获取的request
应该和修改前不一样,修改前获取的是XForwardedRequest
对象,修改后应该是原始的ServletRequest
对象,所以这里设置secure
属性并没有修改到XRequest
对象的secure值,所以并不会对转发请求造成影响,从而完成修复
在该commit里还加了一个测试用例
如果能对该测试用例有足够的理解,理解该漏洞应该不难