burpsuite 官方博客 介绍的web安全缓存投毒安全漏洞,自从2017年web缓存投毒在blackhat上介绍后,这几年持续有相关的研究发表 Practical Web Cache Poisoning: Redefining 'Unexploitable' James Kettle - james.kettle@portswigger.net - @albinowax Abstract Web cache poisoning has long been an elusive vulnerability, a 'theoretical' threat used mostly to scare developers into obediently patching issues that nobody could actually exploit. m o In this paper I'll show you how to compromise websites by using esoteric web features to turn their caches into exploit delivery systems, targeting everyone that makes the mistake of visiting their homepage. c . 5 I'll illustrate and develop this technique with vulnerabilities that handed me control over numerous popular websites and frameworks, progressing from simple single-request attacks to intricate exploit chains that hijack JavaScript, pivot across cache layers, subvert social media and misdirect cloud services. I'll wrap up by discussing defense against cache poisoning, and releasing the open source Burp Suite Community extension that fueled this research. h t i g b u Core Concepts Caching 101 To grasp cache poisoning, we'll need to take a quick look at the fundamentals of caching. Web caches sit between the user and the application server, where they save and serve copies of certain responses. In the diagram below, we can see three users fetching the same resource one after the other: Cache Time User Website m o Caching is intended to speed up page loads by reducing latency, and also reduce load on the application server. Some companies host their own cache using software like Varnish, and others opt to rely on a Content Delivery Network (CDN) like Cloudflare, with caches scattered across geographical locations. Also, some popular web applications and frameworks like Drupal have a built-in cache. c . 5 b u There are also other types of cache, such as client-side browser caches and DNS caches, but they're not the focus of this research. Cache keys h t i g The concept of caching might sound clean and simple, but it hides some risky assumptions. Whenever a cache receives a request for a resource, it needs to decide whether it has a copy of this exact resource already saved and can reply with that, or if it needs to forward the request to the application server. Identifying whether two requests are trying to load the same resource can be tricky; requiring that the requests match byte-for-byte is utterly ineffective, as HTTP requests are full of inconsequential data, such as the requester's browser: GET /blog/post.php?mobile=1 HTTP/1.1  Host: example.com  User­Agent: Mozilla/5.0 … Firefox/57.0  Accept: */*; q=0.01  Accept­Language: en­US,en;q=0.5  Accept­Encoding: gzip, deflate  Referer: https://google.com/  Cookie: jessionid=xyz;  Connection: close Caches tackle this problem using the concept of cache keys – a few specific components of a HTTP request that are taken to fully identify the resource being requested. In the request above, I've highlighted the values included in a typical cache key in orange. This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first: GET /blog/post.php?mobile=1 HTTP/1.1  Host: example.com  User­Agent: Mozilla/5.0 … Firefox/57.0  Cookie: language=pl;  Connection: close GET /blog/post.php?mobile=1 HTTP/1.1  Host: example.com  User­Agent: Mozilla/5.0 … Firefox/57.0  Cookie: language=en;  Connection: close As a result, the page will be served in the wrong language to the second visitor. This hints at the problem – any difference in the response triggered by an unkeyed input may be stored and served to other users. In theory, sites can use the 'Vary' response header to specify additional request headers that should be keyed. in practice, the Vary header is only used in a rudimentary way, CDNs like Cloudflare ignore it outright, and people don't even realise their application supports any header-based input. This causes a healthy number of accidental breakages, but the fun really starts when someone intentionally sets out to exploit it. m o Cache Poisoning c . 5 The objective of web cache poisoning is to send a request that causes a harmful response that gets saved in the cache and served to other users. Time User b u Cache h t i g Website In this paper, we're going to poison caches using unkeyed inputs like HTTP headers. This isn't the only way of poisoning caches - you can also use HTTP Response Splitting and Request Smuggling1 - but I think it's the best.

pdf文档 burp web cache poisoning web缓存投毒 英文版

安全文档 > 网络安全 > > 文档预览
19 页 1 下载 13 浏览 0 评论 0 收藏 3.0分
温馨提示:当前文档最多只能预览 7 页,若文档总页数超出了 7 页,请下载原文档以浏览全部内容。
本文档由 路人甲2022-05-30 19:42:18上传分享
给文档打分
您好可以输入 255 个字符
github5文库的中文名是什么?( 答案:github5 )
评论列表
  • 暂时还没有评论,期待您的金玉良言