CVE-2023-28708 原理剖析-Toy模板网

这篇具有很好参考价值的文章主要介绍了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这个文件中搜索该关键字
CVE-2023-28708 原理剖析

如果获取到X-Forwarded-Proto 并且其值为https就设置Secure属性为True，这个属性最终就体现在cookie上，我们假设一种情况，当反代服务器与提供服务的服务器之间使用http通信时会发生什么，因为反代服务器设置了X-Forwarded-Proto: https，服务提供者会将请求的secure属性设置为True导致被设置了secure的cookie被通过http传输，从而使的cookie存在被劫持的可能。
CVE-2023-28708 原理剖析
这几乎就是这个漏洞的全部
我们看看官方的修复commit
Fix BZ 66471 - JSessionId secure attribute missing with RemoteIpFilte…

老实说他这个修复方法我没太看懂
修改了setSecure方法，获取了request对象，修改后获取的request应该和修改前不一样，修改前获取的是XForwardedRequest对象，修改后应该是原始的ServletRequest对象，所以这里设置secure属性并没有修改到XRequest对象的secure值，所以并不会对转发请求造成影响，从而完成修复
CVE-2023-28708 原理剖析