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

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

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

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

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

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

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

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

　　源白名单

　　XSS 攻击的核心是利用浏览器无法区分脚本是由第三方注入的还是真的是您应用程序的一部分。例如，Google+1 按钮会加载并执行代码，但我们不能指望浏览器上的图像能够分辨代码是真的来自还是来自。浏览器下载并执行任意代码的页面请求，而不管其来源。

　　

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

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

　　内容安全策略：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）加载所有资源，并且您知道不需要任何框架或插件内容，那么您的策略可能如下所示：

　　内容安全策略：默认源代码；frame-src'none'; object-src'none'

　　细节

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

　　可以为每个不同的页面设置策略，这提供了很大的灵活性。因为您网站的某些页面可能有 Google +1 按钮，但有些没有。

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

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

　　“无”：您可能期望没有匹配项

　　“Self”：与当前来源相同，但不包括子域

　　“不安全内联”：允许内联 Javascript 和 CSS

　　“Unsafe-eval”：一种允许文本到 JS 的机制，例如 eval

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

　　沙盒

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

　　有害的内联代码

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

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

　　我很了不起吗？

　　改写成如下形式：

　　我很了不起吗？

　　// 惊人的.js

　　函数 doAmazingThings() {

　　alert('你太棒了！');

　　}

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

　　document.getElementById('惊人')

　　.addEventListener('click', doAmazingThings);

　　});

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

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

　　如果您必须有内联脚本和样式，您可以为 script-src 或 style-src 属性设置'unsafe-inline value'。但不要这样做。禁止内联脚本是 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 格式的拦截报告发送到某个地址。

　　内容安全策略：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）、页面的referrer、违反页面策略的资源（blocked-uri）、违规指令（violated-指令），以及页面所有权内容安全策略（原创策略）。

　　实际使用

　　CSP 现在可在 Chrome 16+ 和 Firefox 4+ 浏览器上使用，预计在 IE10 上将获得有限支持。Safari 目前不支持，但 WebKit 的 nightly build 版本已经可用，因此预计 Safari 会在后续迭代中提供支持。

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

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

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

　　有很多方法可以实现 Facebook 的 Like 按钮。我建议您坚持使用 iframe 版本，因为它可以与您网站的其余部分很好地隔离。这需要使用 frame-src 命令。请注意，默认情况下，Facebook提供的iframe代码使用的是相对路径//，请将此代码修改为，HTTP不是必需的，您可以不使用它。

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

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

　　使用多个小部件非常简单：只需合并所有策略指令，记住将同一指令的设置放在一起。如果你想使用上面的三个小部件，策略将如下所示：

　　脚本源代码；帧源

　　实际案例2：辩护

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

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

　　内容安全策略：default-src'none'; 脚本源代码；风格-src; img-src; 连接源代码；frame-src'self'

　　实际案例 3：仅使用 SSL

　　婚戒论坛管理员希望所有资源都以安全的方式加载，但又不想写太多代码；重写大量第三方论坛内嵌脚本和样式代码，超出了他的能力范围。因此，以下策略将非常有用：

　　内容安全策略：default-src https:; script-src https:'unsafe-inline'; style-src https:'unsafe-inline'

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

　　未来

　　W3C Web 应用程序安全工作组正在研究内容安全策略规范的细节。1.0 版本将进入最终修订阶段，与本文描述的内容非常接近。public-webappsec@邮件群正在讨论1.1版本，浏览器厂商也在努力巩固和完善CSP的实现。

　　CSP1.1在画板上有一些有趣的地方，值得单独列出：

　　通过meta标签添加策略：CSP的首选设置方式是HTTP头，非常好用，但是通过标签或者脚本来设置会更直接，但目前还没有最终确定。WebKit 已经实现了通过 meta 元素设置权限的功能，所以你现在可以在 Chrome 下尝试以下设置：在文档标题中添加。

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

　　DOM API：如果在CSP的下一次迭代中加入该功能，可以通过Javascript查询页面当前的安全策略，并根据不同情况进行调整。例如，在 eval() 是否可用的情况下，您的代码实现可能会略有不同。这对 JS 框架的作者非常有用；并且API规范目前非常不确定。您可以在规范草案的脚本接口章节中找到最新的迭代版本。

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

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

　　本文转载自：