网站内容策略(Web对于网络安全有哪些改进？对于这个问题的最新解决方案)

　　网站内容策略(Web对于网络安全有哪些改进？对于这个问题的最新解决方案)

　　前言：HTML5出现后，网络安全受到更多关注。 Web 对网络安全性做了哪些改进？我们如何应对日益危险的在线欺诈和攻击？ 文章 下面讨论了 W3C 对这个问题的最新解决方案。如果以后有机会，我会现场分享针对 XSS、P3P、同源策略、CORS（跨域资源共享）和 CSP 的 HTML5 内容安全。

　　----------------华丽的分割线

　　注意：本文讨论的 API 尚未最终确定，请在自己的项目中谨慎使用。

　　万维网的安全策略植根于同源策略。例如，代码只能访问数据，不能访问权限。每个来源都与网络的其余部分隔离，为开发人员创建了一个安全的沙箱。这在理论上是完美的，但现在攻击者已经找到了破解系统的巧妙方法。

　　这是一种 XSS 跨站脚本攻击，使用虚假内容和欺骗点击绕过同源策略。这是一个大问题，如果攻击者成功注入代码，将会泄露大量用户数据。

　　现在我们引入了一种新的有效的安全防御策略来降低这种风险，即内容安全策略 (CSP)。

　　来源白名单

　　XSS 攻击的核心是利用浏览器无法区分脚本是由第三方注入还是实际上是应用程序的一部分。例如，Google +1 按钮会加载并执行代码，但我们不能依靠浏览器上的图像来判断代码是否真的来自。浏览器下载并执行页面请求中的任意代码，无论其来源如何。

　　

　　CSP 定义了 Content-Security-Policy HTTP 标头，以允许您创建受信任来源的白名单，以便浏览器仅执行和呈现来自这些来源的资源，而不是盲目地信任服务器提供的所有内容。即使攻击者能找到漏洞注入脚本，也不会执行，因为源不在白名单中。

　　以上面的 Google +1 按钮为例，因为我们相信提供有效的代码，就像我们自己一样，我们可以定义一个策略，允许浏览器只执行来自以下两个来源之一的脚本。

　　Content-Security-Policy:script-src 'self'

　　容易吗？ script-src 可以控制指定页面的脚本相关权限。这样浏览器只会从页面本身下载和执行脚本。

　　一旦我们定义了这个策略，浏览器会在检测到注入代码时抛出错误（注意是什么浏览器）。

　　内容安全政策适用于所有常用资源

　　虽然脚本资源是最明显的安全隐患，但CSP也提供了丰富的指令集，让页面可以控制各类资源的加载，比如以下几种：

　　content-src：限制连接类型（例如XHR、WebSockets和EventSource）

　　font-src：控制网页字体的来源。例如，您可以使用 font-src 来使用 Google 的网络字体。

　　frame-src：列出可以嵌入的帧的来源。例如 frame-src 只允许嵌入 YouTube 视频。 .

　　img-src：定义可加载图片的来源。

　　media-src：限制视频和音频来源。

　　object-src：限制 Flash 和其他插件的来源。

　　style-src：类似于 Script-src，但仅适用于 css 文件。

　　默认情况下，所有设置都打开，没有任何限制。您可以用分号分隔多个指令，但类似于 script-src ;script-src，第二个指令将被忽略。正确的拼写是 script-src。

　　例如，如果您的应用程序需要从内容交付网络（例如 CDN）加载所有资源，并且知道不需要框架或插件内容，您的策略可能如下所示：

　　Content-Security-Policy:default-src ;框架源“无”；对象源“无”

　　详情

　　我在示例中使用的 HTTP 标头是 Content-Security-Policy，但现代浏览器已经通过前缀提供支持：Firefox 使用 x-Content-Security-Policy，WebKit 使用 X-WebKit-CSP。未来会逐步过渡到统一标准。

　　可以按页面设置策略，这提供了很大的灵活性。因为您的网站可能有网页有 Google +1 按钮，而其他网页没有。

　　每个指令的源列表可以非常灵活，您可以指定一个模式（data:、https:），或者指定一个主机名范围（匹配任何源、任何模式和主机上的任何端口），或者指定一个完整的URI（:443，专门用于https协议、域名、端口443）。

