这应该不是一个严重的漏洞，可能评分只能为低，因为并没有什么卵用。
话不多说，直接进入正题
我的复现环境：
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里还加了一个测试用例
如果能对该测试用例有足够的理解，理解该漏洞应该不难