Merge branch 'master' of https://github.com/angular/angular-cn
This commit is contained in:
Zhimin YE (Rex)
commit
77fc29977b
|
|
@ -13,7 +13,7 @@ md-toolbar(class="main-nav background-regal l-pinned-top l-layer-5",scroll-y-off
|
|||
li.l-left <a class="main-nav-button" href="/events.html" md-button>开发者会议</a>
|
||||
li.l-left <a class="main-nav-button" href="/news.html" md-button>新闻</a>
|
||||
li.l-left <a class="main-nav-button" href="/translate/cn/about.html" md-button>关于中文版</a>
|
||||
li.l-left <a class="main-nav-button" href="https://angular.io/" md-button target="_blank">官网</a>
|
||||
li.l-left <a class="main-nav-button" href="https://angular.io/" md-button target="_blank">英文版</a>
|
||||
li.l-right <a class="main-nav-button" href="/docs/ts/latest/quickstart.html" md-button>立即开始！</a>
|
||||
li.l-right
|
||||
a.main-nav-button.md-button(ng-click="appCtrl.toggleSource($event)", href)
|
||||
|
|
|
|||
|
|
@ -6,13 +6,12 @@ block includes
|
|||
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提供了一些内建保护措施。本文将讨论这些内建保护措施。
|
||||
但是本文不会覆盖应用程序级别的安全，比如用户认证（_这个用户是谁？_）和授权(_这个用户能做什么？_)
|
||||
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)有更多下面描述的关于攻击和防攻击的信息。
|
||||
[开放式Web应用程序安全项目(OWASP)](https://www.owasp.org/index.php/Category:OWASP_Guide_Project)有关于攻防的更多信息。
|
||||
|
||||
.l-main-section
|
||||
:marked
|
||||
|
|
@ -21,7 +20,7 @@ block includes
|
|||
|
||||
* [Reporting Vulnerabilities](#report-issues)
|
||||
|
||||
* [漏洞报告](#report-issues)
|
||||
* [漏洞举报](#report-issues)
|
||||
|
||||
* [Best Practices](#best-practices)
|
||||
|
||||
|
|
@ -29,7 +28,7 @@ block includes
|
|||
|
||||
* [Preventing Cross-Site Scripting (XSS)](#xss)
|
||||
|
||||
* [防止跨站脚本(XSS)](#xss)
|
||||
* [防范跨站脚本(XSS)攻击](#xss)
|
||||
|
||||
* [Trusting Safe Values](#bypass-security-apis)
|
||||
|
||||
|
|
@ -37,30 +36,31 @@ block includes
|
|||
|
||||
* [HTTP-level Vulnerabilities](#http)
|
||||
|
||||
* [HTTP级别漏洞](#http)
|
||||
* [HTTP级别的漏洞](#http)
|
||||
|
||||
* [Auditing Angular Applications](#code-review)
|
||||
|
||||
* [审计Angular应用程序](#code-review)
|
||||
|
||||
p Try the #[+liveExampleLink2()] of the code shown in this chapter.
|
||||
|
||||
p 运行#[+liveExampleLink2('在线例子')]
|
||||
|
||||
.l-main-section
|
||||
h2#report-issues Reporting Vulnerabilities
|
||||
|
||||
h2#report-issues 漏洞报告
|
||||
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内在的漏洞。
|
||||
给我们[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/)获取更多关于谷歌如何处理安全问题的信息。
|
||||
请到[谷歌安全哲学](https://www.google.com/about/appsecurity/)了解关于“谷歌如何处理安全问题”的更多信息。
|
||||
|
||||
.l-main-section
|
||||
h2#best-practices Best Practices
|
||||
|
|
@ -73,8 +73,8 @@ h2#best-practices 最佳实践
|
|||
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)，获取安全更新详情。
|
||||
* **及时把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
|
||||
|
|
@ -82,23 +82,23 @@ h2#best-practices 最佳实践
|
|||
community and make a pull request.
|
||||
|
||||
* **不要修改你的Angular副本**
|
||||
私有的，制定版本的Angular往往跟不上最新版本，可能会忽略重要的安全补丁和安全增强。取而代之，在社区共享你对Angular的改进并创建Pull Request。
|
||||
私有的、定制版的Angular往往跟不上最新版本，这可能导致你忽略重要的安全修复与增强。反之，应该在社区共享你对Angular所做的改进并创建Pull Request。
|
||||
|
||||
* **Avoid Angular APIs marked in the documentation as “[_Security Risk_](#bypass-security-apis)”.**
|
||||
* **避免使用在文档中标记为“[_安全风险_](#bypass-security-apis)”的Angular API。**
|
||||
* **避免使用在本文档中被标记为“[_安全风险_](#bypass-security-apis)”的Angular API。**
|
||||
|
||||
.l-main-section
|
||||
h2#xss Preventing Cross-Site Scripting (XSS)
|
||||
|
||||
h2#xss 防止跨站脚本(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上最常见的攻击方式之一。
|
||||
[跨站脚本(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
|
||||
|
|
@ -106,20 +106,20 @@ h2#xss 防止跨站脚本(XSS)
|
|||
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的数据，就意味着我们有安全漏洞。
|
||||
为了防范XSS攻击，我们必须阻止恶意代码进入DOM。比如，如果某个攻击者能骗我们把`<script>`标签插入到DOM，就可以在我们的网站上运行任何代码。
|
||||
除了`<script>`，攻击者还可以使用很多DOM元素和属性来执行代码，比如`<img onerror="...">`、`<a href="javascript:...">`。
|
||||
如果攻击者所控制的数据混进了DOM，就会导致安全漏洞。
|
||||
|
||||
### Angular’s Cross-site Scripting Security Model
|
||||
### Angular的跨站脚本的安全级别
|
||||
### 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类绑定或者插值表达式等方式被插入到COM的时候，
|
||||
Angular将对值进行无害化，去掉不可信的值。
|
||||
为了系统性的阻止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
|
||||
|
|
@ -129,75 +129,78 @@ h2#xss 防止跨站脚本(XSS)
|
|||
vulnerabilities, also known as template injection.
|
||||
|
||||
### 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里面很危险。
|
||||
无害化处理会审查不可信的值，并将它转换成可以安全插入到DOM的形式。多数情况下，这些值并不会在处理过程中发生任何变化。
|
||||
无害化处理的方式取决于所在的环境：一个在CSS里面无害的值，可能在URL里很危险。
|
||||
|
||||
Angular defines four security contexts: HTML, style, URL, and resource URL.
|
||||
|
||||
Angular定义四个安全环境：HTML，样式，URL，和资源URL。
|
||||
Angular定义了四个安全环境：HTML，样式，URL，和资源URL。
|
||||
|
||||
* HTML is used when interpreting a value as HTML, e.g. when binding to `innerHtml`
|
||||
|
||||
* HTML：在将一个值按HTML解析时被使用，比如当绑定到`innerHtml`时。
|
||||
* HTML：当一个值将被解释为HTML时使用，比如当绑定到`innerHTML`时。
|
||||
|
||||
* Style is used when binding CSS into the `style` property
|
||||
|
||||
* 样式：在绑定CSS到`style`属性时被使用。
|
||||
* 样式：当把CSS绑定到`style`属性时使用。
|
||||
|
||||
* URL is used for URL properties such as `<a href>`
|
||||
|
||||
* URL： URL属性比如`<a href>`
|
||||
* URL：当被用作URL属性时使用，比如`<a href>`。
|
||||
|
||||
* Resource URLs are URLs that will be loaded and executed as code, e.g. in `<script src>`
|
||||
|
||||
* 资源URL： 它们将会被加载并执行的代码的URL，比如`<script src>`里的URL。
|
||||
* 资源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会在控制台输出一个警告。
|
||||
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`绑定到元素的属性上。
|
||||
下面的例子绑定了`htmlSnippet`的值，一次把它放进插值表达式里，一次把它绑定到元素的`innerHTML`属性上。
|
||||
|
||||
+makeExample('security/ts/app/inner-html-binding.component.html')(format=".")
|
||||
|
||||
:marked
|
||||
Interpolated content is always escaped - the HTML is not interpreted, and the browser displays
|
||||
angle brackets in the elements text content.
|
||||
|
||||
插值内容总是被脱离 - HTML不会被解析，浏览器在元素文本内容中显示尖括号。
|
||||
插值表达式的内容总会被编码 - 其中的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>`标签的代码可以被执行。
|
||||
如果希望这段HTML被正常解释，就必须绑定到一个HTML属性上，比如`innerHTML`。但是如果把一个可能被攻击者控制的值绑定到`innerHTML`就会导致XSS漏洞。
|
||||
比如，包含在`<script>`标签的代码就会被执行。
|
||||
|
||||
+makeExample('security/ts/app/inner-html-binding.component.ts', 'inner-html-controller')(format=".")
|
||||
|
||||
: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>`标签，但保留安全的内容，比如`<script>`标签里面的文本内容或者`<b>`元素。
|
||||
Angular认为这些值是不安全的，并自动进行无害化处理。它会移除`<script>`标签，但保留安全的内容，比如`<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
|
||||
|
||||
|
|
@ -208,8 +211,8 @@ figure.image-display
|
|||
contain unsafe methods. Avoid directly interacting with the DOM, and instead use Angular
|
||||
templates where possible.
|
||||
|
||||
浏览器内置的DOM API不会针对安全漏洞自动保护你。比如，可以通过`ElementRef`访问的节点`document`，以及其他第三方API包含不安全的方法。
|
||||
避免直接与DOM交互，如果可能，尽量使用Angular模版。
|
||||
浏览器内置的DOM API不会自动针对安全漏洞进行保护。比如，`document`（它可以通过`ElementRef`访问）以及其它第三方API都可能包含不安全的方法。
|
||||
要避免直接与DOM交互，只要可能，就尽量使用Angular模板。
|
||||
|
||||
### Content Security Policy
|
||||
|
||||
|
|
@ -221,13 +224,13 @@ figure.image-display
|
|||
`Content-Security-Policy` HTTP header.
|
||||
|
||||
[内容安全策略(CSP)](https://developer.mozilla.org/en-
|
||||
US/docs/Web/Security/CSP/Introducing_Content_Security_Policy)是用来防止XSS的深度防御技术。
|
||||
为了打开CSP，配置你的Web服务器，让它返回合适的`Content_Security_Policy` HTTP头字段。
|
||||
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
|
||||
|
|
@ -236,9 +239,9 @@ figure.image-display
|
|||
[Dynamic Forms Cookbook](../cookbook/dynamic-form.html) on how to dynamically construct forms in a
|
||||
safe way.
|
||||
|
||||
离线模版编译器防止一整套叫做模版注入的漏洞，并能在很大程度上增强应用程序性能。在产品发布时使用离线模板编译器。
|
||||
不要动态的生成模版。Angular信任模版代码，所以生成模版，尤其是包含用户数据的模版能规避Angular自带的保护。
|
||||
参见[动态表单烹饪书](../cookbook/dynamic-form.html)关于如何安全的动态创建表单。
|
||||
离线模板编译器阻止了一整套被称为“模板注入”的漏洞，并能显著增强应用程序的性能。尽量在产品发布时使用离线模板编译器，
|
||||
而不要动态生成模板（比如在代码中拼接字符串生成模板）。由于Angular会信任模板本身的代码，所以，动态生成的模板 —— 特别是包含用户数据的模板 —— 会绕过Angular自带的保护机制。
|
||||
要了解如何用安全的方式动态创建表单，请参见[动态表单烹饪宝典](../cookbook/dynamic-form.html)一章。
|
||||
|
||||
### Server side XSS protection
|
||||
|
||||
|
|
@ -251,14 +254,15 @@ figure.image-display
|
|||
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模版，
|
||||
这样会带来很高的引入模版注入漏洞的风险。
|
||||
服务器端构造的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,
|
||||
|
|
@ -267,14 +271,14 @@ h2#bypass-security-apis 信任安全的值
|
|||
introduce a security vulnerability into your application. If in doubt, find a professional
|
||||
security reviewer.
|
||||
|
||||
有时候，应用程序确实需要包含可执行的代码，比如为一些URL显示一个`<iframe>`，或者构造有潜在危险的URL。
|
||||
为了防止在这种情况下自动无毒化，你可以告诉Angular，说你已经审查了一个值，检查了它是怎么生成的，并且确认它总是安全的。
|
||||
但是**你要非常小心**。如果你信任一个可能可以是恶意的值，你将会引入一个安全漏洞到你的应用。如果你有疑问，找一个安全专家复查。
|
||||
有时候，应用程序确实需要包含可执行的代码，比如使用URL显示`<iframe>`，或者构造出有潜在危险的URL。
|
||||
为了防止在这种情况下被自动无害化，你可以告诉Angular：我已经审查了这个值，检查了它是怎么生成的，并确信它总是安全的。
|
||||
但是**千万要小心**！如果你信任了一个可能是恶意的值，就会在应用中引入一个安全漏洞。如果你有疑问，请找一个安全专家审查下。
|
||||
|
||||
You can mark a value as trusted by injecting `DomSanitizationService`, and calling one of the
|
||||
following methods.
|
||||
|
||||
注入`DomSanitizationService`服务，然后调用下面的方法之一，你就可以标记一个值为可信任。
|
||||
注入`DomSanitizationService`服务，然后调用下面的方法之一，你就可以把一个值标记为可信任的。
|
||||
|
||||
* `bypassSecurityTrustHtml`
|
||||
* `bypassSecurityTrustScript`
|
||||
|
|
@ -286,19 +290,22 @@ h2#bypass-security-apis 信任安全的值
|
|||
your intended use of the value. Imagine the following template needs to bind a URL to a
|
||||
`javascript:alert(...)` call.
|
||||
|
||||
记住，一个值是否安全依赖于它所在的环境，所以你要为这个值的预定用法选择正确的环境。假设下面的的模版需要绑定URL到`javascript.alert(...)`方法。
|
||||
记住，一个值是否安全取决于它所在的环境，所以你要为这个值按预定的用法选择正确的环境。假设下面的模板需要把`javascript.alert(...)`方法绑定到URL。
|
||||
|
||||
+makeExample('security/ts/app/bypass-security.component.html', 'dangerous-url')(format=".")
|
||||
|
||||
:marked
|
||||
Normally, Angular would automatically sanitize the URL and disable the dangerous code. To prevent
|
||||
this, we can mark the URL value as a trusted URL using the `bypassSecurityTrustUrl` call:
|
||||
|
||||
一般情况下，Angular会自动无毒化这个URL并禁止危险的代码。为了防止这种行为，我们可以调用`bypassSecurityTrustUrl`，来标记这个URL值为一个信任的URL：
|
||||
通常，Angular会自动无害化这个URL并禁止危险的代码。为了防止这种行为，我们可以调用`bypassSecurityTrustUrl`把这个URL值标记为一个可信任的URL：
|
||||
|
||||
+makeExample('security/ts/app/bypass-security.component.ts', 'trust-url')(format=".")
|
||||
|
||||
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
|
||||
|
|
@ -307,29 +314,30 @@ figure.image-display
|
|||
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>`。
|
||||
如果需要把用户输入转换为一个可信任的值，我们可以很方便的在控制器方法中处理。下面的模板允许用户输入一个YouTube视频的ID，
|
||||
然后把相应的视频加载到`<iframe>`中。`<iframe src>`是一个“资源URL”的安全环境，因为不可信的源码可能作为文件下载到本地，被毫无防备的用户执行。
|
||||
所以我们要调用一个控制器方法来构造一个新的、可信任的视频URL，然后把它绑定到`<iframe src>`。
|
||||
|
||||
+makeExample('security/ts/app/bypass-security.component.html', 'iframe-videoid')(format=".")
|
||||
|
||||
+makeExample('security/ts/app/bypass-security.component.ts', 'trust-video-url')(format=".")
|
||||
|
||||
.l-main-section
|
||||
h2#http HTTP-level Vulnerabilities
|
||||
|
||||
h2#http HTTP级别漏洞
|
||||
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自带助手工具，可以让客户端集成变得更加容易。
|
||||
Angular内建了一些支持来阻止两个常见的HTTP漏洞：跨站请求伪造（XSRF）和跨站脚本包含（XSSI）。
|
||||
这两个漏洞主要在服务器端防范，但是Angular也自带了一些辅助特性，可以让客户端的集成变得更容易。
|
||||
|
||||
h3#xsrf Cross-site Request Forgery (XSRF)
|
||||
|
||||
h3#xsrf 跨站请求伪造(XSRF)
|
||||
h3#xsrf 跨站请求伪造（XSRF）
|
||||
|
||||
:marked
|
||||
In a Cross-site Request Forgery (XSRF or CSRF), an attacker tricks the user into visiting a
|
||||
|
|
@ -338,9 +346,9 @@ h3#xsrf 跨站请求伪造(XSRF)
|
|||
cookies, and the attacker could - for example - cause a bank transfer in the user's name with
|
||||
the right request.
|
||||
|
||||
在一个跨站请求伪造（XSRF或CSFR）中，一个攻击者欺骗用户，让他们访问一个_不同的_页面，并让他们提交一个表单，
|
||||
向你的应用程序Web服务器发送一个请求。如果用户已经登陆到你的应用程序，浏览器就会发送用户认证cookie，
|
||||
这样攻击者可以-比如- 冒用用户的名字，发送一个正确的请求，触发一次银行转账。
|
||||
在跨站请求伪造（XSRF或CSFR）中，一个攻击者会欺骗用户，让他们访问_另一个_页面，并提交一个表单，
|
||||
向你应用程序的Web服务器发送一个请求。如果用户已经登录到你的应用程序，浏览器就会发送该用户的认证Cookie，
|
||||
这样攻击者就可以发送一个正确的请求，从该用户名下触发一次银行转账。
|
||||
|
||||
To prevent this, your application must make sure that user requests originate in your own
|
||||
application, not on a different site. A common technique is that the server sends a randomly
|
||||
|
|
@ -349,24 +357,24 @@ h3#xsrf 跨站请求伪造(XSRF)
|
|||
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`。
|
||||
为了防止这种情况，你必须确保每个用户的请求都是从你自己的应用中发出的，而不是从另一个网站发出的。
|
||||
一个常见的技术是服务器随机生成一个用户认证令牌到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，
|
||||
并为每个状态修改请求验证返回头字段。
|
||||
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唯一的，它包含一大串随机值，它是由一个加密性安全随机数字生成器生成的，并且会失效。
|
||||
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
|
||||
|
|
@ -374,45 +382,46 @@ h3#xsrf 跨站请求伪造(XSRF)
|
|||
`provide(XSRFStrategy, {useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name')})` or
|
||||
`provide(XSRFStrategy, {useClass: MyXSRFStrategy})` to your providers list.
|
||||
|
||||
Angular应用程序可以自定义cookie和头字段名字，可以通过绑定它们自己的`CookieXSRFStrategy`值，
|
||||
也可以通过提供一个自定义类型绑定实现一个完全制定`XSRFStrategy`。
|
||||
Angular应用程序可以通过绑定它们自己的`CookieXSRFStrategy`值来自定义cookie和HTTP头的名字，
|
||||
也可以通过提供一个自定义类型绑定来完全制定`XSRFStrategy`，只要把`provide(XSRFStrategy, {useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name')})`或`provide(XSRFStrategy, {useClass: MyXSRFStrategy})`加到你的供应商列表里就可以了。
|
||||
|
||||
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 a rich source of detail.
|
||||
|
||||
到开放式Web应用程序安全项目(OWASP)[这里](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29)
|
||||
到开放式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对象构造器，然后在一个API URL中引入一个`<script>`标签。
|
||||
跨站脚本包含，也被称为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一样可以被执行时，这种攻击才有效。在服务端按约定使用著名字符串`")]}',\n"`来前缀所有JSON响应，把它们标记为不可执行，
|
||||
可以防止这种攻击，
|
||||
只有在返回的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"`从所有响应中去掉。
|
||||
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小节学习更多这方面的知识。
|
||||
要学习更多这方面的知识，请参见[谷歌Web安全博客文章](https://security.googleblog.com/2011/05/website-security-for-webmasters.html)的XSSI小节。
|
||||
|
||||
.l-main-section
|
||||
h2#code-review Auditing Angular Applications
|
||||
|
|
@ -425,5 +434,5 @@ h2#code-review 审计Angular应用程序
|
|||
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，都在文档中被标记为安全性敏感。
|
||||
Angular应用应该遵循和常规Web应用一样的安全原则并按照这些原则进行审计。Angular中某些应该在安全评审中被审计的API（
|
||||
比如[_bypassSecurityTrust_](#bypass-security-apis) API）都在文档中被明确标记为安全性敏感的。
|
||||
|
|
|
|||
|
|
@ -16,14 +16,17 @@
|
|||
本文档的任何更新都会实时发布于我们的 [首发网站](http://www.angular.live) 。如果你要进行转载，请自行同步（不过小心别DDoS了我们），或者在想要同步到最新版时 [联系我们](mailto:traveller@163.com) 。
|
||||
## 授权方式
|
||||
本文档遵循[“保持署名—非商用”创意共享4.0许可证（CC BY-NC 4.0）](http://creativecommons.org/licenses/by-nc/4.0/deed.zh)授权方式，你不用知会我们就可以任意转载，但必须保持署名（特别是：不得去掉本页入口链接，也不得修改本页内容），并且不得用于商业目的。
|
||||
|
||||
## 关于译者
|
||||
本文档有两位译者，他们是多年的好友。这次利用业余时间联手翻译，就是因为看好Angular 2的前景，希望帮助大家在这项技术上能跟国外同步前进。
|
||||
|
||||
### 汪志成（雪狼）
|
||||
《AngularJS深度剖析与最佳实践》的作者之一，ThoughtWorks高级咨询师。他从1998年开始做商业软件开发，拥有超过18年的从业经验，至今仍热衷于编程。
|
||||
|
||||
虽然一直在做编程工作，不过他最热衷的却是国学，特别是儒学与诗词。孟子曰：“得天下英才而教育之，三乐也”，愿践行之。
|
||||
|
||||
小道消息：他当年英语四级都没考过哦，现在却可以直接读各种英文资料了。所以，不要怕，英文不是老虎，我行你也行。
|
||||
|
||||
### 叶志敏
|
||||
早期翻译软件《东方快车》的产品经理，至今已在英国留学和生活了十年。目前他正在用Angular 2与.net core开发一套针对英国医疗保健服务行业的ERP系统。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue