网络安全最全HTTP请求走私漏洞简单分析_apache 2，2024年最新【深度思考】

本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。

最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。

最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。

学习路线图

其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。

相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。

网络安全工具箱

当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。

项目实战

最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

面试题

归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

• Apache mod_proxy配置请求走私攻击

---

HTTP请求走私漏洞的产生

在HTTP/1.1中，HTTP请求走私漏洞出现，是因为HTTP规范提供了两种不同的方法指定请求位置的结束即我们说的Content-Length 和Transfer-Encoding标头，分别表示正文内容的长度和是否分块，当同时使用这两种方法的时候，如果前端和后端服务器处理表头的时候出现了歧义，则会出现处理情况的不同，从而导致了请求走私漏洞，比如说：

图中由于前端服务器不支持Transfer-Encoding分块，因此正文的所有数据由于Content-Length被传入到了后端服务器中，而后端服务器因为支持Transfer-Encoding，遇到0的时候，就停止了接收，后面请求的admin就被认为是一次新的请求，两个服务器之间的歧义导致了HTTP请求走私漏洞。

HTTP请求走私漏洞的分类

1. CL.TE：前端服务器使用 Content-Length 标头和后端服务器使用 Transfer-Encoding 页眉
2. TE.CL：前端服务器使用 Transfer-Encoding 标头和后端服务器使用 Content-Length 页眉
3. TE.TE：前端和后端服务器都支持 Transfer-Encoding 标头，但两个服务器处理Transfer-Encoding产生歧义

HTTP请求走私攻击的危害

由于当今的Web应用程序之间大都采用HTTP服务器链的形式，有时为了负载均衡等各种原因，都会设置多个代理或均衡器，最终这些服务器请求都转发到了一个或多个后端服务器中，假若这些类型的架构在服务器处理HTTP请求时发生了歧义，会产生巨大的危害。

1. 会话劫持: 攻击者可以使用HTTP请求走私攻击来劫持用户的会话，获取用户的敏感信息，例如登录凭据、会话标识符等。攻击者可以利用这些信息冒充用户，执行未经授权的操作。
2. 身份伪装: 攻击者能够通过HTTP请求走私攻击伪装成合法的用户，绕过一些安全机制和防护措施。这可能导致攻击者获得未授权的访问权限，例如访问受限资源或执行特权操作。
3. 敏感信息泄露: 攻击者可以利用HTTP请求走私漏洞，通过注入恶意请求将敏感信息泄漏给第三方。这些信息可能包括用户的个人身份信息、金融数据、业务逻辑、系统配置等。
4. 业务破坏: 攻击者可以使用HTTP请求走私攻击来破坏正常的业务流程。例如，他们可以篡改或删除HTTP请求头、操纵响应内容、劫持会话等，导致应用程序无法正常工作，影响用户体验和业务流程。
5. 安全漏洞利用: HTTP请求走私攻击可能与其他安全漏洞相结合，从而导致更严重的安全问题。攻击者可能会利用该漏洞执行其他攻击，如跨站脚本攻击 (XSS)、跨站请求伪造 (CSRF)、服务器端请求伪造 (SSRF) ，等。

确认HTTP请求走私漏洞

通过时间延迟技术确认CL漏洞

由于前端服务器使用的是Content-Length标头，而后端服务器使用的是Transfer-Encoding，因此前端服务器仅会转发一部分，后端服务器处理了第一个区块，因为还没结束符，所以会等待下一个区块的到达，可以有明显的时间延迟。

POST / HTTP/1.1 
Host: aiwin.com
Transfer-Encoding: chunked 
Content-Length: 3

1 
X

如以上数据包为例，前端使用Content-length，只会发送3个长度的数据，发送到了1，而后端使用的是chunked，会一直等待下一区块的到来，或者等待结束符0的到来。

通过时间延迟技术寻找TE.CL漏洞

由于前端服务器使用Transfer-Encoding表头，仅转发请求的一部分，后端服务器使用的是Content-Length表头，在等待着剩余内容的到达，也可以观察到时间延迟

POST / HTTP/1.1 
Host: aiwin.com
Transfer-Encoding: chunked 
Content-Length: 6

0

X

如上数据包，前端服务器使用的是chunked，会转发到0之前的正文，但是后端服务器使用的是Content-Length，长度为6，而转发到0，长度仅为3，所以会等待后面3个长度的正文到来，会导致时间延迟

使用差异响应内容确认漏洞

通过走私漏洞，能够干扰正确请求的响应包，通过正常请求的响应来确认漏洞。

通过差异响应确认CL.TE漏洞

如下数据包，由于前端服务器使用的是Content-Length，所以全部数据都被发送到了后端服务器中，而后端服务器使用的是Transfer-Encoding，数据接收到0后就停止了，下面GET的请求被认为是新一次的请求处理，返回了404 Not Found。

通过差异响应确认TE.CL漏洞

如下HTTP请求包，由于前端服务器使用的是TE，所以全部数据毫无问题的发送到了后端服务器，而后端服务器使用的是CL，只接收到了5e的数据，下面的POST数据被认为是新一次的请求被后端服务器处理，返回了404。

请求走私漏洞的利用

通过请求漏洞绕过URL访问的限制

如下数据包，访问/admin页面，是被403掉的

因为这里存在请求走私漏洞，CL-TE漏洞，所以前端将全部的数据传入到了后端，而后端使用的是TE，接收到0后停止，下一次请求/admin被认为是新一次的请求，而此次请求的Host为本地，因此可以绕过403

通过请求走私漏洞绕过客户端认证

一般在https中，作为TLS握手的一部分，服务器需要提供证书向客户端进行身份认证，证书包含通用名称，该名称需要与注册的主机名相匹配，客户端可以使用它验证是否与合法服务器进行通信。

GET /admin HTTP/1.1
Host: aiwin.com
X-SSL-CLIENT-CN: aiwin

一般这些CN标头对用户是隐藏的，如果能够发送正确的CN头和值，可能能偶绕过访问控制，在前端中，如果这些头已经存在，前端服务器会覆盖它们，因此不太可利用，而走私的请求可以绕过前端，原封不动的发送给后端，绕过验证。

POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 64
Transfer-Encoding: chunked


## 写在最后

**在结束之际，我想重申的是，学习并非如攀登险峻高峰，而是如滴水穿石般的持久累积。尤其当我们步入工作岗位之后，持之以恒的学习变得愈发不易，如同在茫茫大海中独自划舟，稍有松懈便可能被巨浪吞噬。然而，对于我们程序员而言，学习是生存之本，是我们在激烈市场竞争中立于不败之地的关键。一旦停止学习，我们便如同逆水行舟，不进则退，终将被时代的洪流所淘汰。因此，不断汲取新知识，不仅是对自己的提升，更是对自己的一份珍贵投资。让我们不断磨砺自己，与时代共同进步，书写属于我们的辉煌篇章。**


需要完整版PDF学习资源私我



**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化资料的朋友，可以点击这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**