缓存欺骗

在测试期间，能够识别缓存的响应至关重要，各种响应标头可能指示它已被缓存。例如：

  • X-Cache 标头提供有关是否从缓存提供响应的信息。典型值包括：
    • X-Cache： hit - 响应是从缓存中提供的。
    • X-Cache： miss - 缓存不包含请求密钥的响应，因此它是从源服务器获取的。在大多数情况下，响应随后被缓存。要确认这一点，请再次发送请求以查看值是否更新为 hit。
    • X-Cache： dynamic - 源服务器动态生成内容。通常，这意味着响应不适合缓存。
    • X-Cache： refresh - 缓存的内容已过时，需要刷新或重新验证。
  • Cache-Control 标头可能包含指示缓存的指令，例如 max-age （单位是秒）为大于 0 的 值。请注意，这仅表明资源是可缓存的。它并不总是表示缓存，因为缓存有时可能会覆盖此标头。

缓存欺骗

  • 一般来说，构建基本的 Web 缓存欺骗攻击包括以下步骤：
    1. 寻找能够返回敏感信息的请求，重点关注 GET、HEAD 或 OPTIONS 请求，因为用于增删改的请求通常不会缓存。
    2. 确定缓存和源服务器解析 URL 路径的方式是否存在差异：
      • /my-account/test.js被源服务器识别为/my-account，一旦/my-account/test.js可缓存，那么/my-account就会被缓存
      • /settings/users/list;aaa.js被源服务器识别为/settings/users/list ，一旦/settings/users/list;aaa.js可缓存，那么/settings/users/list 就会被缓存
      • /image/..%2Fimageassest/1.js被识别为/image/assest/1.js，一旦/image/..%2Fimageassest/1.js可缓存，那么/image/assest/1.js就会被缓存
    3. 制作一个恶意 URL，当受害者访问 URL 时，他们的响应将存储在缓存中。然后使用 Burp或Reqable向目标发起一个请求

缓存键是缓存服务器针对要做缓存的资源做的匹配规则，这种缓存键用户无法控制，以下是一些关于缓存服务器和源服务器在处理url时的特点：

  • 缓存服务器以路径前缀作为缓存键
  • 源服务器忽略了路径后缀，即忽略了分隔符及后面的部分
  • 缓存服务器和源服务器各自都可能做路径标准化
  • 缓存服务器以静态拓展名作为缓存键
  • 缓存服务器以特定的文件名作为缓存键，如 robots.txt、index.html 和 favicon.ico

漏洞挖掘的具体步骤：

  • 找到想要缓存的目标url，如/myaccount

  • 尝试以下方式（正向）

    • 假设缓存服务器以路径前缀作为缓存键，比如/resource，设计一段payload为/resource/../myaccount
    • 假设缓存服务器以静态拓展名作为缓存键，比如.js，设计一段payload为/myaccount;.js，注意，分隔符和后缀都是可以爆破的
    • 假设缓存服务器以路径后缀作为缓存键，比如/assest，设计一段payload为/myaccount/assest，payload是否成功取决于/assest是否被源服务器忽略
    • 假设缓存服务器以特定文件作为后缀，比如robots.txt，设计一段payload为/myaccount;robots.txt，除此之外还可能以特定文件作为前缀，不过可能性较小

  • 尝试以下方式（逆向）

    • 判断源服务器使用哪些分隔符，这可以使用intruder爆破分隔符，能够得到正常响应的都是可以使用的分隔符，初始payload为/myaccount;123
    • 判断源服务器是否做路径标准化，paylaod为/abc/../my-account，如果正常响应说明有做路径标准化，否则没做
    • 判断缓存服务器是否做路径标准化，payload为/aaa/../robots.txt（/robots.txt确定会被缓存），如果响应头显示有Cache表明缓存服务器会做路径标准化，否则没做
    • 判断缓存服务器会缓存哪些文件，可以使用intruder爆破文件拓展，响应有cache的表明该类型文件会被缓存，初始payload为/static.js（/static.js已确定可缓存）

  • 当目标url被成功缓存，就可以开始构造页面

    <script>document.location="url"</script>

    诱导用户点击这个页面从而缓存url

  • 攻击者再次访问这段url既可以获取用户的敏感信息

