安全

Web 应用程序的安全涉及到很多方面。针对常见的漏洞和攻击，比如跨站脚本攻击，Angular 提供了一些内置的保护措施。本章将讨论这些内置保护措施，但不会涉及应用级安全，比如用户认证（这个用户是谁？）和授权(这个用户能做什么？)。

要了解更多攻防信息，参见开放式 Web 应用程序安全项目(OWASP)。

你可以运行在线例子 / 下载范例，在 Stackblitz 中试用并下载本页的代码。

举报漏洞

给我们（security@angular.io）发邮件，报告 Angular 本身的漏洞。

要了解关于“谷歌如何处理安全问题”的更多信息，参见谷歌的安全哲学。

最佳实践

• 及时把 Angular 包更新到最新版本。 我们会频繁的更新 Angular 库，这些更新可能会修复之前版本中发现的安全漏洞。查看 Angular 的更新记录，了解与安全有关的更新。
• 不要修改你的 Angular 副本。 私有的、定制版的 Angular 往往跟不上最新版本，这可能导致你忽略重要的安全修复与增强。反之，应该在社区共享你对 Angular 所做的改进并创建 Pull Request。
• 避免使用本文档中带“安全风险”标记的 Angular API。 要了解更多信息，请参阅本章的信任那些安全的值部分。

防范跨站脚本(XSS)攻击

跨站脚本(XSS)允许攻击者将恶意代码注入到页面中。这些代码可以偷取用户数据 （特别是它们的登录数据），还可以冒充用户执行操作。它是 Web 上最常见的攻击方式之一。

为了防范 XSS 攻击，你必须阻止恶意代码进入 DOM。比如，如果某个攻击者能骗你把 <script> 标签插入到 DOM，就可以在你的网站上运行任何代码。 除了 <script>，攻击者还可以使用很多 DOM 元素和属性来执行代码，比如 <img onerror="...">、<a href="javascript:...">。 如果攻击者所控制的数据混进了 DOM，就会导致安全漏洞。

Angular 的“跨站脚本安全模型”

为了系统性的防范 XSS 问题，Angular 默认把所有值都当做不可信任的。 当值从模板中以属性（Property）、DOM 元素属性（Attribte)、CSS 类绑定或插值表达式等途径插入到 DOM 中的时候， Angular 将对这些值进行无害化处理（Sanitize），对不可信的值进行编码。

Angular 的模板同样是可执行的：模板中的 HTML、Attribute 和绑定表达式（还没有绑定到值的时候）会被当做可信任的。 这意味着应用必须防止把可能被攻击者控制的值直接编入模板的源码中。永远不要根据用户的输入和原始模板动态生成模板源码！ 使用离线模板编译器是防范这类“模板注入”漏洞的有效途径。

无害化处理与安全环境

无害化处理会审查不可信的值，并将它们转换成可以安全插入到 DOM 的形式。多数情况下，这些值并不会在处理过程中发生任何变化。 无害化处理的方式取决于所在的环境：一个在 CSS 里面无害的值，可能在 URL 里很危险。

Angular 定义了四个安全环境 - HTML，样式，URL，和资源 URL：

• HTML：值需要被解释为 HTML 时使用，比如当绑定到 innerHTML时。
• 样式：值需要作为 CSS 绑定到 style 属性时使用。
• URL：值需要被用作 URL 属性时使用，比如 <a href>。
• 资源 URL：值需要被当做代码而加载并执行时使用，比如 <script src> 中的 URL。

Angular 会对前三项中种不可信的值进行无害化处理。但 Angular 无法对第四种资源 URL 进行无害化，因为它们可能包含任何代码。在开发模式下， 如果 Angular 在进行无害化处理时需要被迫改变一个值，它就会在控制台上输出一个警告。

无害化示例

下面的例子绑定了 htmlSnippet 的值，一次把它放进插值表达式里，另一次把它绑定到元素的 innerHTML 属性上。

src/app/inner-html-binding.component.html

content_copy<h3>Binding innerHTML</h3>
<p>Bound value:</p>
<p class="e2e-inner-html-interpolated">{{htmlSnippet}}</p>
<p>Result of binding to innerHTML:</p>
<p class="e2e-inner-html-bound" [innerHTML]="htmlSnippet"></p>

插值表达式的内容总会被编码 - 其中的 HTML 不会被解释，所以浏览器会在元素的文本内容中显示尖括号。

如果希望这段 HTML 被正常解释，就必须绑定到一个 HTML 属性上，比如 innerHTML。但是如果把一个可能被攻击者控制的值绑定到 innerHTML就会导致 XSS 漏洞。 比如，包含在 <script> 标签的代码就会被执行：

