450 lines
25 KiB
Plaintext
450 lines
25 KiB
Plaintext
block includes
|
||
include ../_util-fns
|
||
:marked
|
||
Web application security has many aspects. This chapter describes Angular's built in
|
||
protections against common web application vulnerabilities and attacks, such as Cross Site
|
||
Scripting Attacks. It does not cover application level security, such as authentication (_Who is
|
||
this user?_) or authorization (_What can this user do?_).
|
||
|
||
Web应用程序的安全涉及到很多方面。针对常见的漏洞和攻击，比如跨站脚本攻击，Angular提供了一些内建的保护措施。本章将讨论这些内建保护措施，但不会涉及应用级安全，比如用户认证（_这个用户是谁？_）和授权(_这个用户能做什么？_)。
|
||
|
||
The [Open Web Application Security Project (OWASP)](https://www.owasp.org/index.php/Category:OWASP_Guide_Project)
|
||
has further information on the attacks and mitigations described below.
|
||
|
||
[开放式Web应用程序安全项目(OWASP)](https://www.owasp.org/index.php/Category:OWASP_Guide_Project)有关于攻防的更多信息。
|
||
|
||
.l-main-section
|
||
:marked
|
||
# Table Of Contents
|
||
# 目录
|
||
|
||
* [Reporting Vulnerabilities](#report-issues)
|
||
|
||
* [举报漏洞](#report-issues)
|
||
|
||
* [Best Practices](#best-practices)
|
||
|
||
* [最佳实践](#best-practices)
|
||
|
||
* [Preventing Cross-Site Scripting (XSS)](#xss)
|
||
|
||
* [防范跨站脚本(XSS)攻击](#xss)
|
||
|
||
* [Trusting Safe Values](#bypass-security-apis)
|
||
|
||
* [信任安全值](#bypass-security-apis)
|
||
|
||
* [HTTP-level Vulnerabilities](#http)
|
||
|
||
* [HTTP级别的漏洞](#http)
|
||
|
||
* [Auditing Angular Applications](#code-review)
|
||
|
||
Try the <live-example></live-example> of the code shown in this chapter.
|
||
|
||
运行<live-example></live-example>来试用本章中的代码。
|
||
|
||
.l-main-section
|
||
h2#report-issues Reporting Vulnerabilities
|
||
|
||
h2#report-issues 举报漏洞
|
||
|
||
:marked
|
||
Email us at [security@angular.io](mailto:security@angular.io) to report vulnerabilities in
|
||
Angular itself.
|
||
|
||
给我们（[security@angular.io](mailto:security@angular.io)）发邮件，报告Angular本身的漏洞。
|
||
|
||
For further details on how Google handles security issues please refer to [Google's security
|
||
philosophy](https://www.google.com/about/appsecurity/).
|
||
|
||
请到[谷歌的安全哲学](https://www.google.com/about/appsecurity/)了解关于“谷歌如何处理安全问题”的更多信息。
|
||
|
||
.l-main-section
|
||
h2#best-practices Best Practices
|
||
|
||
h2#best-practices 最佳实践
|
||
|
||
:marked
|
||
* **Keep current with the latest Angular library releases.**
|
||
We regularly update our Angular libraries and these updates may fix security defects discovered in
|
||
previous version. Check the Angular [change
|
||
log](https://github.com/angular/angular/blob/master/CHANGELOG.md) for security-related updates.
|
||
|
||
* **及时把Angular包更新到最新版本。**
|
||
|
||
我们会频繁的更新Angular库，这些更新可能会修复之前版本中发现的安全漏洞。查看Angular的[更新记录](https://github.com/angular/angular/blob/master/CHANGELOG.md)，了解与安全有关的更新。
|
||
|
||
* **Don't modify your copy of Angular.**
|
||
Private, customized versions of Angular tend to fall behind the current version and may neglect
|
||
important security fixes and enhancements. Instead, share your Angular improvements with the
|
||
community and make a pull request.
|
||
|
||
* **不要修改你的Angular副本。**
|
||
|
||
私有的、定制版的Angular往往跟不上最新版本，这可能导致你忽略重要的安全修复与增强。反之，应该在社区共享你对Angular所做的改进并创建Pull Request。
|
||
|
||
* **Avoid Angular APIs marked in the documentation as “[_Security Risk_](#bypass-security-apis)”.**
|
||
|
||
* **避免使用本文档中带“[_安全风险_](#bypass-security-apis)”标记的Angular API。**
|
||
|
||
.l-main-section
|
||
h2#xss Preventing Cross-Site Scripting (XSS)
|
||
|
||
h2#xss 防范跨站脚本(XSS)攻击
|
||
|
||
:marked
|
||
[Cross-Site Scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) enables attackers
|
||
to inject malicious code into web pages. Such code can then, for example, steal user's data (in
|
||
particular their login data), or perform actions impersonating the user. This is one of the most
|
||
common attacks on the web.
|
||
|
||
[跨站脚本(XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting)允许攻击者将恶意代码注入到页面中。这些代码可以偷取用户数据
|
||
（特别是他们的登录数据），还可以冒充用户执行操作。它是Web上最常见的攻击方式之一。
|
||
|
||
To block XSS attacks, we must prevent malicious code from entering the DOM. For example, if an
|
||
attacker can trick us into inserting a `<script>` tag in the DOM, they can run arbitrary code on
|
||
our website. The attack is not limited to `<script>` tags - many elements and properties in the
|
||
DOM allow code execution, for example `<img onerror="...">`, `<a href="javascript:...">`. If
|
||
attacker controlled data enters the DOM, we have to expect security vulnerabilities.
|
||
|
||
为了防范XSS攻击，我们必须阻止恶意代码进入DOM。比如，如果某个攻击者能骗我们把`<script>`标签插入到DOM，就可以在我们的网站上运行任何代码。
|
||
除了`<script>`，攻击者还可以使用很多DOM元素和属性来执行代码，比如`<img onerror="...">`、`<a href="javascript:...">`。
|
||
如果攻击者所控制的数据混进了DOM，就会导致安全漏洞。
|
||
|
||
### Angular’s Cross-site Scripting Security Model
|
||
### Angular的“跨站脚本安全模型”
|
||
|
||
To systematically block XSS bugs, Angular treats all values as untrusted by default. When a value
|
||
is inserted into the DOM from a template, via property, attribute, style, or class binding, or via
|
||
interpolation, Angular will sanitize and escape untrusted values.
|
||
|
||
为了系统性的防范XSS问题，Angular默认把所有值都当做不可信任的。
|
||
当值从模板中以属性（Property）、DOM元素属性（Attribte)、CSS类绑定或插值表达式等途径插入到DOM中的时候，
|
||
Angular将对这些值进行无害化处理（Sanitize），对不可信的值进行编码。
|
||
|
||
**Angular templates are the same as executable code**: HTML, attributes, and binding expressions
|
||
(but not the values bound!) in templates are trusted to be safe. That means applications must
|
||
prevent potentially attacker controlled values from ever making it into the source code of a
|
||
template. Never generate template source code by concatenating user input and templates! Using
|
||
the [offline template compiler](#offline-template-compiler) is an effective way to prevent these
|
||
vulnerabilities, also known as template injection.
|
||
|
||
**Angular的模板同样是可执行的**：模板中的HTML、Attribute和绑定表达式（还没有绑定到值的时候）会被当做可信任的。
|
||
这意味着应用必须防止把来自攻击者的值直接编入模板的源码中。永远不要根据用户的输入和原始模板动态生成模板源码！
|
||
使用[离线模板编译器](#offline-template-compiler)是防范这类“模板注入”漏洞的有效途径。
|
||
|
||
### Sanitization and security contexts
|
||
|
||
### 无害化处理与安全环境
|
||
|
||
Sanitization inspects an untrusted value and turns it into a value that is safe to insert into
|
||
the DOM. In many cases, values do not get changed by this at all. Sanitization depends on context:
|
||
a value that is harmless in CSS is potentially dangerous in a URL.
|
||
|
||
无害化处理会审查不可信的值，并将它们转换成可以安全插入到DOM的形式。多数情况下，这些值并不会在处理过程中发生任何变化。
|
||
无害化处理的方式取决于所在的环境：一个在CSS里面无害的值，可能在URL里很危险。
|
||
|
||
Angular defines four security contexts: HTML, style, URL, and resource URL.
|
||
|
||
Angular定义了四个安全环境：HTML，样式，URL，和资源URL。
|
||
|
||
* HTML is used when interpreting a value as HTML, e.g., when binding to `innerHtml`
|
||
|
||
* HTML：值需要被解释为HTML时使用，比如当绑定到`innerHTML`时。
|
||
|
||
* Style is used when binding CSS into the `style` property
|
||
|
||
* 样式：值需要作为CSS绑定到`style`属性时使用。
|
||
|
||
* URL is used for URL properties such as `<a href>`
|
||
|
||
* URL：值需要被用作URL属性时使用，比如`<a href>`。
|
||
|
||
* Resource URLs are URLs that will be loaded and executed as code, e.g., in `<script src>`
|
||
|
||
* 资源URL：值需要被当做代码而加载并执行时使用，比如`<script src>`中的URL。
|
||
|
||
Angular sanitizes untrusted values for the first three items; sanitizing resource URLs is not
|
||
possible as they contain arbitrary code. In development mode, Angular prints a console warning
|
||
when it has to change a value during sanitization.
|
||
|
||
Angular会对前三项中种不可信的值进行无害化处理。但Angular无法对第四种资源URL进行无害化，因为它们可能包含任何代码。在开发模式下，
|
||
如果Angular在进行无害化处理时需要被迫改变一个值，它就会在控制台上输出一个警告。
|
||
|
||
### Sanitization example
|
||
|
||
### 无害化示例
|
||
|
||
The template below binds the value of `htmlSnippet`, once by interpolating it into an element's
|
||
content, and once by binding it to the `innerHTML` property of an element.
|
||
|
||
下面的例子绑定了`htmlSnippet`的值，一次把它放进插值表达式里，另一次把它绑定到元素的`innerHTML`属性上。
|
||
|
||
+makeExample('app/inner-html-binding.component.html')
|
||
|
||
:marked
|
||
Interpolated content is always escaped - the HTML is not interpreted, and the browser displays
|
||
angle brackets in the elements text content.
|
||
|
||
插值表达式的内容总会被编码 - 其中的HTML不会被解释，所以浏览器会在元素的文本内容中显示尖括号。
|
||
|
||
For the HTML to be interpreted, we must bind to an HTML property, such as `innerHTML`. But binding
|
||
a potentially attacker controlled value into `innerHTML` would normally cause an XSS
|
||
vulnerability. For example, code contained in a `<script>` tag would be executed.
|
||
|
||
如果希望这段HTML被正常解释，就必须绑定到一个HTML属性上，比如`innerHTML`。但是如果把一个可能被攻击者控制的值绑定到`innerHTML`就会导致XSS漏洞。
|
||
比如，包含在`<script>`标签的代码就会被执行。
|
||
|
||
+makeExcerpt('app/inner-html-binding.component.ts ()', 'inner-html-controller')
|
||
|
||
:marked
|
||
Angular recognizes the value as unsafe, and automatically sanitizes it. It removes the `<script>`
|
||
tag but keeps safe content, such as the text content of the `<script>` tag, or the `<b>` element.
|
||
|
||
Angular认为这些值是不安全的，并自动进行无害化处理。它会移除`<script>`标签，但保留安全的内容，比如该片段中的文本内容或`<b>`元素。
|
||
|
||
figure.image-display
|
||
img(src='/resources/images/devguide/security/binding-inner-html.png'
|
||
alt='A screenshot showing interpolated and bound HTML values')
|
||
|
||
:marked
|
||
### Avoid direct use of the DOM APIs
|
||
|
||
### 避免直接使用DOM API
|
||
|
||
The built-in browser DOM APIs do not automatically protect you from security vulnerabilities.
|
||
For example, `document`, the node available through `ElementRef`, and many third party APIs
|
||
contain unsafe methods. Avoid directly interacting with the DOM, and instead use Angular
|
||
templates where possible.
|
||
|
||
浏览器内置的DOM API不会自动针对安全漏洞进行防护。比如，`document`（它可以通过`ElementRef`访问）以及其它第三方API都可能包含不安全的方法。
|
||
要避免直接与DOM交互，只要可能，就尽量使用Angular模板。
|
||
|
||
### Content Security Policy
|
||
|
||
### 内容安全策略
|
||
|
||
A [Content Security Policy (CSP)](http://www.html5rocks.com/en/tutorials/security/content-security-policy/) is a defense-in-depth
|
||
technique to prevent XSS. To enable CSP, configure your web server to return an appropriate
|
||
`Content-Security-Policy` HTTP header.
|
||
|
||
[内容安全策略(CSP)](https://developer.mozilla.org/en-
|
||
US/docs/Web/Security/CSP/Introducing_Content_Security_Policy)是用来防范XSS的纵深防御技术。
|
||
要打开CSP，请配置你的Web服务器，让它返回合适的HTTP头`Content_Security_Policy`。
|
||
|
||
<a id="offline-template-compiler"></a>
|
||
### Use the Offline Template Compiler
|
||
|
||
### 使用离线模板编译器
|
||
|
||
The offline template compiler prevents a whole class of vulnerabilities called template injection,
|
||
and also greatly improves application performance. Use the offline template compiler in production
|
||
deployments. Do not dynamically generate templates. Angular trusts template code, so generating
|
||
templates, in particular containing user data, circumvents Angular's built-in protections. See the
|
||
[Dynamic Forms Cookbook](../cookbook/dynamic-form.html) on how to dynamically construct forms in a
|
||
safe way.
|
||
|
||
离线模板编译器阻止了一整套被称为“模板注入”的漏洞，并能显著增强应用程序的性能。尽量在产品发布时使用离线模板编译器，
|
||
而不要动态生成模板（比如在代码中拼接字符串生成模板）。由于Angular会信任模板本身的代码，所以，动态生成的模板 —— 特别是包含用户数据的模板 —— 会绕过Angular自带的保护机制。
|
||
要了解如何用安全的方式动态创建表单，请参见[动态表单烹饪宝典](../cookbook/dynamic-form.html)一章。
|
||
|
||
### Server side XSS protection
|
||
|
||
### 服务器端XSS保护
|
||
|
||
HTML constructed on the server is vulnerable to injection attacks. Injecting template code into an
|
||
Angular application is the same as injecting executable code into the
|
||
application; it gives the attacker full control over the application. To prevent this, make sure
|
||
to use a templating language that automatically escapes values to prevent XSS vulnerabilities on
|
||
the server. Do not generate Angular templates on the server side using a templating language, this
|
||
carries a high risk of introducing template injection vulnerabilities.
|
||
|
||
服务器端构造的HTML很容易受到注入攻击。当需要在服务器端生成HTML时（比如Angular应用的初始页面），
|
||
务必使用一个能够自动进行无害化处理以防范XSS漏洞的后端模板语言。不要在服务器端使用模板语言生成Angular模板，
|
||
这样会带来很高的“模板注入”风险。
|
||
|
||
.l-main-section
|
||
h2#bypass-security-apis Trusting Safe Values
|
||
|
||
h2#bypass-security-apis 信任安全的值
|
||
|
||
:marked
|
||
Sometimes applications genuinely need to include executable code, display an `<iframe>` from some
|
||
URL, or construct potentially dangerous URLs. To prevent automatic sanitization in this situation,
|
||
you can tell Angular that you inspected a value, checked how it is generated, and made sure it is
|
||
always secure. But **be careful**! If you trust a value that can be malicious, you will likely
|
||
introduce a security vulnerability into your application. If in doubt, find a professional
|
||
security reviewer.
|
||
|
||
有时候，应用程序确实需要包含可执行的代码，比如使用URL显示`<iframe>`，或者构造出有潜在危险的URL。
|
||
为了防止在这种情况下被自动无害化，你可以告诉Angular：我已经审查了这个值，检查了它是怎么生成的，并确信它总是安全的。
|
||
但是**千万要小心**！如果你信任了一个可能是恶意的值，就会在应用中引入一个安全漏洞。如果你有疑问，请找一个安全专家复查下。
|
||
|
||
You can mark a value as trusted by injecting `DomSanitizationService`, and calling one of the
|
||
following methods.
|
||
|
||
注入`DomSanitizationService`服务，然后调用下面的方法之一，你就可以把一个值标记为可信任的。
|
||
|
||
* `bypassSecurityTrustHtml`
|
||
* `bypassSecurityTrustScript`
|
||
* `bypassSecurityTrustStyle`
|
||
* `bypassSecurityTrustUrl`
|
||
* `bypassSecurityTrustResourceUrl`
|
||
|
||
Remember, whether a value is safe depends on context, so you need to choose the right context for
|
||
your intended use of the value. Imagine the following template needs to bind a URL to a
|
||
`javascript:alert(...)` call.
|
||
|
||
记住，一个值是否安全取决于它所在的环境，所以你要为这个值按预定的用法选择正确的环境。假设下面的模板需要把`javascript.alert(...)`方法绑定到URL。
|
||
|
||
+makeExcerpt('app/bypass-security.component.html ()', 'dangerous-url')
|
||
|
||
:marked
|
||
Normally, Angular automatically sanitizes the URL, disables the dangerous code and,
|
||
in development mode, logs this action to the console. To prevent
|
||
this, we can mark the URL value as a trusted URL using the `bypassSecurityTrustUrl` call:
|
||
|
||
通常，Angular会自动无害化这个URL并禁止危险的代码。为了防止这种行为，我们可以调用`bypassSecurityTrustUrl`把这个URL值标记为一个可信任的URL：
|
||
|
||
+makeExcerpt('app/bypass-security.component.ts ()', 'trust-url')
|
||
|
||
figure.image-display
|
||
img(src='/resources/images/devguide/security/bypass-security-component.png'
|
||
alt='A screenshot showing an alert box created from a trusted URL')
|
||
|
||
:marked
|
||
If we need to convert user input into a trusted value, it can be convenient to do so in a
|
||
controller method. The template below allows users to enter a YouTube video ID, and load the
|
||
corresponding video in an `<iframe>`. The `<iframe src>` attribute is a resource URL security
|
||
context, because an untrusted source can, e.g., smuggle in file downloads that unsuspecting users
|
||
would execute. So we call a method on the controller to construct a trusted video URL, which
|
||
Angular then allows binding into `<iframe src>`.
|
||
|
||
如果需要把用户输入转换为一个可信任的值，我们可以很方便的在控制器方法中处理。下面的模板允许用户输入一个YouTube视频的ID，
|
||
然后把相应的视频加载到`<iframe>`中。`<iframe src>`是一个“资源URL”的安全环境，因为不可信的源码可能作为文件下载到本地，被毫无防备的用户执行。
|
||
所以我们要调用一个控制器方法来构造一个新的、可信任的视频URL，然后把它绑定到`<iframe src>`。
|
||
|
||
+makeExcerpt('app/bypass-security.component.html ()', 'iframe-videoid')
|
||
|
||
+makeExcerpt('app/bypass-security.component.ts ()', 'trust-video-url')
|
||
|
||
.l-main-section
|
||
h2#http HTTP-level Vulnerabilities
|
||
|
||
h2#http HTTP级别的漏洞
|
||
|
||
:marked
|
||
Angular has built in support to help prevent two common HTTP vulnerabilities, Cross-site Request
|
||
Forgery (XSRF) and Cross-site Script Inclusion (XSSI). Both of these must be primarily mitigated
|
||
on the server side, but Angular ships helpers to make integration on the client side easier.
|
||
|
||
Angular内建了一些支持来防范两个常见的HTTP漏洞：跨站请求伪造（XSRF）和跨站脚本包含（XSSI）。
|
||
这两个漏洞主要在服务器端防范，但是Angular也自带了一些辅助特性，可以让客户端的集成变得更容易。
|
||
|
||
h3#xsrf Cross-site Request Forgery (XSRF)
|
||
|
||
h3#xsrf 跨站请求伪造（XSRF）
|
||
|
||
:marked
|
||
In a Cross-site Request Forgery (XSRF or CSRF), an attacker tricks the user into visiting a
|
||
_different_ page, and has them, e.g., submit a form that sends a request to your application's
|
||
web server. If the user is logged into your application, the browser will send authentication
|
||
cookies, and the attacker could — for example — cause a bank transfer in the user's name with
|
||
the right request.
|
||
|
||
在跨站请求伪造（XSRF或CSFR）中，一个攻击者会欺骗用户，让他们访问_另一个_页面，并提交一个表单，
|
||
向你应用程序的Web服务器发送一个请求。如果用户已经登录到你的应用程序，浏览器就会发送该用户的认证Cookie，
|
||
这样攻击者就可以发送一个正确的请求，以该用户的名义发起一次银行转账。
|
||
|
||
To prevent this, your application must ensure that user requests originate in your own
|
||
application, not on a different site. A common technique is that the server sends a randomly
|
||
generated authentication token in a cookie, often with the name `XSRF-TOKEN`. Cookies can only
|
||
be read by the website on which they are set, so only your own application can read this token. On
|
||
each API request, the server then validates the client by checking that the token is sent back,
|
||
usually in an HTTP header called `X-XSRF-TOKEN`.
|
||
|
||
为了防止这种情况，你必须确保每个用户的请求都是从你自己的应用中发出的，而不是从另一个网站发出的。
|
||
一个常见的技术是服务器随机生成一个用户认证令牌到cookie中，它的名字通常是`XSRF-TOKEN`。
|
||
由于Cookie只能被创建它的网站访问，所以你自己的程序能读取这个令牌，但攻击者不行。每收到一个API请求，
|
||
服务器就会通过检查这个发回来的令牌对客户端进行验证，这个令牌通常放在HTTP头里，叫做`X-XSRF-TOKEN`。
|
||
|
||
The Angular `http` client has built-in support for this technique. The default
|
||
`CookieXSRFStrategy` looks for a cookie called `XSRF-TOKEN` and sets an HTTP request header named
|
||
`X-XSRF-TOKEN` with the value of that cookie on every request. The server must set the
|
||
`XSRF-TOKEN` cookie, and validate the response header for each state modifying request.
|
||
|
||
Angular的`http`客户端具有对这项技术的内建支持。默认的`CookieXSRFStrategy`会寻找一个名叫`XSFR-TOKEN`的cookie。
|
||
在每个请求中，设置一个名为`X-XSRF-TOKEN`的HTTP请求头，并把该cookie的值赋给它。
|
||
服务器必须设置`XSRF-TOKEN` cookie，并为每个会修改状态的请求验证请求头。
|
||
|
||
XSRF tokens should be unique per user and session, have a large random value generated by a
|
||
cryptographically secure random number generator, and expire.
|
||
|
||
XSRF令牌应该对每个用户和session是唯一的，它包含一大串由安全的随机数字生成器生成的随机值，并且会过期。
|
||
|
||
Angular applications can customize cookie and header names by binding their own
|
||
`CookieXSRFStrategy` value, or implement an entirely custom `XSRFStrategy` by providing a custom
|
||
binding for that type, by adding either of the following to your providers list:
|
||
|
||
Angular应用程序可以通过绑定它们自己的`CookieXSRFStrategy`值来自定义cookie和HTTP头的名字，
|
||
也可以通过提供一个自定义类型绑定来完全制定`XSRFStrategy`，
|
||
只要把下列代码之一加到你的提供商列表里就可以了：
|
||
|
||
code-example(language="typescript").
|
||
{ provide: XSRFStrategy, useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name')}
|
||
{ provide: XSRFStrategy, useClass: MyXSRFStrategy}
|
||
|
||
:marked
|
||
Learn about Cross Site Request Forgery (XSRF) at the Open Web Application Security Project (OWASP)
|
||
[here](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) and
|
||
[here](https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet). This [Stanford University
|
||
paper](https://seclab.stanford.edu/websec/csrf/csrf.pdf) is also a rich source of detail.
|
||
|
||
到开放式Web应用程序安全项目(OWASP)的[这里](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29)
|
||
和[这里](https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)学习更多关于跨站请求伪造（XSRF）的知识。
|
||
这个[斯坦福大学论文](https://seclab.stanford.edu/websec/csrf/csrf.pdf)有详尽的细节。
|
||
|
||
h3#xssi Cross-site Script Inclusion (XSSI)
|
||
|
||
h3#xssi 跨站脚本包含(XSSI)
|
||
|
||
:marked
|
||
Cross-site Script Inclusion, also known as JSON vulnerability, can allow an attacker's website to
|
||
read data from a JSON API. The attack works on older browser by overriding native JavaScript
|
||
object constructors, and then including an API URL using a `<script>` tag.
|
||
|
||
跨站脚本包含，也被称为Json漏洞，它可以允许一个攻击者的网站从JSON API读取数据。这种攻击发生在老的浏览器上，
|
||
它重写原生JavaScript对象的构造函数，然后使用`<script>`标签包含一个API的URL。
|
||
|
||
This attack is only successful if the returned JSON is executable as JavaScript. Servers can
|
||
prevent it by prefixing all JSON responses to make them non-executable, by convention using the
|
||
well-known string `")]}',\n"`.
|
||
|
||
只有在返回的JSON能像JavaScript一样可以被执行时，这种攻击才会生效。所以服务端会约定给所有JSON响应体加上前缀`")]}',\n"`，来把它们标记为不可执行的，
|
||
以防范这种攻击，
|
||
|
||
Angular's `Http` library recognizes this convention and automatically strips the string
|
||
`")]}',\n"` from all responses before further parsing.
|
||
|
||
Angular的`Http`库会识别这种约定，并在进一步解析之前，自动把字符串`")]}',\n"`从所有响应中去掉。
|
||
|
||
Learn more in the XSSI section of this [Google web security blog
|
||
post](https://security.googleblog.com/2011/05/website-security-for-webmasters.html)
|
||
|
||
要学习更多这方面的知识，请参见[谷歌Web安全博客文章](https://security.googleblog.com/2011/05/website-security-for-webmasters.html)的XSSI小节。
|
||
|
||
.l-main-section
|
||
h2#code-review Auditing Angular Applications
|
||
|
||
h2#code-review 审计Angular应用程序
|
||
|
||
:marked
|
||
Angular applications should follow the same security principles as regular web applications, and
|
||
should be audited as such. Angular specific APIs that should be audited in a security review,
|
||
such as the [_bypassSecurityTrust_](#bypass-security-apis) APIs, are marked in the documentation
|
||
as security sensitive.
|
||
|
||
Angular应用应该遵循和常规Web应用一样的安全原则并按照这些原则进行审计。Angular中某些应该在安全评审中被审计的API（
|
||
比如[_bypassSecurityTrust_](#bypass-security-apis) API）都在文档中被明确标记为安全性敏感的。
|