【XSS技巧拓展】————6、CSP简介
摘要
Content Security Policy是一种web平台的安全机制，是为了减少xss漏洞而出现，这应该是现代web应用中顶级的安全漏洞。在本文中，我们仔细观察和考虑CSP的实际好处，也确定下现实世界中出现的可以导致94.72%的所有不同策略重大缺陷。
我们对互联网超过10亿个主机名大约1000亿的搜索引擎库，1680867台主机的CSP部署方式，26011种独特的CSP策略做了研究，这里我们介绍CSP规范的安全相关，并提供对其威胁模型的深入分析，重点关注对于XSS的保护，这里我们确定三种常见的CSP绕过方式，并解释它们是如何颠覆策略的安全性的。
之后呢，我们转而对部署在互联网上的策略分析，来了解他们的安全程度，我们发现，加载脚本最常列入白名单的有15个域，其中有14个不安全的站点，因此有75.81%的策略因为使用了了脚本白名单，允许了攻击者绕过了CSP。总而言之，我们发现尝试限制脚本执行的策略中有94.68%是无效的，并且99.34%具有CSP的主机制定的CSP策略对xss防御没有任何帮助。
最后，我们提出了“strict-dynamic”的关键字，这是规范的一个附加，它有助于基于加密随机数创建策略，而不依赖域白名单。我们讨论我们在复杂应用成语中部署一个这样基于nonce策略的经验，来为程序要提供指导来改进策略。
1、介绍
XSS-跨站脚本攻击，将攻击者控制的脚本注入到Web代码的上下文来控制脚本，可以说是最臭名昭著的Web漏洞之一。自从2000年第一正式提出了XSS以来，经过很多代人的研究、预防、环节，XSS仍然是网络最流行的安全问题之一，随着网络的发展，新的变化也被不断的被发现。
至今为止，CSP的仍然是最有希望的针对XSS对策。CSP是一个声明性的策略机制，允许Web开发者定义哪些客户端资源可以由浏览器加载和执行。通过禁止内敛脚本并仅允许可信域作为外部脚本的源，通过这种方式限制站点执行恶意客户端的代码。因此，即使攻击这发现了xss漏洞，CSP也可以保护应用程序的安全，攻击者不能在不控制可信主机的情况下加载恶意代码。
在这篇文章中，我们介绍第一次深入分析CSP在整个网络部署的结果，为了研究这一点，我们首先需要调查CSP的保护能力，通过分析威胁模型，分析可能的漏洞和可以使攻击这绕过保护的攻击方式。
我们遵循从google搜索引擎提取的真实世界CSP策略的大规模研究。我们发现目前至少有168000个网络主机部署了CSP策略。在对数据集进行归一化和重复数据处理后，我们确定了26011个唯一的CSP策略，其中94.72%都是可以被忽略的。攻击这可以使用各种方式破坏CSP保护的站点，尽管部署CSP方面花费了相当大的努力。现在的策略中90.63%可以包含通过允许执行内敛脚本或从任意外部主机加载脚本。而只有9.37%的策略具有更严格的配置，甚至防范着潜在的XSS。但是，我们发现，只有51%的这类策略仍然可以绕过，因为在script-src中存在微妙的策略配置错误或不安全的站点。
基于我们的研究结果，我们认为，为复杂的web端应用维护安全白名单在实践中是不可行的；因此，我们建议改变CSP的使用方式。我们建议通过指定脚本可以执行的url白名单来指定信任的应该被替换为基于nonce和散列值的方法，这已经被CSP规范定义并且在主流的浏览器实现中可用。
在基于nonce的策略中，web应用程序定义了在CSP中传递单一、不可猜测的token（nonce），以及一些合理的html属性，而不是把主机和域白名单用于脚本执行。用户代理仅允许执行那些nonce与策略中指定值匹配的脚本。可以将html注入到页面内的攻击者不知道临时值，因此无法执行恶意脚本。为了简化这种基于nonce的方式，我们提出了一个新的CSP源表达式关于script，我们称它为strict-dynamic。使用这个，动态生成的脚本隐式地从穿件他们的可信脚本集成值。这样，已经执行的合法脚本可以轻松地将新脚本添加到DOM，而不需要大量的代码修改。但是如果攻击者找到了xss漏洞，但是不知道正确的nonce，他们的脚本将会被阻止。
为了证明这种方法的可行性，我们提出了一个真实世界的案例研究。在一个比较主流的cms中使用基于nonce的策略。
我们的总结如下：
- 我们提出了CSP安全模型的第一深入分析结果，分析对标准中对于web漏洞的保护。我们识别常见的策略配置错误，并提供3类CSP的绕过方式，可以禁用策略的保护能力
- 我们通过google搜索引擎中提取策略，对现实世界的CSP部署的好处进行了大规模的研究。基于一个大约1060亿页的资料库，其中39亿是收到了CSP保护的，我们分析除了26011个独特的策略。我们发现，由于策略配置的错误和白名单的不安全，这些策略至少有94.71%对xss缓解没有帮助。
- 基于我们的研究结果，我们建议改变CSP在实际中的部署方式，不适用白名单，我们主张基于nonce的方式。为了进一步实现这种方法，我们提出了strict-dynamic，这是当前在chrome浏览器中实现的CSP3特性之一。我们讨论这种方法的好处，并提出了在主流cms中部署基于nonce和strict-dynamic策略的案例研究
在本文中，第二节中我们深入分析CSP，包括2.1中的技术基础，2.2和2.3讲了CSP设计策略时的常见漏洞。随后第3节中我们介绍了我们实际研究的结果，为了能够描述清楚问题，3.1中首先概述问题，3.2介绍我们的数据集，3.3中解释我们的研究方法，最后在3.4中给出结果和分析。基于这次研究，我们提出了改进CSP的方法，最后我们在第5节中介绍相关的东西，在第6节总结。
2.CSP
2.1 概述
CSP是一种声明机制的策略，它允许Web作者在站内指定许多安全限制，由浏览器执行。
CSP使开发人员在开发时可以以各种方式锁定他的站，减少XSS的风险和危害，降低站内各类脚本的执行权限。
CSP从建立开始一直快速发展，现在正在进行规范的是CSP3，但该标准在不同浏览器都是不同程度的试行，比如Chromium中具有完整的CSP2支持，并实现了CSP3中的大部分草案，但仍然落后于实验的标准，而在Firefox和基于Webkit的浏览器刚刚完成了完整的CSP2支持。这里我们不关注关于各个标准之间的修订，只是提供一个关于版本的概述。
CSP策略一般通过HTTP响应头中或在元素中传递。CSP的功能可以分为3类。
限制资源加载
CSP最广为人知和常用的的方面是限制浏览器只加载开发人员允许的子资源，称之为源列表。常用的执行包括script-src, style-src, catcall, default-src, 作为特殊情况，script-src和style-src指令还有额外的配置选项，这些允许script和css有更精细的控制方式。
基于url的控制
某些类型的攻击不能通过仅管理子资源来防止，但仍然需要一个可以与之交互的可信来源。一个比较常见的例子是frame-ancestors指令，它定义了框架资源的起源，以防止点击劫持。类似的，base-url和form-action定义了
其他限制
这里包括blocks-all-mixed-content和upgrade-insecurerequests关键字，可以防止混合内容错误和改进了对于https的支持，plugin-types限制了允许的插件格式，sandbox反应了一些HTML5沙箱框架的一些安全功能
为了能让整个Web站和CSP兼容，对XSS的防御有帮助，Web的开发者通常需要重构正常逻辑生成的html标记，框架以及模板化整个站。特别是涉及到内联脚本、eval和等效的结构、内联时间处理和javascript: URL的使用必须避免和重构为对CSP友好的结构。
除了默认的强制执行策略限制方式之外，还可以在Reprot-Only模式配置CSP，其中记录不合理的配置，但不会强制执行。在这两种情况下，report-uri指令都可以用作发送不合理配置报告，已通知站开发者站不合理的标记。
2.1.1 源列表
CSP源列表（也可以叫做白名单）是CSP的核心部分，并且是指定信任关系的和新方式。例如：
应用程序仅允许信任的托管域可以加载脚本，也允许来自cdn.example.org\third-party.org的字体或者图像，并且需要通过https加载，同时有不对其他资源施加任何限制。
对于任何指令，白名单可以由主机名（example.org, example.com）组成，可能包括*通配符以拓展对所有子域（*.example.com）的信任、schema(https:/http:)、和特殊的关键字’self’（表示当前文档的来源）还有’none’（强制执行空源，也就是说精致加载任何资源）
从CSP2开始，开发者还可以选择在白名单中制定路径（example.org/resources/js/）.有趣的是，不能依赖基于路径的限制来限制可以加载资源的位置，这个问题稍后在讨论。
2.1.2脚本执行的限制
由于脚本在现在Web应用程序中的重要性，script-src提供了几个关键字，以允许对脚本的执行提供更精细的控制：
1、unsafe-inline
允许执行内联的