yii框架通过内置的csrf令牌机制有效防止跨站请求伪造攻击，其核心是在表单中自动插入隐藏的csrf令牌并验证请求的合法性，确保用户操作的自主性，该机制默认开启且可通过配置管理，对于ajax请求需手动将yii::$app->request->csrftoken作为数据或x-csrf-token请求头发送以完成验证，同时可通过samesite cookie属性、双重提交cookie和敏感操作二次认证等策略进一步增强防护，避免因忽略令牌传递导致请求失败。
说起Web安全，CSRF（跨站请求伪造）绝对是那种让人头疼却又容易被忽视的家伙。简单来说，YII框架中的CSRF攻击，就是攻击者利用用户在已登录状态下对某个网站的信任，诱导用户点击恶意链接或访问恶意页面，从而在用户不知情或未经授权的情况下执行某些操作，比如修改密码、转账等等。这就像是，你家门没锁，然后有人趁你不在，用你的名义给邻居送了份“大礼”，而你却毫不知情。YII框架在设计之初就考虑到了这一点，它通过一套内置机制来有效地防止这类伪造请求。
YII框架防止伪造请求的核心在于其内置的CSRF验证机制。当你创建一个新的YII应用时，这个功能通常是默认开启的。它主要通过在每个表单中嵌入一个隐藏的CSRF令牌（token）来实现。当用户提交表单时，服务器会检查这个令牌是否有效且与会话中的令牌匹配。如果不匹配，请求就会被拒绝。
在YII中，这个过程通常是透明的。你只需要确保在你的视图文件中，表单是使用
Html::beginForm()或
ActiveForm::begin()等YII提供的助手方法来生成的，因为它们会自动为你插入CSRF令牌。如果你需要手动处理，比如在自定义的AJAX请求中，你需要获取并发送这个令牌。
要启用或禁用CSRF验证，你可以在应用的配置中找到
request组件，然后设置
enableCsrfValidation属性。
// config/web.php 或 config/main.php
'components' => [
'request' => [
// !!! insert a secret key in the following (if it is empty) - this is required by cookie validation
'cookieValidationKey' => 'your-secret-key',
'enableCsrfValidation' => true, // 默认为true，表示开启CSRF验证
'csrfParam' => '_csrf', // CSRF令牌的参数名，默认是_csrf
],
// ...
],如果出于某种特殊原因，你需要在某个控制器或某个动作中临时禁用CSRF验证，你可以在控制器中设置：
class MyController extends Controller
{
public function beforeAction($action)
{
if (in_array($action->id, ['my-action-without-csrf'])) {
$this->enableCsrfValidation = false;
}
return parent::beforeAction($action);
}
public function actionMyActionWithoutCsrf()
{
// 这个动作不会进行CSRF验证
}
}但说实话，我个人极力不推荐随意禁用它，除非你真的非常清楚你在做什么，并且有其他同等甚至更强的安全措施来弥补。大多数时候，出现CSRF验证失败，往往是前端表单生成或AJAX请求处理出了问题，而不是验证本身的问题。
为什么CSRF攻击如此隐蔽且危险？
CSRF攻击的隐蔽性在于它利用的是用户对网站的“信任”，而不是网站本身的“漏洞”。它不直接窃取你的登录凭据，而是劫持你的已登录会话。想象一下，你登录了银行网站，然后打开了另一个看似无害的网页，这个网页里可能藏着一个恶意代码，它悄悄地向银行网站发送了一个转账请求，而这个请求看起来就像是你自己发起的，因为你的浏览器带着你的会话Cookie一起发送了。银行服务器一看，嗯，是这个用户发起的请求，而且Cookie也对，就执行了。你可能要过很久才会发现账户里的钱少了。
这种攻击方式的危险之处在于它的“无感知性”。用户在整个过程中可能完全没有察觉到任何异常，甚至不会收到任何警告。它通常通过钓鱼邮件、恶意广告、或者被入侵的合法网站来传播。而且，由于是利用用户的浏览器执行操作，所以即使网站本身的代码没有直接的安全漏洞，也可能遭受CSRF攻击。这就好比，你的房子很坚固，但有人趁你开门的时候，一把把你推了进去，然后利用你家里的东西做了坏事。
除了YII的内置机制，还有哪些增强CSRF防御的策略？
虽然YII的内置CSRF验证已经很强大，但在实际应用中，我们总能找到一些方法来进一步加固防线。这就像给你的房子加了道锁，然后你又想在窗户上装个防盗网，或者干脆请个保安。
一个常见的增强策略是“双重提交Cookie”（Double Submit Cookie）。虽然YII的令牌机制已经类似，但这里可以更明确地将其分离：一个CSRF令牌放在Cookie中，另一个放在隐藏表单字段中。每次提交时，服务器比对这两个值。如果攻击者无法读取或设置Cookie（由于同源策略），他就无法伪造请求。
另一个值得考虑的是利用HTTP头部。对于AJAX请求，我们可以将CSRF令牌放在自定义的HTTP头部中，比如
X-CSRF-Token。这比放在请求体中更不容易被拦截或篡改，因为浏览器通常会对跨域的自定义头部请求进行预检（OPTIONS请求），这本身就增加了防御层级。
再者，
SameSiteCookie属性是现代浏览器提供的一个强大防御手段。你可以将敏感的会话Cookie设置为
SameSite=Lax或
SameSite=Strict。
Strict模式下，只有当请求是从你当前所在的网站发出的（即URL完全匹配）时，Cookie才会被发送。
Lax模式则稍微宽松一些，允许顶层导航（比如点击链接）发送Cookie，但会阻止跨站的POST请求发送Cookie。YII框架默认的session cookie通常已经设置了
SameSite属性，但检查并确保其配置正确仍然是好习惯。
最后，对于特别敏感的操作，比如修改密码、修改绑定手机号、提现等，我们应该要求用户进行二次验证，例如输入当前密码、短信验证码或Google Authenticator验证码。这本质上是多因素认证的一种应用，即使CSRF令牌被绕过，攻击者也无法完成最终操作，因为他没有第二个验证因素。
在YII中，处理AJAX请求的CSRF验证有什么特别之处？
处理AJAX请求的CSRF验证，在YII中确实有些“特别”，因为它不像传统的表单提交那样，由YII自动帮你插入隐藏字段。你需要手动获取CSRF令牌并将其包含在你的AJAX请求中。
YII将CSRF令牌存储在会话中，并通过
Yii::$app->request->csrfToken这个属性暴露出来。在前端JavaScript中，你需要获取这个值，然后将其作为数据的一部分（比如POST请求的body）或者作为HTTP请求头发送到服务器。
最常见的方法是将其作为POST请求的数据字段发送。假设你的CSRF参数名是默认的
_csrf：
// 在你的HTML或JavaScript文件中，获取CSRF令牌和参数名
const csrfToken = '<?= Yii::$app->request->csrfToken ?>';
const csrfParam = '<?= Yii::$app->request->csrfParam ?>';
// 假设你有一个AJAX POST请求
$.ajax({
url: '/some/action',
type: 'POST',
data: {
[csrfParam]: csrfToken, // 将CSRF令牌作为数据的一部分发送
// ... 其他数据
someData: 'value'
},
success: function(response) {
// 处理成功响应
},
error: function(xhr, status, error) {
// 处理错误
}
});另一种更推荐的方式，尤其对于现代API设计，是将CSRF令牌放在HTTP请求头中。这通常通过自定义一个头部来实现，例如
X-CSRF-Token：
// 在你的HTML或JavaScript文件中
const csrfToken = '<?= Yii::$app->request->csrfToken ?>';
$.ajax({
url: '/some/action',
type: 'POST',
headers: {
'X-CSRF-Token': csrfToken // 将CSRF令牌放在请求头中
},
data: {
// ... 其他数据
someData: 'value'
},
success: function(response) {
// 处理成功响应
},
error: function(xhr, status, error) {
// 处理错误
}
});在YII的后端，如果你使用
X-CSRF-Token头部，你可能需要在控制器或组件中稍微调整一下，确保YII能够从这个头部读取令牌。不过，YII的
request组件通常已经能够智能地从
$_POST或HTTP头部中查找
csrfParam指定的值。所以，只要你前端发送的参数名与
csrfParam配置的一致，YII就能自动验证。
处理AJAX时，最容易犯的错误就是忘记发送CSRF令牌，导致请求被YII拒绝，然后开发人员就会很困惑。所以，当你遇到AJAX请求返回400 Bad Request或者CSRF验证失败的错误时，第一件事就应该检查你的前端代码是否正确地包含了CSRF令牌。