src/app/inner-html-binding.component.ts (class)

content_copyexport class InnerHtmlBindingComponent {
  // For example, a user/attacker-controlled value from a URL.
  htmlSnippet = 'Template <script>alert("0wned")</script> <b>Syntax</b>';
}

Angular 认为这些值是不安全的，并自动进行无害化处理。它会移除 <script> 标签，但保留安全的内容，比如该片段中的文本内容或 <b> 元素。

避免直接使用 DOM API

The built-in browser DOM APIs don't automatically protect you from security vulnerabilities. For example, document, the node available through ElementRef, and many third-party APIs contain unsafe methods. In the same way, if you interact with other libraries that manipulate the DOM, you likely won't have the same automatic sanitization as with Angular interpolations. Avoid directly interacting with the DOM and instead use Angular templates where possible.

浏览器内置的 DOM API 不会自动针对安全漏洞进行防护。比如，document（它可以通过 ElementRef 访问）以及其它第三方 API 都可能包含不安全的方法。 要避免直接与 DOM 交互，只要可能，就尽量使用 Angular 模板。

内容安全策略

内容安全策略(CSP)是用来防范 XSS 的纵深防御技术。 要打开 CSP，请配置你的 Web 服务器，让它返回合适的 HTTP 头 Content_Security_Policy。 要了解关于内容安全策略的更多信息，请参阅 HTML5Rocks 上的内容安全策略简介

使用离线模板编译器

离线模板编译器阻止了一整套被称为“模板注入”的漏洞，并能显著增强应用程序的性能。尽量在产品发布时使用离线模板编译器， 而不要动态生成模板（比如在代码中拼接字符串生成模板）。由于 Angular 会信任模板本身的代码，所以，动态生成的模板 —— 特别是包含用户数据的模板 —— 会绕过 Angular 自带的保护机制。 要了解如何用安全的方式动态创建表单，请参见动态表单一章。

服务器端 XSS 保护

服务器端构造的 HTML 很容易受到注入攻击。当需要在服务器端生成 HTML 时（比如 Angular 应用的初始页面）， 务必使用一个能够自动进行无害化处理以防范 XSS 漏洞的后端模板语言。不要在服务器端使用模板语言生成 Angular 模板， 这样会带来很高的“模板注入”风险。

信任安全值

有时候，应用程序确实需要包含可执行的代码，比如使用 URL 显示 <iframe>，或者构造出有潜在危险的 URL。 为了防止在这种情况下被自动无害化，你可以告诉 Angular：我已经审查了这个值，检查了它是怎么生成的，并确信它总是安全的。 但是千万要小心！如果你信任了一个可能是恶意的值，就会在应用中引入一个安全漏洞。如果你有疑问，请找一个安全专家复查下。

注入 DomSanitizer 服务，然后调用下面的方法之一，你就可以把一个值标记为可信任的。

• bypassSecurityTrustHtml
• bypassSecurityTrustScript
• bypassSecurityTrustStyle
• bypassSecurityTrustUrl
• bypassSecurityTrustResourceUrl

记住，一个值是否安全取决于它所在的环境，所以你要为这个值按预定的用法选择正确的环境。假设下面的模板需要把 javascript.alert(...) 方法绑定到 URL。

src/app/bypass-security.component.html (URL)

content_copy<h4>An untrusted URL:</h4>
<p><a class="e2e-dangerous-url" [href]="dangerousUrl">Click me</a></p>
<h4>A trusted URL:</h4>
<p><a class="e2e-trusted-url" [href]="trustedUrl">Click me</a></p>

通常，Angular 会自动无害化这个 URL 并禁止危险的代码。为了防止这种行为，可以调用 bypassSecurityTrustUrl 把这个 URL 值标记为一个可信任的 URL：

src/app/bypass-security.component.ts (trust-url)

