论文笔记 | A Tale of Two Headers: A Formal Analysis ofInconsistent Click-Jacking Protection on the Web

我的考试考完了，USENIX 2020的都出来了，要赶紧读起来。

一作是这个博士，我觉得有点帅呀。他是做网络安全的

二作多读了硕士，应该大我两岁。也好强，今年一作发了NDSS，二作发了USENIX，一作AsiaCCS。方向的话， client-side Web security。

五作 Ben Stock 大佬本佬了，我得加油。也是web security的！！！

Background

2.1 Framing-based Attacks

攻击的关键是攻击者可以欺骗受害者点击其他的web应用。一个著名的案例就是like-jacking攻击。

2.2 X-Frame-Options

X-Frame-Options (XFO) 头部。该头部允许来自哪些源的资源可以frame它。举个例子，Firefox和IE支持三种不同的XFO头：SAMEORIGIN运行frame相同的源的页面，ALLOW-FROM头选择性的允许frame一个单一源的页面，而DENY则完全不允许frame。

作者注意到：“并非所有浏览器都以完全相同的方式实现X-Frame-Options，这可能会导致意外结果”，有意识ALLOW-FROM。

作者在本篇论文中确实发现X-Frame-Options是不一致的。

Content Security Policy

由于XFO的不足之处，作者将阻止攻击的功能合并到了内容安全策略中。虽然CSP最初的目的是为了减轻注入攻击，但CSP现在也提供了framing control和TLS enforcement的支持。

CSP是通过强制frame-ancestors来进行frame控制的。该方法有明显的优势：

• frame-ancestors指令基于顶级浏览上下文和框架页面之间的整个嵌套框架链（ances-tors）执行原点检查框架，这通过排除双重框架来提供最强的安全保证。
• CPS语法更完整，操作灵活，规则严格

Formal Framework

这是本篇论文核心的部分

3.1 策略语义

因为CSP比XFO更好表达，因此在这里作者在CoreCSP的基础上为CSP定义了一组语义。

下面是CoreCSP的语法

举个例子，对于frame-ancestors *.foo.com https://**，受保护的页面使用了HTTP的语法，那么该政策的语义由指令值{(http,∗.foo.com),(https,∗)}形式化。

3.2 形式定义

作者选择CoreCSP的原因是指令值可以使用$⊑$来表示关系，且很容易。

Definition 1 (Consistent Policy)

对一致性的描述：

例子1：

如果网站设置了 XFO标签：

那么它是不一致的，因为Chrome使用者是被完全不受保护的。网站也要设置CSP：

下面，作者举了个例子想说明，并不是所有的不一致性都有相同的危险。

例子2：

有一个CSP策略，
对于不适用CSP的浏览器，这是不一致的，因此需要添加上XFO

虽然这仍然是不一致的，但是它对安全的约束更加严格，也更加直观。
通过对这个事例，作者发现:旧版的浏览器在如何实施策略方面都达成了一致，现代浏览器也共享相同的策略解释，但是旧版浏览器可能比现代浏览器更加保守。

Definition 2(Security-Oriented Policy)

Policy Semantics

传统浏览器和现代浏览器都为策略提供了相同的语义，但给定了策略解释 传统浏览器可能比现代浏览器更宽松。

Definition 3(Compatibility-Oriented Policy).

这条是针对那些关心旧浏览器兼容性的的web网站开发者。

例子3：

例子2是面向兼容性的策略，因为该策略并没有对旧浏览器有任何限制，不过会牺牲对就浏览器的保护

总的来说，Security-oriented策略可以为旧浏览器提供适当级别的保护，但可能会带来兼容性问题。面向兼容性的策略可能会牺牲对旧浏览器的保护，但会向后兼容它们，因此可
能会吸引Web开发人员。注意，策略是一致的，当且仅当它是面向安全性和面向兼容性的。

不一致策略是难以描述的：
- 两个旧浏览器对策略的解释是不一致的
- 两个新浏览器对策略的解释是不一致的
- 以上这些都不是真的，然而，传统浏览器和现代浏览器对同一政策给出了两种无可比拟的解释。

Policy Analyzer

我们根据理论设计并实现了FRAMECHECK，这是一种基于我们的策略的自动化分析器。通过提供URL进行分析，FRAMECHECK可以生成有关其点击劫持保护状态的安全报告。

4.1 FRAMECHECK 描述

作者的工具有以下两个参数：

1. ${UA}_b$ 用户代理字段
2. 语义，可以将HTTP翻译成CoreCSP值。作者通过一组详尽的测试用例逆向工程它的语义。

数据集：

给定一个页面w，FRAMECHECK首先使用浏览器访问w，发送相关的user-agent 字符串。

Test Cases 测试样例

总共，作者总共开发了40多个测试用例，以在浏览器集中重建未指定的XFO标头的语义。

ALLOW-FROM支持

虽然大家都知道Chrome不支持“ALLOW-FROM”指令，但实际上只有3 / 10的浏览器支持XFO指令:Edge、firefox6和internet Explorer。

Multiple Headers支持

当同一网页发送多个XFO标头时，大多数经过测试的浏览器会同时强制执行所有标头（ 7/10）。Edge，Internet Explorer和Opera Mini仅强制使用第一个标头，而丢弃其他标头，这可能导致不一致。

