@ -44,7 +44,7 @@ Further reading on the topic:
由于手动的给所用的输出转义容易出错，
Yii 提供了大量的工具来在不同的上下文执行转义。
Further reading on the topic:
进一步阅读该话题：
- < https: / / www . owasp . org / index . php / Command_Injection >
- < https: / / www . owasp . org / index . php / Code_Injection >
@ -115,7 +115,7 @@ $rowCount = $connection->createCommand($sql)->queryScalar();
你可以在 [Quoting Table and Column Names ](db-dao.md#quoting-table-and-column-names ) 中获取更多的语法细节。
Further reading on the topic:
进一步阅读该话题：
- < https: / / www . owasp . org / index . php / SQL_Injection >
@ -149,7 +149,7 @@ XSS 或者跨站脚本发生在输出 HTML 到浏览器时，输出内容没有
注意 HtmlPurifier 帮助类的处理过程较为费时，建议增加缓存。
Further reading on the topic:
进一步阅读该话题：
- < https: / / www . owasp . org / index . php / Cross-site_Scripting_ % 28XSS % 29 >
@ -160,21 +160,21 @@ Further reading on the topic:
CSRF 是跨站请求伪造的缩写。这个攻击思想源自许多应用程序假设来自用户的浏览器请求是由用户自己产生的，
而事实并非如此。
For example, the website `an.example.com` has a `/logout` URL that, when accessed using a simple GET request, logs the user out. As long
as it's requested by the user themselves everything is OK, but one day bad guys are somehow posting
`<img src="http://an.example.com/logout">` on a forum the user visits frequently. The browser doesn't make any difference between
requesting an image or requesting a page so when the user opens a page with such a manipulated `<img>` tag,
the browser will send the GET request to that URL and the user will be logged out from `an.example.com` .
例如，网站 `an.example.com` 有一个 `/logout` 网址, 当使用简单的 GET 请求访问时, 记录用户退出。
只要用户的请求一切正常，但是有一天坏人们故意在用户经常访问的论坛上放上 `<img src="http://an.example.com/logout">` 。
浏览器在请求图像或请求页面之间没有任何区别，
所以当用户打开一个带有这样一个被操作过的 `<img>` 标签的页面时，
浏览器将 GET 请求发送到该 URL，用户将从 `an.example.com` 注销。
That's the basic idea of how a CSRF attack works. One can say that logging out a user is not a serious thing,
however this was just an example, there are much more things one could do using this approach, for example triggering payments
or changing data. Imagine that some website has an URL
`http://an.example.com/purse/transfer?to=anotherUser&amount=2000` . Accessing it using GET request, causes transfer of $2000
from authorized user account to user `anotherUser` . We know, that the browser will always send GET request to load an image,
so we can modify code to accept only POST requests on that URL. Unfortunately, this will not save us, because an attacker
can put some JavaScript code instead of `<img>` tag, which allows to send POST requests to that URL as well.
这是 CSRF 攻击如何运作的基本思路。可以说用户退出并不是一件严重的事情，
然而这仅仅是一个例子，使用这种方法可以做更多的事情，例如触发付款或者是改变数据。
想象一下如果某个网站有一个这样的 `http://an.example.com/purse/transfer?to=anotherUser&amount=2000` 网址。
使用 GET 请求访问它会导致从授权用户账户转账 $2000 给 `anotherUser` 。
我们知道，浏览器将始终发送 GET 请求来加载图像，
所以我们可以修改代码以仅接受该 URL 上的 POST 请求。
不幸的是，这并不会拯救我们，因为攻击者可以放置一些 JavaScript 代码而不是 `<img>` 标签，这样就可以向该 URL 发送 POST 请求。
For this reason, Yii applies additional mechanisms to protect against CSRF attacks.
出于这个原因，Yii 应用其他机制来防止 CSRF 攻击。
为了避免 CSRF 攻击，你总是需要：
@ -182,7 +182,7 @@ For this reason, Yii applies additional mechanisms to protect against CSRF attac
有关详细信息，请参阅 [RFC2616 ](https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html )。
2. 保证 Yii CSRF 保护开启。
Sometimes you need to disable CSRF validation per controller and/or action. It could be achieved by setting its property:
有的时候你需要对每个控制器和/或方法使用禁用 CSRF。可以通过设置其属性来实现：
```php
namespace app\controllers;
@ -201,7 +201,7 @@ class SiteController extends Controller
}
```
To disable CSRF validation per custom actions you can do:
要对每个自定义方法禁用 CSRF 验证，您可以使用：
```php
namespace app\controllers;
@ -219,8 +219,8 @@ class SiteController extends Controller
}
```
Disabling CSRF validation in [standalone actions ](structure-controllers.md#standalone-actions ) must be done in `init()`
method. Do not place this code into `beforeRun()` method because it won't have effect.
在 [standalone actions ](structure-controllers.md#standalone-actions ) 禁用 CSRF 必须在 `init()` 方法中设置。
不要把这段代码放在 `beforeRun()` 方法中，因为它不会起任何作用。
```php
< ?php
@ -251,9 +251,9 @@ class ContactAction extends Action
}
```
> Warning: Disabling CSRF will allow any site to send POST requests to your site. It is important to implement extra validation such as checking an IP address or a secret token in this case.
> 警告: 禁用 CSRF 将允许任何站点向您的站点发送 POST 请求。在这种情况下，实施额外验证非常重要，例如检查 IP 地址或秘密令牌。
Further reading on the topic:
进一步阅读该话题：
- < https: / / www . owasp . org / index . php / CSRF >
@ -281,20 +281,20 @@ Further reading on the topic:
调试工具栏同样也应该避免在生产环境出现，除非非常有必要。它将会暴露所有的应用和配置的详情信息。
如果你确定需要，反复确认其访问权限限定在你自己的 IP。
Further reading on the topic:
进一步阅读该话题：
- < https: / / www . owasp . org / index . php / Exception_Handling >
- < https: / / www . owasp . org / index . php / Top_10_2007-Information_Leakage >
Using secure connection over TLS
使用 TLS 上的安全连接
--------------------------------
Yii provides features that rely on cookies and/or PHP sessions. These can be vulnerable in case your connection is
compromised. The risk is reduced if the app uses secure connection via TLS.
Yii 提供依赖 cookie 和/或 PHP 会话的功能。如果您的连接受到威胁，这些可能会很容易受到攻击。
如果应用程序通过 TLS 使用安全连接，则风险会降低。
Please refer to your webserver documentation for instructions on how to configure it. You may also check example configs
provided by H5BP project:
有关如何配置它的说明，请参阅您的 Web 服务器文档。
您还可以参考 H5BP 项目提供的示例配置：
- [Nginx ](https://github.com/h5bp/server-configs-nginx )
- [Apache ](https://github.com/h5bp/server-configs-apache ).
@ -302,30 +302,30 @@ provided by H5BP project:
- [Lighttpd ](https://github.com/h5bp/server-configs-lighttpd ).
Secure Server configuration
安全服务器配置
---------------------------
The purpose of this section is to highlight risks that need to be considered when creating a
server configuration for serving a Yii based website. Besides the points covered here there may
be other security related configuration options to be considered, so do not consider this section to
be complete.
本节的目的是强调在为基于 Yii 的网站提供服务配置时需要考虑的风险。
除了这里涉及的要点之外，
可能还有其他与安全相关的配置选项，
所以不要认为这部分是完整的。
### Avoiding `Host` -header attacks
### 避免 `Host` -header 攻击
Classes like [[yii\web\UrlManager]] and [[yii\helpers\Url]] may use the [[yii\web\Request::getHostInfo()|currently requested host name]]
for generating links.
If the webserver is configured to serve the same site independent of the value of the `Host` header, this information may not be reliable
and [may be faked by the user sending the HTTP request ](https://www.acunetix.com/vulnerabilities/web/host-header-attack ).
In such situations you should either fix your webserver configuration to serve the site only for specified host names
or explicitly set or filter the value by setting the [[yii\web\Request::setHostInfo()|hostInfo]] property of the `request` application component.
像 [[yii\web\UrlManager]] 和 [[yii\helpers\Url]] 这样的类会使用
[[yii\web\Request::getHostInfo()|currently requested host name]] 来生成链接。
如果 Web 服务器配置为独立于 `Host` 标头的值提供相同的站点,这个信息并不可靠，
并且 [可能由发送HTTP请求的用户伪造 ](https://www.acunetix.com/vulnerabilities/web/host-header-attack ).
在这种情况下，您应该修复您的 Web 服务器配置以便仅为指定的主机名提供站点服务
或者通过设置 `request` 应用程序组件的 [[yii\web\Request::setHostInfo()|hostInfo]] 属性来显式设置或过滤该值。
For more information about the server configuration, please refer to the documentation of your webserver:
有关于服务器配置的更多信息，请参阅您的 web 服务器的文档：
- Apache 2: < http: / / httpd . apache . org / docs / trunk / vhosts / examples . html # defaultallports >
- Nginx: < https: / / www . nginx . com / resources / wiki / start / topics / examples / server_blocks / >
If you don't have access to the server configuration, you can setup [[yii\filters\HostControl]] filter at
application level in order to protect against such kind of attack:
如果您无权访问服务器配置，您可以在应用程序级别设置 [[yii\filters\HostControl]] 过滤器，
以防此类的攻击。
```php
// Web Application configuration file
@ -342,6 +342,6 @@ return [
];
```
> Note: you should always prefer web server configuration for 'host header attack' protection instead of the filter usage.
[[yii\filters\HostControl]] should be used only if server configuration setup is unavailable.
> 提示: 您应该始更倾向于使用 web 服务器配置 'host header attack' 保护而不是使用过滤器。
仅当服务器配置设置不可用时 [[yii\filters\HostControl]] 才应该被使用。
yolanda
6 years ago
committed by
GitHub