Tomcat HTTP请求走私(CVE-2021-33037)

这是一篇在先知社区上面看到的文章，我也深入研究了一下，虽然java代码看不懂，但漏洞的成因与里面的逻辑我已经理解清楚了，这里做一下记录
原文请参考
Apache Tomcat HTTP请求走私(CVE-2021-33037)漏洞分析
影响版本
Apache Tomcat 10.0.0-M1-10.0.6
Apache Tomcat 9.0.0.M1-9.0.46
Apache Tomcat 8.5.0-8.5.66

该漏洞的成因是因为tomacat在某些情况下没有正确得解析传输编码标头transfer-encoding导致的，tomacat在实现http协议的时候有一个包叫做http11,里面包含了http0.9 http1.0 http1.1的实现，问题就出在这个包里面，这个我们后面再讨论。这里先讲一下我在读文章的时候先去看了一下transfer-encoding的选项及其格式，Transfer-Encoding
可以在文中看到，如果te的值为trunk，那么正常来讲content-length的值就将失效才对，且在post body中的数据每块的开头都要表明该分块的长度，然后跟\r\n,然后跟内容然后跟\r\n，后面还应该有一个终止块，长度为0，后面跟一些消息块

知道了这个我们再来看原文中的一张图

当我们的请求过程出现了前端代理–ngix，后端服务–tomcat的时候，如果二者在实现rfc标准存在差异的时候就可能导致http走私，我们来看这样一个例子。
用户发送一个http请求，前端识别到了te所以按照标准会忽略cl，那么途中黄色部分的所有内容就被当成了请求体，当成了数据。而后端却不这么认为，相反后端识别了cl而忽略了te，导致其按照4来获取请求体的内容，而剩下的部分被当做了下一个请求，这样一个完整的http请求就走私进来了。当然我觉得上图画的不太对，立足于本文的例子，上图的协议版本应该更改为http1.0，因为按照rfc标准，当我们使用http1.0发送带有te字段的请求的时候，如果服务端可以处理，那么他就会按照http1.1的标准正常处理，如果不能处理的话就忽略。因为tomacat在实现http1.0的时候是完全不能使用te字段的，从而导致了漏洞的产生。
本来准备按照文章复现一下的，我环境都搭好了，结果很遗憾，我不会写jsp，文章中也没有源码，我就尴了个尬！！！
当然经过我的不懈努力上网学习了一下jsp怎么写的

其实就这么一句就可以了，然后我就开始复现了。
不过结局不怎么美妙，复现失败了，我也不知道是哪儿出的问题。。。。。。。。我也很无奈啊！
然后就看到了作者大大和一个大佬的对话

作者的回复还是在我复现漏洞期间，运气也是好！！！不过我还是有点不太理解

然后让我们跟随坐着的思路来看一下tomacat在实现http协议的时候的源码，从而看看他出现的根本原因，算了，你们还是直接看原文吧！！！