HTTP 请求夹带(smuggling)攻击
什么是HTTP请求夹带(smuggling)攻击
HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术。
请求夹带漏洞危害,允许攻击者绕过安全控制,获取对敏感数据的未授权访问,并直接危及其他应用程序用户。
HTTP请求夹带攻击是怎么发生的?
今天的Web应用程序经常在用户和最终应用程序逻辑之间使用HTTP服务器链。
用户将请求发送到前端服务器(有时称为负载平衡器或反向代理),此服务器将请求转发给一个或多个后端服务器。
在现代基于云的应用程序中,这种类型的体系结构越来越常见,并且在某些情况下是不可避免的。
当前端服务器将HTTP请求转发到后端服务器时,它通常通过相同的后端网络连接发送多个请求,因为这样做效率更高,性能更高。
协议非常简单:HTTP请求一个接一个地发送,接收服务器解析HTTP请求标头以确定一个请求结束的位置和下一个请求的开始:
在这种情况下,前端和后端系统就请求之间的界限达成一致至关重要。否则,攻击者可能会发送一个模糊的请求,前端和后端系统会对其进行不同的解释:
在这里,攻击者将后端服务器的部分前端请求解释为下一个请求的开始。它有效地预先附加到下一个请求,因此可能会干扰应用程序处理请求的方式。这是一次请求夹带攻击,它可能会造成严重的后果。
如何构造 HTTP 请求夹带漏洞
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标头可用于指定消息体使用分块编码。
这意味着报文包含一个或多个数据块。 每个块包含以字节为单位的块大小(以十六进制表示),后跟换行符,后跟块内容。 消息以大小为零的块结束。 例如:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked b
q=smuggling
由于HTTP规范提供了两种不同的方法来指定HTTP消息的长度,因此单个消息可以同时使用这两种方法,这样它们就会相互冲突。
HTTP规范试图通过声明防止此问题,如果Content-Length和Transfer-Encoding标头都存在,则应忽略Content-Length标头。这可能足以避免在只有一台服务器正在运行时出现歧义,但在两台或多台服务器链接在一起时则不行。
在这种情况下,出现问题有两个原因:
1.某些服务器不支持请求中的Transfer-Encoding标头。
2.如果标头以某种方式进行模糊处理,则可能会导致某些支持Transfer-Encoding标头的服务器不处理它。
如果前端服务器和后端服务器与(可能模糊的)Transfer-Encoding标头的行为不同,那么他们可能不同意连续请求之间的边界,从而导致请求夹带漏洞。
如何执行HTTP请求夹带攻击
请求夹带攻击涉及将Content-Length头和Transfer-Encoding头放入单个HTTP请求并对其进行操作,以便前端和后端服务器以不同方式处理请求。完成此操作的确切方式取决于两台服务器的行为:
CL.TE:前端服务器使用Content-Length头,后端服务器使用Transfer-Encoding头。
TE.CL:前端服务器使用Transfer-Encoding标头,后端服务器使用Content-Length标头。
TE.TE:前端和后端服务器都支持Transfer-Encoding标头,但是可以通过以某种方式模糊标头来诱导其中一个服务器不处理它
CL.TE漏洞
这里前端服务器使用Content-Length头,后端服务器使用Transfer-Encoding头。我们可以执行简单的HTTP请求夹带攻击,如下所示:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length:
Transfer-Encoding: chunked SMUGGLED
前端服务器处理Content-Length头并确定请求主体长度为13个字节,直到SMUGGLED结束。此请求将转发到后端服务器。
后端服务器处理Transfer-Encoding标头,因此将消息体视为使用分块编码。
它处理第一个块,它被称为零长度,因此被视为终止请求。以下字节SMUGGLED未经处理,后端服务器将这些字节视为序列中下一个请求的开始。
TE.CL漏洞
这里,前端服务器使用Transfer-Encoding标头,后端服务器使用Content-Length标头。我们可以执行简单的HTTP请求夹带攻击,如下所示:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length:
Transfer-Encoding: chunked SMUGGLED
注意:
要使用Burp Repeater发送此请求,您首先需要转到Repeater菜单,并确保未选中“Update Content-Length”选项。
您需要在最后的0之后包含尾随序列\r\n\r\n
前端服务器处理Transfer-Encoding标头,因此将消息体视为使用分块编码。它处理第一个块,长度为8个字节,直到SMUGGLED之后的行的开头。它处理第二个块,它被称为零长度,因此被视为终止请求。此请求将转发到后端服务器。
后端服务器处理Content-Length标头并确定请求主体长度为3个字节,直到8之后的行的开头。以SMUGGLED开头的以下字节未经处理,后端服务器将这些视为序列中下一个请求的开头。
TE.TE行为:混淆TE头、
这里,前端和后端服务器都支持Transfer-Encoding标头,但是可以通过以某种方式模糊标头来诱导其中一个服务器不处理它。
有可能无休止地混淆Transfer-Encoding标头。例如:
Transfer-Encoding: xchunked Transfer-Encoding : chunked Transfer-Encoding: chunked
Transfer-Encoding: x Transfer-Encoding:[tab]chunked [space]Transfer-Encoding: chunked X: X[\n]Transfer-Encoding: chunked Transfer-Encoding
: chunked
这些技术中的每一种都涉及到与HTTP规范的细微偏离。实现协议规范的实际代码很少以绝对精度遵守它,并且不同的实现通常容忍规范的不同变化。要发现TE.TE漏洞,有必要找到Transfer-Encoding标头的一些变体,以便只有一个前端或后端服务器处理它,而另一个服务器忽略它。
根据是否可以诱导不处理混淆的Transfer-Encoding标头的前端服务器或后端服务器,攻击的其余部分将采用与CL.TE或TE.CL漏洞相同的形式已经描述过。
如何防止HTTP请求夹带漏洞
在前端服务器通过同一网络连接将多个请求转发到后端服务器的情况下会出现HTTP请求走私漏洞,并且用于后端连接的协议存在两个服务器不同意关于两者之间边界的风险要求。防止HTTP请求走私漏洞的一些通用方法如下:
禁用后端连接的重用,以便通过单独的网络连接发送每个后端请求。
使用HTTP / 2进行后端连接,因为此协议可防止请求之间的边界模糊不清。
为前端和后端服务器使用完全相同的Web服务器软件,以便他们就请求之间的界限达成一致。
在某些情况下,可以通过使前端服务器规范化模糊请求或使后端服务器拒绝模糊请求并关闭网络连接来避免漏洞。然而,这些方法可能比上面确定的通用缓解更容易出错。
web-security 练习
要解决实验问题,请将请求走私到后端服务器,以便后端服务器处理的下一个请求似乎使用GPOST方法。
https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te
https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl
https://portswigger.net/web-security/request-smuggling/lab-ofuscating-te-header
参考
https://portswigger.net/web-security/request-smuggling
HTTP 请求夹带(smuggling)攻击的更多相关文章
- ASP.NET WebForm中异步请求防止XSRF攻击的方法
在ASP.NET MVC中微软已经提供了如何防止跨域攻击的方法.对于传统Webfrom中使用Handler来接受ajax的Post请求数据,如何来防止XSRF攻击呢.这里给大家提供一个简单地方法,和M ...
- CSRF(跨站请求伪造)攻击
CSRF(跨站请求伪造)攻击 CSRF(Cross Site Request Forgery,跨站请求伪造)是一种近年来才逐渐被大众了解的网络攻击方式,又被称为One-Click Attack或Ses ...
- 跨站请求伪造(CSRF)攻击原理解析:比你所想的更危险
跨站请求伪造(CSRF)攻击原理解析:比你所想的更危险 跨站请求伪造(Cross-Site Request Forgery)或许是最令人难以理解的一种攻击方式了,但也正因如此,它的危险性也被人们所低估 ...
- mvc3.0防止跨站点请求伪造(CSRF)攻击
众所周知,asp.net mvc程序在浏览器运行是产生标准的Html标签,包括浏览器要发送的关键数据等内容都在html内容里面.听起来不错,但是假如我们伪造类似的html内容,更改里面的关键数据,在浏 ...
- 跨站请求伪造(CSRF攻击)理解
一 概念 你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求.CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账......造成的 ...
- 防止跨站请求伪造(CSRF)攻击 和 防重复提交 的方法的实现
CSRF的概念可以参考:http://netsecurity.51cto.com/art/200812/102951.htm 本文介绍的是基于spring拦截器的Spring MVC实现 首先配置拦截 ...
- 利用Haproxy搭建 HTTP 请求走私(Request smuggling)环境
Haproxy 介绍 HAProxy是一个使用C语言编写的自由及开放源代码软件,其提供高可用性.负载均衡,以及基于TCP和HTTP的应用程序代理. 请求走私(Request smuggling)概念证 ...
- ASP.NET Core 防止跨站请求伪造(XSRF/CSRF)攻击
什么是反伪造攻击? 跨站点请求伪造(也称为XSRF或CSRF,发音为see-surf)是对Web托管应用程序的攻击,因为恶意网站可能会影响客户端浏览器和浏览器信任网站之间的交互.这种攻击是完全有可能的 ...
- ASP.NET Core 防止跨站请求伪造(XSRF/CSRF)攻击 (转载)
什么是反伪造攻击? 跨站点请求伪造(也称为XSRF或CSRF,发音为see-surf)是对Web托管应用程序的攻击,因为恶意网站可能会影响客户端浏览器和浏览器信任网站之间的交互.这种攻击是完全有可能的 ...
随机推荐
- python数学工具(一)
python 数学工具包括: 1.函数的逼近 1.1.回归 1.2.插值 2.凸优化3.积分4.符号数学 本文介绍函数的逼近的回归方法 1.作为基函数的单项式 对函数 的拟合 首先定义函数并且可视化 ...
- jenkins持续集成工作原理、功能、部署方式等介绍
超详细的jenkins持续集成工作原理.功能.部署方式等介绍 原创 波波说运维 2019-08-29 00:01:00 概述 今天简单整理了一下jenkins的一些概念性内容,归纳如下: 1.概念 j ...
- Dubbo一致性哈希负载均衡的源码和Bug,了解一下?
本文是对于Dubbo负载均衡策略之一的一致性哈希负载均衡的详细分析.对源码逐行解读.根据实际运行结果,配以丰富的图片,可能是东半球讲一致性哈希算法在Dubbo中的实现最详细的文章了. 文中所示源码,没 ...
- 大数据学习笔记——Java篇之基础知识
Java / 计算机基础知识整理 在进行知识梳理同时也是个人的第一篇技术博客之前,首先祝贺一下,经历了一年左右的学习,从完完全全的计算机小白,现在终于可以做一些产出了!可以说也是颇为感慨,个人认为,学 ...
- 函数计算: 让小程序开发进入 Serverless 时代
点击下载<不一样的 双11 技术:阿里巴巴经济体云原生实践> 本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击上方图片即可下载! 作者 | 吴天龙(木吴 ...
- JS-选择排序
选择排序 选择排序的原理如下.遍历数组,设置最小值的索引为 0,如果取出的值比当前最小值小,就替换最小值索引,遍历完成后,将第一个元素和最小值索引上的值交换.如上操作后,第一个元素就是数组中的最小值, ...
- 《MySQL数据库》MySQL数据库安装(linux)
1. 下载安装包: 百度网盘:链接: https://pan.baidu.com/s/1toGl8O9gMBpDWn0mHWwFyg 提取码: i51g 官网下载:https://dev.mysql ...
- 自定义滚动条(Custom ScrollBar)
时间如流水,只能流去不流回! 点赞再看,养成习惯,这是您给我创作的动力! 本文 Dotnet9 https://dotnet9.com 已收录,站长乐于分享dotnet相关技术,比如Winform.W ...
- SpringBoot电商项目实战 — 商品的SPU/SKU实现
最近事情有点多,所以系列文章已停止好多天了.今天我们继续Springboot电商项目实战系列文章.到目前为止,整个项目的架构和基础服务已经全部实现,分布式锁也已经讲过了.那么,现在应该到数据库设计及代 ...
- 【玩转SpringBoot】让错误处理重新由web服务器接管
其实web服务器是会处理错误的 在web.xml还是随处可见的年代时(确实有点老黄历了),下面的这些配置应该都不陌生. 根据错误代码处理错误,如下图01: 根据异常类型处理错误,如下图02: 不过我们 ...