本文主要是介绍request smuggling漏洞,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
request smuggling漏洞如何产生?
大多数HTTP请求走私漏洞的出现是因为HTTP规范提供了两种不同的方法来指定请求
的结束位置:Content-Length标头和Transfer-Encoding标头。
该Content-Length头是直接的:它指定消息体的以字节为单位的长度。
例如:
POST /search HTTP/1.1
Host:normal-website.com
Content-Type:application/x-www-form-urlencoded
Content-Length:11
q=smuggling
该Transfer一Encoding首标可以被用于指定该消息体的用途分块编码。这意味着消
息正文包含一个或多个数据块。每个块均由以字节为单位的块大小(以十六进制表
示)组成,后跟换行符,然后是块内容。
该消息以大小为零(0)的块终止。
例如:
POST /search HTTP/1.1
Host:normal-website.com
Content-Type:application/x-www-form-urlencoded
Transfer-Encoding:chunked
前端和后端系统就请求之间的边界达成一致至关重要,攻击者可能能够发送不明确的请求,前端和后端系统对此进行不同的解释
攻击者导致其前端请求的一部分被后端服务器解释为下一个请求的开始。是的 有效地预置到下一个请求,因此可能会干扰应用程序处理该请求的方式。这是一个请求 走私袭击,它可能产生毁灭性的后果。
由于 HTTP 规范提供了两种不同的方法来指定 HTTP 消息的长度,因此单个 消息以同时使用这两种方法,以便它们相互冲突。HTTP 规范尝试通过以下方式防止此问题 声明如果两个标题都是 存在,则应忽略标头。这可能足以避免歧义 当只有一台服务器在运行时,但当两台或多台服务器链接在一起时则不然。在这种情况下,可能会出现两个问题
原因:Content-Length
Transfer-Encoding Content-Length
- 某些服务器不支持请求中的标头。
Transfer-Encoding
- 如果出现以下情况,则可以诱导某些支持标头的服务器不处理它 标头以某种方式被混淆。
Transfer-Encoding
如果前端服务器和后端服务器的行为与(可能混淆的)标头不同,则它们可能会在连续请求之间的边界上存在分歧,从而导致请求走私漏洞。Transfer-Encoding
这篇关于request smuggling漏洞的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!