　　您还可以在源列表中使用四个关键字：

　　"none"：你可能期望没有匹配项

　　“self”：与当前来源相同，但没有子域

　　“unsafe-inline”：允许内联 Javascript 和 CSS

　　“unsafe-eval”：允许文本到JS等机制的eval

　　请注意，这些 关键词 需要用引号引起来。

　　沙盒

　　这里还有一个值得讨论的指令：沙盒。与其他指令有些不一致，它主要控制在页面上执行的操作，而不是页面可以加载的资源。如果设置了此属性，则页面的行为类似于设置了沙盒属性的框架。这对页面有广泛的影响，例如阻止表单提交等。这有点超出本文的范围，但您可以在 HTML5 规范的“沙箱标志设置”部分找到更多信息。

　　有害的内联代码

　　CSP 基于源白名单，但并未解决 XSS 攻击的最大来源：内联脚本注入。如果攻击者可以注入收录有害代码的脚本标签（ ），则浏览器没有很好的机制来区分这个标签。 CSP 只能通过完全禁止内联脚本来解决这个问题。

　　此禁令不仅包括嵌入在脚本中的脚本标签，还包括内联事件处理程序和 javascriptscrpt: URL。您需要将脚本标记的内容放入外部文件中，并将 javascript: 和 javascript 替换为适当的 addEventListener。例如，您可以输入以下表格：

　　我很厉害吗？

　　改写如下：

　　我很厉害吗？

　　//惊人的.js

　　函数 doAmazingThings() {

　　alert('你太棒了！');

　　}

　　document.addEventListener('DOMContentReady', function () {

　　document.getElementById('amazing')

　　.addEventListener('click', doAmazingThings);

　　});

　　不管有没有CSP，上面的代码其实都有更多的优势。内联 JavaScript 完全混合了结构和行为，您不应该这样做。另外，外部资源更容易被浏览器缓存，更容易被开发者理解，也更容易编译和压缩。如果你使用行外代码，你会写出更好的代码。

　　内联样式需要以相同的方式处理，样式属性和样式标签都需要提取到外部样式表中。这可以防止各种神奇的数据泄露。

　　如果您必须具有内联脚本和样式，请为 script-src 或 style-src 属性设置“unsafe-inline”值。但是不要这样做，禁用内联脚本是 CSP 提供的最大的安全保障，而禁用内联样式可以让你的应用程序更加安全和健壮。这是一个权衡，但非常值得。

　　评估

　　即使攻击者无法直接注入脚本，他也可能会欺骗您的应用程序将插入的文本转换为可执行脚本并自行执行。 eval() 、 newFunction() 、 setTimeout([string], ...) 和 setInterval([string], ...) 都可以作为这种危险的向量。 CSP 针对这种风险的策略是完全阻止这些向量。

　　这对您构建应用的方式有一些影响：

　　通过内置的 JSON.parse 解析 JSON，而不依赖 eval。 IE8之后的浏览器都支持原生JSON操作，完全安全。

　　通过内联函数而不是字符串来重写您调用 setTimeout 和 setInterval 的方式。例如：

　　setTimeout("document.querySelector('a').style.display = 'none';", 10);

　　可以改写为：

　　setTimeout(function () { document.querySelector('a').style.display = 'none'; }, 10);

　　在运行时避免内联模板：许多模板库使用 new Function() 来加速模板生成。这对于动态程序非常有用，但对于恶意文本来说存在风险。

　　报告

　　CSP 对用户在服务器端阻止不受信任的资源非常有用，但对我们获取发送到服务器的各种通知非常有用，以便我们识别和修复任何恶意脚本注入。您可以通过 report-uri 指令指示浏览器将 JSON 格式的拦截报告发送到某个地址。

　　Content-Security-Policy: default-src 'self'; ...;报告-uri /my_amazing_csp_report_parser;

　　报告将如下所示：

　　{

　　“csp 报告”：{

　　"文档-uri": "",

　　“推荐人”：“”，

　　"blocked-uri": "",

　　"violated-directive": "script-src 'self'",

　　"original-policy": "script-src 'self' ; report-uri"

　　}

　　}