Parsing of Header Value

RFC 7230中的HTTP协议规范要求必须可以用单个标头替换具有相同名称的多个标头，该标头包含用逗号分隔的标头值列表。如下例：

大部分是会拒绝Frame的，但除了Edge, Internet Explorer 和 Opera Mini。

Double Framing Protection

最终，作者观察到大多数浏览器都实施XFO了，它可以抵御双重Frame攻击。 这表明，自从最初的XFO规范以来，当所有浏览器都用于仅基于顶级浏览上下文执行Frame检查时。 但是，仍然有3种浏览器容易受到双重框架攻击：Edge，Internet Explorer和UC Browser。

Summary

Analysis in the wild

在本节中，作者使用Policy Analyzer在野外进行的大规模分析。 分析表明，许多流行的网站都对点击劫持实施了不一致的保护，并揭示了此潜在安全问题的根本原因。

Data Collection

作者首先分析了10,000个站点，以及这些站点页面的节点，每个最多500个。之后，作者使用curl，针对不同的User Agent输出返回头。

在数据收集过程的最后，作者总共访问了989,875个url。其中，5835个站点中有369,606个url(37%)带有针对framing control的XFO或CSP头文件。作者进行数据集清理和重复数据删除后，共剩下17613个framing control策略。表4显示了不同策略中采用的不同安全机制。

Inconsistent Policies

总的来说，作者从1,779个来源中确定了1,800个策略，它们针对点击劫持提供了不一致的保护。

表5提供了详细的分析:

• 当XFO和CSP一起使用时，相对大多数的不一致性(45%)发生，这表明为相同的目的使用两个不同的机制是潜在的危险。
• 不一致的策略中有84％使用了CSP。

Analysis of Inconsistent Policies

为了更深入地了解不一致的策略，作者执行了进一步的分类，作者确定了590个面向安全的策略（占33％）和795个面向兼容性的策略（占44％），而 其他415个不一致的策略（占23％）不属于这两个类别中的任何一个，因此是过度不一致的（Unduly Inconsistent）。

Security-Oriented Policies 面向安全的政策

由于XFO的表现力不如CSP，Web安全人员可能被要求提供比CSP更具限制性的XFO标头。举个例子，对于https://www.icoud.com，XFO是SAMEORINGIN，而CSP对每个icoud.com和apple.com的子域名设置了白名单。

作者进一步将590个面向安全的策略分为两类。

• 无效的政策，与XFO相比，CSP过于宽松。仅有2%
• 细粒度的CSP提供了更有效的政策，99例（17%）

作者认为这种差异是危险的，因为这违反了最小特权原则。

Compatibiility-Oriented Policies 面向兼容性的政策

面向兼容性的策略是向旧浏览器可访问Web应用程序的妥协，这种情况下，会牺牲旧浏览器的安全性。举个例子，对于https://www.spotify.com，CSP策略的白名单是spotify.com和spotify.net的子域名，但是XFO并没有支持如此表达的白名单。

回想一下，作者的数据集包含795个面向兼容性的策略。 作者发现有758例（95%）不提供任XFO保护， 这表明大多数Web开发人员实际上并不关心为旧版浏览器的用户提供安全性，或者只是完全不知道此问题的存在。

Unduly Inconsistent Policies 过度不一致的策略

最后，作者将重点关注415个既不是面向安全性也不是面向兼容性的不一致策略。这些策略很难证明是安全的。
- 至少两个浏览器对315个策略有不同的解释(76%)
- 289个策略被至少两种浏览器解释不同(69%)
- 所有旧版浏览器和所有现代浏览器都对29种策略进行了相同的解释，但是这两种解释是无法比拟的（7％）

表6提供了导致政策不一致（主要是部分重叠）的主要实践的细分。作者观察到，大多数不适当的不一致策略中都存在ALLOW-FROM指令，这表明在这些情况下XFO没有与CSP正确耦合。

Perspective

在这里，作者通过计算对至少一个浏览器不提供任何级别保护的策略的数量来总结发现对安全性的影响。表7显示了这两种情况下策略的存在和分配情况。

实验表明，使用现代浏览器的用户比使用传统浏览器的用户享受到更高程度的保护。

The Role of Browsers

由于之前的浏览器包含了不支持CSP的浏览器，为了减少此不一致而导致的偏差，作者删除了这两个浏览器并做了相似的实验，不一致政策的总数将从1800个减少到289个，作者人文这是一个重大改进。

Recommendations and Countermeasures

for Web Developers

1. XFO和CSP都必须用于当前Web上的有效框架控制
2. Web开发人员应确保每个网页最多发送一个XFOheader，因为在存在多个XFO标头的情况下，浏览器的解释可能不一致。

for Browser Vendors

1. 现在不是放弃对XFO的支持的恰当时机
2. 浏览器应明确警告Web开发人员有关使用CSP实现XFO相同效果的可能性，这是很直接，因为CSP比XFO更具表达力。

Retrofitting Security

作者开发了一种服务器端代理，旨在强制构架控制策略保持一致，即，确保所有浏览器都实施相同级别的保护 https://github.com/cispa/framing-control-proxy