你可以采取一系列措施来防止 Web 缓存欺骗漏洞：

  • 始终使用 Cache-Control 标头来标记动态资源，使用指令 no-store 和 private 进行设置。
  • 配置您的 CDN 设置，以便您的缓存规则不会覆盖 Cache-Control 标头。
  • 激活 CDN 针对 Web 缓存欺骗攻击的任何保护。许多 CDN 允许您设置缓存规则，以验证响应 Content-Type 是否与请求的 URL 文件扩展名匹配。例如，Cloudflare 的 Cache Deception Armor。
  • 验证源服务器和缓存解释 URL 路径的方式之间是否没有任何差异。

Cache-Control： no-store 完全阻止缓存。

Pragma： no-cache（或 Cache-Control： no-cache）允许缓存，但在提供缓存内容之前需要与服务器重新验证。

缓存投毒

  • X-Forwarded-Host的内容被缓存，导致缓存时会从指定的ip获取资源如恶意脚本从而触发蠕虫xss

修复漏洞

缓存投毒的形式

缓存投毒（Cache Poisoning）是一种攻击手段，攻击者通过操纵缓存内容，使缓存服务器存储并返回恶意数据。除了你提到的借助静态资源缓存敏感信息和借助请求头不可信的输入缓存响应造成蠕虫，缓存投毒还有以下几种形式：

  1. 参数污染：
    • 攻击者通过操纵URL参数或查询字符串，使缓存服务器存储恶意响应。例如，攻击者可能通过修改URL中的参数，使缓存服务器存储包含恶意脚本的响应。
  2. Cookie注入：
    • 攻击者通过操纵Cookie，使缓存服务器存储恶意响应。例如，攻击者可能通过修改Cookie值，使缓存服务器存储包含恶意内容的响应。
  3. HTTP头注入：
    • 攻击者通过操纵HTTP请求头，使缓存服务器存储恶意响应。例如，攻击者可能通过修改User-Agent或Referer头，使缓存服务器存储包含恶意内容的响应。
  4. 缓存键污染：
    • 攻击者通过操纵缓存键（Cache Key），使缓存服务器存储恶意响应。例如，攻击者可能通过修改请求中的某些部分，使缓存服务器错误地将恶意响应与正常请求关联起来。
  5. 缓存时间操纵：
    • 攻击者通过操纵缓存时间（Cache Duration），使缓存服务器长时间存储恶意响应。例如，攻击者可能通过修改Cache-Control头，使缓存服务器长时间存储包含恶意内容的响应。
  6. 缓存分区污染：
    • 攻击者通过操纵缓存分区（Cache Partitioning），使缓存服务器存储恶意响应。例如，攻击者可能通过修改请求中的某些部分，使缓存服务器将恶意响应存储在不同的缓存分区中，从而影响其他用户的请求。
  7. 缓存刷新攻击：
    • 攻击者通过频繁请求特定资源，使缓存服务器频繁刷新缓存，从而降低系统性能或使缓存服务器存储恶意响应。
  8. 缓存绕过攻击：
    • 攻击者通过操纵请求，使缓存服务器绕过缓存直接请求源服务器，从而获取或注入恶意内容。
  9. 缓存欺骗：
    • 攻击者通过伪造请求，使缓存服务器存储恶意响应。例如，攻击者可能通过伪造请求，使缓存服务器存储包含恶意脚本的响应。
  10. 缓存重放攻击：
    • 攻击者通过重放旧请求，使缓存服务器存储旧响应，从而影响系统性能或使缓存服务器存储恶意响应。

tomcat路径穿越

tomcat 对url 特殊字符的处理主要是三个步骤对于三个函数：

  • 先是postParseRequest() 函数对’;’ 分号进行处理。比如把’/123;456/’ 替换为’/123/’。

  • 然后是调用req.getURLDecoder().convert() 函数对URL 中进行了URL编码的字符进行解码，其中如果解码之后的结果是’/’ ,也就是输入的URL 含有’%2f’ 就会返回400。

  • 接着是调用normalize() 函数对URL 进行规范化，比如处理’/…/’ ，’/./’ ,’\’,’//’ 。另外URL中如果含有空字符串，则会返回400.如果规范化后的url 是以’…/’开头的，也会返回400。

/xxkj/api/xxkj/user/...;/user/userInfo

经过tomcat处理后变为/xxkj/api/xxkj/user/userInfo