translate: security.jade, new reworded part.
This commit is contained in:
Zhimin YE
parent
f42cc68544
commit
e4c327c2d1
|
|
@ -348,49 +348,81 @@ h3#xsrf 跨站请求伪造（XSRF）
|
|||
a different web page (e.g. `evil.com`) with malignant code that secretly sends a malicious request
|
||||
to your application's web server (e.g. `example-bank.com`).
|
||||
|
||||
在跨站请求伪造（XSRF或CSFR）中，攻击者欺骗用户，让他们访问一个假冒页面(例如`evil.com`)，
|
||||
该页面带有恶意代码，秘密的向你的应用程序服务器发送恶意请求(e.g. `example-bank.com`)。
|
||||
|
||||
Assume the user is logged into the application at `example-bank.com`.
|
||||
The user opens an email and clicks a link to `evil.com` which opens in a new tab.
|
||||
|
||||
假设用户已经在`example-bank.com`登录。用户打开一个邮件，点击里面的链接，在新页面中打开`evil.com`。
|
||||
|
||||
The `evil.com` page immediately sends a malicious request to `example-bank.com`.
|
||||
Perhaps it's a request to transfer money from the user's account to the attacker's account.
|
||||
The browser automatically sends the `example-bank.com` cookies (including the authentication cookie) with this request.
|
||||
|
||||
该`evil.com`页面立刻发送恶意请求到`example-bank.com`。这个请求可能是从用户账户转账到攻击者的账户。
|
||||
与该请求一起，浏览器自动发出`example-bank.com`的cookie。
|
||||
|
||||
The `example-bank.com` server, if it lacks XSRF protection, can't tell the difference between a legitimate request from the application
|
||||
and the forged request from `evil.com`.
|
||||
|
||||
如果`example-bank.com`服务器缺乏XSRF保护，就无法辨识请求是从应用程序发来的合法请求还是从`evil.com`来的假请求。
|
||||
|
||||
To prevent this, the application must ensure that a user request originates from the real
|
||||
application, not from a different site.
|
||||
The server and client must cooperate to thwart this attack.
|
||||
|
||||
为了防止这种情况，你必须确保每个用户的请求都是从你自己的应用中发出的，而不是从另一个网站发出的。
|
||||
客户端和服务器必须合作来抵挡这种攻击。
|
||||
|
||||
In a common anti-XSRF technique, the application server sends a randomly
|
||||
generated authentication token in a cookie.
|
||||
The client code reads the cookie and adds a custom request header with the token in all subsequent requests.
|
||||
The server compares the received cookie value to the request header value and rejects the request if the values are missing or don't match.
|
||||
|
||||
常见的反XSRF技术是服务器随机生成一个用户认证令牌到cookie中。
|
||||
客户端代码获取这个cookie，并用它为接下来所有的请求添加自定义请求页头。
|
||||
服务器比较收到的cookie值与请求页头的值，如果它们不匹配，便拒绝请求。
|
||||
|
||||
This technique is effective because all browsers implement the _same origin policy_. Only code from the website
|
||||
on which cookies are set can read the cookies from that site and set custom headers on requests to that site.
|
||||
That means only your application can read this cookie token and set the custom header. The malicious code on `evil.com` can't.
|
||||
|
||||
这个技术之所以有效，是因为所有浏览器都实现了_同源策略_。只有设置cookie的网站的代码可以访问该站的cookie，并为该站的请求设置自定义页头。
|
||||
这就是说，只有你的应用程序可以获取这个cookie令牌和设置自定义页头。`evil.com`的恶意代码不能。
|
||||
|
||||
Angular's `http` has built-in support for the client-side half of this technique in its `XSRFStrategy`.
|
||||
The default `CookieXSRFStrategy` is turned on automatically.
|
||||
Before sending an HTTP request, the `CookieXSRFStrategy` looks for a cookie called `XSRF-TOKEN` and
|
||||
sets a header named `X-XSRF-TOKEN` with the value of that cookie.
|
||||
|
||||
Angular的`http`客户端在其`XSRFStrategy`中具有对这项技术的内置支持。
|
||||
默认的`CookieXSRFStrategy`会被自动开启
|
||||
在发送每个请求之前，`CookieXSRFStrategy`查询名为`XSRF-TOKEN`的cookie，并设置一个名为`X-XSRF-TOKEN`的HTTP请求头，并把该cookie的值赋给它。
|
||||
|
||||
The server must do its part by setting the
|
||||
initial `XSRF-TOKEN` cookie and confirming that each subsequent state-modifying request
|
||||
includes a matching `XSRF-TOKEN` cookie and `X-XSRF-TOKEN` header.
|
||||
|
||||
服务器必须要完成自己的任务，设置初始`XSRF-TOKEN`cookie，并确认接下来的每个请求包含了配对的`XSRF-TOKEN`cookie和`X-XSRF-TOKEN`页头。
|
||||
|
||||
XSRF/CSRF tokens should be unique per user and session, have a large random value generated by a
|
||||
cryptographically secure random number generator, and should expire in a day or two.
|
||||
|
||||
CSRF令牌对每个用户和session应该是唯一的，它包含一大串由安全的随机数字生成器生成的随机值，并且在一两天之内过期。
|
||||
|
||||
Your server may use a different cookie or header name for this purpose.
|
||||
An Angular application can customize cookie and header names by providing its own `CookieXSRFStrategy` values.
|
||||
|
||||
你服务器可能使用不同的cookie或者页头名字。Angular应用可以通过自己的`CookieXSRFStrategy`值来自定义cookie和页头名字。
|
||||
|
||||
code-example(language="typescript").
|
||||
{ provide: XSRFStrategy, useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name') }
|
||||
:marked
|
||||
Or you can implement and provide an entirely custom `XSRFStrategy`:
|
||||
|
||||
或者你可以实现和提供完整的自定义`XSRFStrategy`。
|
||||
|
||||
code-example(language="typescript").
|
||||
{ provide: XSRFStrategy, useClass: MyXSRFStrategy }
|
||||
|
||||
|
|
@ -401,13 +433,15 @@ code-example(language="typescript").
|
|||
The Stanford University paper
|
||||
<a href="https://seclab.stanford.edu/websec/csrf/csrf.pdf" target="_blank">Robust Defenses for Cross-Site Request Forgery</a> is a rich source of detail.
|
||||
|
||||
See also Dave Smith's easy-to-understand
|
||||
<a href="https://www.youtube.com/watch?v=9inczw6qtpY" target="_blank" title="Cross Site Request Funkery Securing Your Angular Apps From Evil Doers">talk on XSRF at AngularConnect 2016</a>.
|
||||
|
||||
到开放式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)有详尽的细节。
|
||||
|
||||
See also Dave Smith's easy-to-understand
|
||||
<a href="https://www.youtube.com/watch?v=9inczw6qtpY" target="_blank" title="Cross Site Request Funkery Securing Your Angular Apps From Evil Doers">talk on XSRF at AngularConnect 2016</a>.
|
||||
|
||||
参见Dave Smith在<a href="https://www.youtube.com/watch?v=9inczw6qtpY" target="_blank" title="Cross Site Request Funkery Securing Your Angular Apps From Evil Doers">AngularConnect 2016关于XSRF的演讲</a>。
|
||||
|
||||
h3#xssi Cross-site script inclusion (XSSI)
|
||||
|
||||
h3#xssi 跨站脚本包含(XSSI)
|
||||
|
|
|
|||
Loading…
Reference in New Issue