HTTP/2 协议下的“优先级反转”（Priority Inversion）攻击详解 描述 HTTP/2 协议引入了“流”（Stream）和“优先级”（Priority）机制，旨在优化资源加载顺序，提升Web性能。然而，攻击者可能恶意操纵流的依赖关系和权重，引发“优先级反转”（Priority Inversion），导致关键资源（如CSS、JavaScript）被低优先级或恶意请求阻塞，从而造成应用功能损坏、性能降级，甚至为DoS攻击创造新途径。此攻击利用HTTP/2的流复用和优先级控制机制，旨在破坏客户端预期的资源处理顺序。 知识点详解 第一步：理解 HTTP/2 的流、依赖与权重 HTTP/2 允许在单个TCP连接上并行传输多个“流”（即独立的请求/响应交换）。为了管理这些流的传输顺序，每个流可以设置： 依赖关系 ：每个流（依赖流）可以声明依赖另一个流（父流），形成树状依赖树。父流传输完成前，依赖流的处理会被延迟。 权重 ：同层级（共享同一父流）的多个兄弟流，根据权重比例共享带宽。权重值范围1~256，默认值为16。 依赖与权重共同决定了流的处理顺序和带宽分配。客户端（如浏览器）会精心构建依赖树，优先加载关键资源。 第二步：优先级反转攻击原理 攻击者（通常控制恶意服务器或中间人）通过篡改HTTP/2优先级帧（PRIORITY frame）或利用HTTP/2到HTTP/1.1的转换缺陷，破坏客户端设定的依赖树，导致： 关键资源被延迟 ：将本应高优先级的流（如 /main.js ）错误地设置为依赖一个低优先级或长时间阻塞的流（如恶意大文件），使关键脚本的传输被延迟，页面功能受损。 带宽分配失衡 ：恶意设置权重，使非关键流获得不成比例的高带宽，挤占关键资源传输，造成性能降级。 优先级反转本质上是一种“资源排序攻击”，破坏了客户端对资源加载顺序的假设。 第三步：攻击场景与步骤 常见于两种攻击场景： 场景一：恶意服务器主动发起 攻击前提 ：用户访问攻击者控制的网站，或网站被攻陷，攻击者控制了部分HTTP响应。 攻击步骤 ： a. 攻击者在响应关键资源（如CSS文件）的HTTP响应中，插入一个PRIORITY帧，声明该流依赖于一个攻击者精心构造的低优先级/长时间运行/不存在的流（如 /blocker ）。 b. 同时，攻击者可发送一个对 /blocker 的大响应，或故意不发送其响应数据。 c. 客户端收到PRIORITY帧后，重构依赖树，导致关键CSS流等待 /blocker 流，造成页面渲染阻塞或样式错乱。 场景二：利用中间人篡改 攻击前提 ：攻击者具备中间人位置（如恶意代理、网关），可修改HTTP/2流量。 攻击步骤 ： a. 拦截客户端发送的HTTP/2请求，这些请求可能已包含浏览器优化的优先级设置。 b. 修改其中的PRIORITY帧，将关键流的依赖关系指向一个恶意构造的低优先级流。 c. 将篡改后的请求转发给服务器，并将服务器响应转发给客户端。 d. 客户端基于被篡改的优先级处理响应，导致关键资源延迟。 第四步：防御措施 服务器端防御 ： 优先级校验 ：HTTP/2服务器应校验接收到的优先级设置是否合理，例如拒绝导致循环依赖的优先级设置，或忽略明显异常的依赖关系（如将关键资源依赖到权重极低或不存在的流）。 限制优先级变更 ：可限制一个流在生命周期内修改优先级的次数，或仅在连接建立初期允许设置优先级。 HTTP/2到HTTP/1.1降级处理 ：在反向代理/负载均衡器进行HTTP/2到HTTP/1.1转换时，需谨慎处理优先级信息，避免在降级过程中引入依赖混乱。 客户端防御 ： 实现优先级保护 ：客户端（浏览器、HTTP客户端库）应具备对接收到的优先级更新的验证机制，可忽略明显恶意的优先级更新，或采用“优先级固定”策略，对关键资源的优先级不轻易更改。 超时与重置机制 ：如果一个流因依赖问题长时间未收到数据，客户端应能检测并发送RST_ STREAM帧重置该流，或建立新连接绕过问题。 协议与部署规范 ： 遵循RFC 9113 ：严格遵循HTTP/2（RFC 9113）规范，其中包含了对优先级处理的更严格规定，旨在减少优先级逻辑的复杂度与漏洞。 监控与告警 ：在生产环境监控异常优先级模式，如大量优先级更新、循环依赖错误等，并设置告警。 第五步：总结 HTTP/2优先级反转攻击是一种较新的应用层协议滥用，它不直接窃取数据，而是通过操纵资源加载顺序破坏应用可用性与性能。防御需在服务器端、客户端及网络基础设施层面协同实施，通过校验、限制、监控等措施，确保优先级机制按预期工作，不被恶意利用。