　　它收录有助于识别阻塞情况的信息，包括发生阻塞的页面（document-uri）、页面的引用者、违反页面政策的资源（blocked-uri）以及被违反的指令（violated-directive）和页面的所有内容安全策略（original-policy）。

　　实际用法

　　CSP 现在可在浏览器 Chrome 16+ 和 Firefox 4+ 上使用，预计在 IE10 上将获得有限的支持。 Safari 尚不支持它，但 WebKit nightly builds 已经可用，所以期待 Safari 在下一次迭代中支持它。

　　让我们看一些常见的用例：

　　实际案例 1：社交媒体小部件

　　Google +1 按钮包括来自的脚本和嵌入的 iframe。您的策略需要收录这些来源才能使用 Google +1 按钮。最简单的策略是script-src；帧源。您还需要确保 Google 提供的 JS 片段存储在外部 JS 文件中。

　　Facebook 的 Like 按钮有多种实现方式。我建议您坚持使用 iframe 版本，因为它与您网站的其他部分完全隔离。这需要使用 frame-src 指令。请注意，Facebook提供的iframe代码默认使用相对路径//，请将此代码修改为HTTP，不需要使用。

　　Twitter 的 Tweet 按钮依赖于 script 和 frame，两者均来自（Twitter 默认提供相对 URL，复制时请编辑代码指定 HTTPS）。

　　其他平台也有类似情况，可以类似解决。我建议将 default-src 设置为 none，然后查看控制台以检查您需要使用哪些资源来确保小部件正常工作。

　　使用多个小部件非常简单：只需组合所有策略指令，记住将相同指令的设置保持在一起。如果你想使用上面的三个小部件，策略应该是这样的：

　　脚本-src ;框架源

　　实际案例 2：防御

　　假设您访问一家银行网站，并希望确保只加载您需要的资源。在这种情况下，首先设置一个默认权限来阻止所有内容（default-src 'none'），然后从头开始构建策略。

　　比如银行网站需要从CDN中加载图片、样式和脚本，通过XHR连接拉取各种数据，也需要用到frame，但是frame都是来自非第三方的-party 本地页面。 网站 上没有 Flash、字体和其他内容。在这种情况下，我们可以发送的最严格的 CSP 标头是：

　　Content-Security-Policy: default-src 'none';脚本-src ;样式-src ; img-src ;连接源代码； frame-src '自我'

　　实际案例 3：仅 SSL

　　婚戒论坛管理员希望以安全的方式加载所有资源，但又不想真正编写太多代码；重写许多 3rd 方论坛内联脚本和样式代码超出了他的能力。因此，以下策略将非常有用：

　　Content-Security-Policy: default-src https:;脚本源 https: 'unsafe-inline'; style-src https: 'unsafe-inline'

　　虽然 default-src 指定 https，但脚本和样式不会自动继承。每个指令都将完全覆盖默认资源类型。

　　未来

　　W3C 的 Web 应用程序安全工作组正在研究内容安全策略规范的细节，1.版本 0 即将进入最终修订阶段，与本文描述的内容非常接近在 public-webappsec@ 邮件组讨论 1.1 版本的同时，浏览器供应商也在努力整合和改进 CSP 实施。

　　CSP 1.1 在画板上有一些有趣的部分，值得单独列出：

　　通过元标记添加策略：设置 CSP 的首选方法是 HTTP 标头，这非常有用，但通过标记或脚本设置它们更简单，但尚未最终确定。 WebKit已经实现了通过meta元素设置权限的功能，现在可以在Chrome下尝试如下设置：在文档头部添加。

　　您甚至可以在运行时通过脚本添加策略。

　　DOM API：如果CSP的下一次迭代增加了这个特性，可以通过Javascript查询页面当前的安全策略，并根据不同的情况进行调整。例如，在 eval() 可用的情况下，您的代码实现可能会略有不同。这对 JS 框架的作者非常有用；并且 API 规范目前非常不确定，您可以在草案规范的 Scripting Interfaces 部分找到最新的迭代。

　　新指令：许多新指令正在讨论中，包括：只有明确指定的脚本元素才能使用内联脚本； ：这将限制插件的类型； : 允许表单仅提交到特定来源。

　　如果您对这些未来功能的讨论感兴趣，可以阅读邮件列表存档或加入邮件列表。

　　本文翻译自：