content_copyconstructor(private sanitizer: DomSanitizer) {
  // javascript: URLs are dangerous if attacker controlled.
  // Angular sanitizes them in data binding, but you can
  // explicitly tell Angular to trust this value:
  this.dangerousUrl = 'javascript:alert("Hi there")';
  this.trustedUrl = sanitizer.bypassSecurityTrustUrl(this.dangerousUrl);

如果需要把用户输入转换为一个可信任的值，可以在控制器方法中处理。下面的模板允许用户输入一个 YouTube 视频的 ID， 然后把相应的视频加载到 <iframe> 中。<iframe src> 是一个“资源 URL”的安全环境，因为不可信的源码可能作为文件下载到本地，被毫无防备的用户执行。 所以要调用一个控制器方法来构造一个新的、可信任的视频 URL，然后把它绑定到 <iframe src>。

src/app/bypass-security.component.html (iframe)

content_copy<h4>Resource URL:</h4>
<p>Showing: {{dangerousVideoUrl}}</p>
<p>Trusted:</p>
<iframe class="e2e-iframe-trusted-src" width="640" height="390" [src]="videoUrl"></iframe>
<p>Untrusted:</p>
<iframe class="e2e-iframe-untrusted-src" width="640" height="390" [src]="dangerousVideoUrl"></iframe>

src/app/bypass-security.component.ts (trust-video-url)

content_copyupdateVideoUrl(id: string) {
  // Appending an ID to a YouTube URL is safe.
  // Always make sure to construct SafeValue objects as
  // close as possible to the input data so
  // that it's easier to check if the value is safe.
  this.dangerousVideoUrl = 'https://www.youtube.com/embed/' + id;
  this.videoUrl =
      this.sanitizer.bypassSecurityTrustResourceUrl(this.dangerousVideoUrl);
}

HTTP 级别的漏洞

Angular 内置了一些支持来防范两个常见的 HTTP 漏洞：跨站请求伪造（XSRF）和跨站脚本包含（XSSI）。 这两个漏洞主要在服务器端防范，但是 Angular 也自带了一些辅助特性，可以让客户端的集成变得更容易。

跨站请求伪造（XSRF）

在跨站请求伪造（XSRF 或 CSFR）中，攻击者欺骗用户，让他们访问一个假冒页面(例如 evil.com)， 该页面带有恶意代码，秘密的向你的应用程序服务器发送恶意请求(例如 example-bank.com)。

假设用户已经在 example-bank.com 登录。用户打开一个邮件，点击里面的链接，在新页面中打开 evil.com。

该 evil.com 页面立刻发送恶意请求到 example-bank.com。这个请求可能是从用户账户转账到攻击者的账户。 与该请求一起，浏览器自动发出 example-bank.com 的 cookie。

如果 example-bank.com 服务器缺乏 XSRF 保护，就无法辨识请求是从应用程序发来的合法请求还是从 evil.com 来的假请求。

为了防止这种情况，你必须确保每个用户的请求都是从你自己的应用中发出的，而不是从另一个网站发出的。 客户端和服务器必须合作来抵挡这种攻击。

常见的反 XSRF 技术是服务器随机生成一个用户认证令牌到 cookie 中。 客户端代码获取这个 cookie，并用它为接下来所有的请求添加自定义请求页头。 服务器比较收到的 cookie 值与请求页头的值，如果它们不匹配，便拒绝请求。

这个技术之所以有效，是因为所有浏览器都实现了同源策略。只有设置 cookie 的网站的代码可以访问该站的 cookie，并为该站的请求设置自定义页头。 这就是说，只有你的应用程序可以获取这个 cookie 令牌和设置自定义页头。evil.com 的恶意代码不能。

Angular 的 HttpClient 对这项技术的客户端部分提供了内置的支持要了解更多信息，参见 HttpClient 部分。

到开放式 Web 应用程序安全项目(OWASP)的这里 和这里学习更多关于跨站请求伪造（XSRF）的知识。 这个斯坦福大学论文有详尽的细节。

参见 Dave Smith 在AngularConnect 2016 关于 XSRF 的演讲。

跨站脚本包含(XSSI)

跨站脚本包含，也被称为 Json 漏洞，它可以允许一个攻击者的网站从 JSON API 读取数据。这种攻击发生在老的浏览器上， 它重写原生 JavaScript 对象的构造函数，然后使用 <script> 标签包含一个 API 的 URL。

只有在返回的 JSON 能像 JavaScript 一样可以被执行时，这种攻击才会生效。所以服务端会约定给所有 JSON 响应体加上前缀 ")]}',\n"，来把它们标记为不可执行的， 以防范这种攻击。

Angular 的 Http 库会识别这种约定，并在进一步解析之前，自动把字符串 ")]}',\n" 从所有响应中去掉。

要学习更多这方面的知识，请参见谷歌 Web 安全博客文章的 XSSI 小节。

审计 Angular 应用程序

Angular 应用应该遵循和常规 Web 应用一样的安全原则并按照这些原则进行审计。Angular 中某些应该在安全评审中被审计的 API（ 比如bypassSecurityTrust API）都在文档中被明确标记为安全性敏感的。

	安全