创新互联Angular教程：Angular安全

安全

本主题会讲述 Angular 为防范 Web 应用常见的安全漏洞和攻击（比如跨站脚本攻击）内置的保护措施，但不会涉及应用级安全，比如用户认证（这个用户是谁？）和授权(这个用户能做什么？)。

创新互联专业为企业提供赫山网站建设、赫山做网站、赫山网站设计、赫山网站制作等企业网站建设、网页设计与制作、赫山企业网站模板建站服务，十余年赫山做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

你可以运行现场演练 / 下载范例，在 Stackblitz 中试用并下载本页的代码。

举报漏洞

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

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

最佳实践

实践

详情

及时把 Angular 包更新到最新版本

我们会频繁的更新 Angular 库，这些更新可能会修复之前版本中发现的安全漏洞。查看 Angular 的更新记录，了解与安全有关的更新。

不要修改你的 Angular 副本

私有的、定制版的 Angular 往往跟不上最新版本，这可能导致你忽略重要的安全修复与增强。反之，应该在社区共享你对 Angular 所做的改进并创建 Pull Request。.

避免使用本文档中带“安全风险”标记的 Angular API

要了解更多信息，请参阅本章的信任安全值部分。

防范跨站脚本(XSS)攻击

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

为了防范 XSS 攻击，你必须阻止恶意代码进入 DOM。比如，如果某个攻击者能骗你把 ​ Syntax'; }

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

避免直接使用 DOM API

除非你强制使用可信类型（Trusted Types），否则浏览器内置的 DOM API 不会自动保护你免受安全漏洞的侵害。比如 ​document​、通过 ​ElementRef ​拿到的节点和很多第三方 API，都可能包含不安全的方法。如果你使用能操纵 DOM 的其它库，也同样无法借助像 Angular 插值那样的自动清理功能。所以，要避免直接和 DOM 打交道，而是尽可能使用 Angular 模板。

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

信任安全值

有时候，应用程序确实需要包含可执行的代码，比如使用 URL 显示 ​

Untrusted:

updateVideoUrl(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);
}

内容安全政策

内容安全策略（CSP）是防止 XSS 的深度防御技术。要启用 CSP，请将你的 Web 服务器配置为返回适当的 ​Content-Security-Policy​ HTTP 请求头。在 Google Developers 网站上的《网络基础知识》指南中了解有关内容安全政策的更多信息。

新版 Angular 所需的最小化策略是：

default-src 'self'; style-src 'self' 'unsafe-inline';

区段

详情
default-src 'self';

允许此页面加载所有来自同源的资源。

style-src 'self' 'unsafe-inline';

允许此页面加载来自同源的全局样式('self')，并允许组件加载它们的样式('unsafe-inline' - 参见 angular/angular#6361)。

Angular 本身只需要这些设置即可正常运行。但是，随着项目的增长，你可能需要将 CSP 设置扩展到超乎此最小值，以支持应用特有的一些其它特性。

强制执行可信类型

我们建议使用可信类型来帮助保护你的应用程序免受跨站脚本攻击。可信类型是一项 Web 平台功能，可通过实施更安全的编码实践来帮助你防范跨站脚本攻击。可信类型还可以帮助简化应用程序代码的审计。

可信类型可能尚未在你的应用程序目标的所有浏览器中可用。如果启用了可信类型的应用程序在不支持可信类型的浏览器中运行，应用程序的功能将被保留，并且你的应用程序将通过 Angular 的 DomSanitizer 防范 XSS。有关当前浏览器支持，请参阅  caniuse.com/trusted-types。

要为你的应用程序强制实施可信类型，你必须将应用程序的 Web 服务器配置为使用以下 Angular 策略之一发出 HTTP 请求头：

策略

详情
angular

此策略用于 Angular 内部经过安全审查的代码，并且当强制执行可信类型时，Angular 需要此策略才能正常运行。任何由 Angular 清理的内联模板值或内容都被此政策视为安全的。

angular#unsafe-bypass

此策略用于要使用 Angular 的 ​DomSanitizer ​的各个方法来绕过安全性的应用程序，比如 bypassSecurityTrustHtml。任何使用了这些方法的应用程序都必须启用此策略。

angular#unsafe-jit

JIT 编译器使用此策略。如果你的应用程序直接与 JIT 编译器交互或使用 ​platformBrowserDynamic ​在 JIT 模式下运行，则必须启用此策略。

你应该在以下位置为可信类型配置 HTTP 请求头：

  • 生产环境基础设施服务器
  • Angular CLI ( ​ng serve​ )，使用 ​angular.json​ 文件中的 ​headers ​属性，用于本地开发和端到端测试
  • Karma ( ​ng test​ )，使用 ​karma.config.js​ 文件中的 ​customHeaders ​属性，进行单元测试

以下是为可信类型和 Angular 配置的请求头示例：

Content-Security-Policy: trusted-types angular; require-trusted-types-for 'script';

以下是为可信类型和 Angular 应用程序专门配置的请求头示例，这些应用程序使用了 Angular ​DomSanitizer ​中那些可以绕过安全性的方法。

Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for 'script';

以下是使用 JIT，且专门为可信类型和 Angular 应用程序配置的请求头示例：

Content-Security-Policy: trusted-types angular angular#unsafe-jit; require-trusted-types-for 'script';

社区贡献

要了解关于如何对可信类型配置进行故障排除的更多信息，以下资源可能会有所帮助：

使用可信类型防范基于 DOM 的跨站脚本漏洞

使用 AOT 模板编译器

AOT 模板编译器可防止称为模板注入的一整类漏洞，并大大提高了应用程序性能。AOT 模板编译器是 Angular CLI 应用程序使用的默认编译器，你应该在所有生产部署中使用它。

AOT 编译器的替代方法是 JIT 编译器，它可以在运行时将模板编译为浏览器中的可执行模板代码。Angular 信任这些模板代码，因此动态生成模板并进行编译（尤其是包含用户数据的模板）可以规避 Angular 的内置保护，并且是一种安全性方面的反模式。

服务器端 XSS 保护

在服务器上构造的 HTML 容易受到注入攻击。将模板代码注入到 Angular 应用程序中与注入可执行代码是一样的：它使攻击者可以完全控制该应用程序。为避免这种情况，请使用一种模板语言来自动转义值以防止服务器上的 XSS 漏洞。不要在服务器端使用模板语言生成 Angular 模板；这样做会带来引入模板注入漏洞的高风险。

HTTP 级漏洞

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

跨站请求伪造

在跨站请求伪造（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 ​对这项技术的客户端部分提供了内置的支持。

跨站脚本包含(XSSI)

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