文章目录
??这篇论文出自USENIX 2020，CCF-A类论文，信安四大之一。
??这篇论文讲述了web缓存欺骗攻击在真实的网站中的存在情况，并设计了一套测量该类攻击的方法，测量该攻击在Alexa Top网站中的存在情况。
1 背景
??在讲解检测方法之前，我们先来熟悉一下什么是web缓存欺骗攻击。
1.1 web缓存
??我们都知道，在web服务器和终端用户之间频繁地交互数据是一件开销很大的事情。在客户机和服务器之间进行长距离的多次往返时，如果遇到网络中常见的技术问题或路由问题时，可能导致网站延迟的增加，进而导致web应用程序被判定为无响应。另外，经常访问的资源会浪费web服务器的计算周期和网络带宽。
??缓存成为了这种问题的解决方案。缓存技术很常见，我们的计算机里也同样用到了缓存技术，减少CPU访问主存的次数，提高计算效率。
??web缓存也是类似的道理，一些客户端应用程序例如web浏览器会为单个用户实现自己的私有缓存。或者web缓存作为通信路径上的中间人代理，实现一个共享缓存，存储和服务多个用户频繁访问的对象。如果缓存命中，则不必去原始服务器请求对象，这大大提高了数据传输效率。
??特别的，web缓存是CDN的一个关键组成部分。CDN在全球部署共享缓存代理（也称边缘服务器），形成大规模分布式网络，当用户发起请求时，CDN会选择距离用户最近的缓存去提供内容，而不必由源站去响应。
??web缓存的目标通常是静态资源，包括静态HTML页面、脚本、样式表、图片及其他媒体文件、软件下载等。大多数缓存的共享特性使得那些动态的、个性化的、包含用户隐私的信息不会被缓存。
1.2 路径混淆
??URL通过将web资源直接映射到web服务器的文件系统结构来引用这些资源，例如
example.com/home/index.html?lang=en
该URL对应web服务器文档根目录下的index.html，lang=en代表语言参数。
??web应用程序的规模和复杂性都在增加，web服务器引入了URL重写技术，实现高级路由结构、提升资源的可用性和可访问性。该技术导致了web服务器解析、处理和解释URL的方式并不能清晰地反应在URL字符串的外部可见表示中（通俗地讲就是你并不知道服务器是对这个URL做怎样处理的）。因此，web缓存是无法得知资源文件系统路径和URL之间的这个额外抽象层的，它们会以自己的方式去处理URL，这就是路径混淆。
??REST-ful URL的广泛使用有助于说明由URL的不同解释产生的问题。REST-ful URL方案使用的结构与web服务器内部资源组织的抽象不同，它提供了一个可读性更强的面向api的表示。例如web服务器可能会选择URL
example.com/index/v1/v2
去表示
example.com/index.php?p1=v1&p2=v2
现在，我们来考虑这样一个场景，还是这台web服务器，用户使用下述URL去请求
example.com/index/img/pic.jpg
在服务端与客户端的所有中间实体，如浏览器、web缓存、代理、防火墙等，都会误解这个请求，以为服务端会返回一个图片。web缓存还有可能将其视为需缓存资源。但是，在实际情况下，web服务器会将这条URL解释为
example.com/index.php?p1=img&p2=pic.jpg
然后返回index.php，响应码为200，尽管pic.jpg在服务端不存在，但还是返回了成功的状态码。
1.3 web缓存欺骗
??现在到了我们的正题，也就是web缓存欺骗，用WCD来代表这一现象。攻击者可以利用它来破坏web应用程序的机密属性，最终可能导致用户的数据泄露等安全问题。其实早在2017年，Gil等人就提出了WCD，并成功攻击了PayPal上的在线支付者。
??WCD攻击就是利用的路径混淆，攻击者会构造具备下述两种属性的URL：
- URL必须被web服务器解释为对带有私有信息的不可缓存页面的请求，并且应该会触发成功的响应
- 这条URL必须被中间的web缓存解释为一个匹配有效缓存规则的静态对象的请求。
??接下来，攻击者会使用社会工程学攻击引诱受害者访问这条URL，这将导致不正确地缓存受害者的私人信息。然后攻击者将重复这条请求，获得缓存内容的访问权，下图展示了WCD攻击的过程。
这个过程可以描述为：
- 第一步：攻击者引诱受害者访问URL，请求account.php/nonexistent.jpg，这个图片实际在web服务器上不存在；
- 第二步：请求到达web服务器并被处理。服务器利用重写规则丢弃被请求对象中不存在的部分，返回一个成功响应account.php，这里面包含了受害者账户的私有详细信息。web缓存不知道发生在服务器上的URL重写，它把这条资源视为图片资源，存储了下来；
- 第三步：攻击者访问相同的URL，导致缓存命中，获取了受害者的缓存账户信息
2 WCD攻击测量方法
??知道了WCD攻击的原理，接下来就是如何去测量这种攻击。作者将测量方法分为3个阶段：
- 测量设置
- 攻击面检测
- WCD检测
这3步如下图所示。这里面，使用Chrome和Python的request库，以及selenium自动化工具完成。
2.1 第一阶段：测量设置
??WCD攻击只有在脆弱站点管理私有最终用户信息并允许对这些数据执行敏感操作时才有意义。因此提供身份验证机制的站点是该攻击的主要目标，也是这篇文章的主要测量目标。第一阶段就是识别这些站点，并在这些站点上创建账户。
2.1.1 域名发现
??首先去访问Alexa top域名，同时，利用一些开源智能工具进行子域发现来增加网站覆盖率，添加到种子池里面。
2.1.2 账号创建
??在每个站点上创建两个测试账户：一个用于受害者，另一个用于攻击者。利用唯一的虚拟值填充每个账户。然后手动检查每个受害者账户，发现应被视为私人信息的数据字段（例如姓名、电子邮件、地址、支付账户等）或用户创建的内容（例如评论、帖子等）
??对于这些字段，利用预定义的标记去填充，如果在后续的缓存响应中发现了这些标记，就代表成功检测到了WCD攻击。另一方面，攻击者的账户不需要数据输入。
2.1.3 Cookie收集
??如果成功登录到站点，爬虫程序会为受害者和攻击者的账户收集两套cookie，用于实验期间保持身份验证。此外，爬虫使用正则表达式和黑名单以避免访问页面上的注销链接。
2.2 第二阶段：攻击面检测
??这个阶段的主要目标是从种子池中的域名映射到一组页面（完整的url）中，意思就是说看这个域名下包含了哪些网站页面。这些页面会被用于测试是否存在WCD漏洞。
??许多的现代网站具有相似的结构，暴露出类似的攻击。在理想情况下，这些相似的页面应该被组合在一起，并只选择一个作为代表来检测WCD。这样做的目的是去冗余，减少分析量。
??具体分组方式是通过查询字符串参数名称或路径参数完成的，将这种方式分组的url转换为抽象表示，如下表所示。每一组只选择一个URL做代表进行分析。
2.3 第三阶段：WCD检测
??在这一阶段，对上一阶段中的每个URL发起WCD攻击，分析响应来确定是否达成了WCD攻击。
??WCD攻击和上述攻击场景图逻辑相同，这里对于每个URL，进行如下攻击步骤：
- 设计一个攻击URL，引用一个不存在的静态资源，这里选取的是在源站URL后面添加“/<random>.css”
- 从受害者账户向这个攻击URL发起请求，记录响应
- 从攻击者账户发出相同的请求，保存响应以供比较
- 最后，作为一个未经身份验证的用户，忽略保存在cookie jar中的攻击者身份标识符来重复攻击。以确定没有身份验证的攻击者是否也可以利用WCD漏洞
??如果攻击者账户请求的URL中存在受害者标记，则攻击者一定收到了受害者错误缓存的内容，因此目标URL包含可利用的WCD漏洞。
??然后，扫描攻击者的响应，发现被频繁用作web应用安全机制的一部分秘密令牌，以及任何其他应用验证令牌。例如CSRF token、session identifier、API credential等
3 WCD测量分析
3.1 WCD漏洞在流行网站中的存在情况
??在这次测量中，选取了Alexa Top 5K的站点，使用OAuth认证过滤出来295个最终网站，在这些网站中发现了16个网站包含WCD漏洞
??下图表示了Alexa Top 5K的站点分布情况，WCD漏洞情况和爬取站点的数量成正比。也就是说，WCD漏洞的发生率与网站的流行程度并不是很相关
3.2 WCD漏洞是否会暴露以及会暴露何种PII
??14/16个站点暴露出PII（personally identifiable information，个人验证信息），包含姓名、用户名、电子邮件、电话号码等。还有一些包含财务和健康信息，例如账户余额、购物历史、体重等。这些信息是作为高效鱼叉式钓鱼攻击的基础。
3.3 WCD漏洞是否可以击败针对web应用程序攻击的防御
??6/16个站点泄露了有效的CSRF令牌，这可能允许攻击者在部署了CSRF防御的情况下进行CSRF攻击
??6/16个站点泄露了内联Javascript中的会话标识符或用户特定的API令牌。
3.4 WCD漏洞是否会被未认证用户利用
??在第三阶段的最后一步提到，用为认证的用户去访问。查看未认证用户是否可以利用WCD漏洞。经过验证发现，所有漏洞都可以被未认证用户利用。这就意味着，WCD作为一类漏洞，往往不需要攻击者进行身份验证，降低了攻击门槛。
4 路径混淆变种
??除了检测WCD漏洞外，这篇论文还对路径混淆进行了变种，利用各种字符构造URL进行攻击，如下
1.换行符\n，编码%0A
2.分号;，编码%03B
3.井号#，编码%023
4.问号?，编码%03F
源站服务器倾向于忽略这些字符后面的内容，缓存服务器则可能仍然以文件拓展名做缓存决策。
??经实验，有如下结论：
- 累计发现25个受WCD攻击影响的站点
- 原始路劲混淆方法发现14个受WCD攻击影响的站点
- 路劲混淆变型方法发现23个受WCD攻击影响的站点
- 本文提出的路径混淆变型增加了攻击成功率
- 一些变型方法增加了 web 服务器返回 200 OK 响应码的概率，因而增加了 返回敏感信息的可能性
5 Empirical Experiments
??最后，这篇论文做了一个实际场景下的实验，演示不同缓存设置对WCD的影响
- 缓存地点因素：受害者选取在美国波士顿，攻击者在意大利特伦托，19个站点攻击成功，6个
- 缓存时间因素：对19个站点分别在1小时、6小时、24小时候试试攻击，分别有16、10、9个站点被成功攻击
地理位置和实施攻击的时间都会显著影响攻击的成功率。
??另外，几乎所有CDN厂商都提供“忽略Cache Control”头部字段的选项，并且普遍依赖文件扩展名做缓存决策。
6 总结
??总结下来，这篇论文可得出几个基本结论：
- 正确配置 Web 缓存并非易事，基于文件扩展名做缓存决策容易出现安全问题，出CDN 并非即插即用解决方案，需要考虑系统性安全问题
- WCD 是一个“系统安全”问题，安全组件和安全组件组成的系统也可能是不安全的，必须考虑不同技术之间的复杂交互
- 路径混淆变种是防不胜防的，因此难以完全确定某个站点是否受该攻击的影响，本文的结果只是一个下限
