Codeigniter 是怎么做 CSRF 防御的

概述

关于如何启用 CSRF 防护，Codeigniter(CI) 官方文档有详细说明。

CSRF 的防御一般比较通用的方案有：

• Referer验证
• Token验证
• 验证码防御

Referer 验证用起来比较简单，但由于各浏览器在 Referer 字段上有着不同的标准，再加上部分验证代码存在逻辑漏洞，所以，一直以来这个方案存在被绕过的风险，效果不是特别理想。而验证码防御的方案又对用户体验有比较大的影响，所以目前来说，基于 token 的验证是最为可用的 CSRF 防护方案，大量开源框架都采用这种方式来抵御 CSRF 攻击的。当然，也有组合这几种的防御方案，效果比单一使用某一方案更优。

CI & CSRF

CI 默认并未开启 CSRF 防御

// /application/config/config.php
$config['csrf_protection'] = FALSE;

若将该值设置为TRUE，则 CI 会对每个 POST 请求进行 CSRF Verify

// /system/core/Input.php
		// CSRF Protection check
		if ($this->_enable_csrf === TRUE && ! is_cli())
		{
			$this->security->csrf_verify();
		}

上面这一步是在 Input 类的 construct 函数里进行的，这意味着一旦开启 CSRF 防御，将全局作用于所有请求，这样不得不为每个 POST 表单添加一个 token 字段，否则请求会被中断。使用 CI 内置的 form_open() 函数将会自动地在表单中插入一个隐藏的 CSRF 字段，但是如果用 Ajax 去提交 POST 请求，就得为每个请求手动添加 csrf_cookie_name 字段，随请求一起传给服务端。

// /system/core/Security.php
	/**
	 * CSRF Verify
	 *
	 * @return	CI_Security
	 */
	public function csrf_verify()
	{
		// If it's not a POST request we will set the CSRF cookie
		if (strtoupper($_SERVER['REQUEST_METHOD']) !== 'POST')
		{
			return $this->csrf_set_cookie();
		}

		// Check if URI has been whitelisted from CSRF checks
		if ($exclude_uris = config_item('csrf_exclude_uris'))
		{
			$uri = load_class('URI', 'core');
			foreach ($exclude_uris as $excluded)
			{
				if (preg_match('#^'.$excluded.'$#i'.(UTF8_ENABLED ? 'u' : ''), $uri->uri_string()))
				{
					return $this;
				}
			}
		}

		// Do the tokens exist in both the _POST and _COOKIE arrays?
		if ( ! isset($_POST[$this->_csrf_token_name], $_COOKIE[$this->_csrf_cookie_name])
			OR $_POST[$this->_csrf_token_name] !== $_COOKIE[$this->_csrf_cookie_name]) // Do the tokens match?
		{
			$this->csrf_show_error();
		}

		// We kill this since we're done and we don't want to polute the _POST array
		unset($_POST[$this->_csrf_token_name]);

		// Regenerate on every submission?
		if (config_item('csrf_regenerate'))
		{
			// Nothing should last forever
			unset($_COOKIE[$this->_csrf_cookie_name]);
			$this->_csrf_hash = NULL;
		}

		$this->_csrf_set_hash();
		$this->csrf_set_cookie();

		log_message('info', 'CSRF token verified');
		return $this;
	}

csrf_verify() 函数对非 POST 请求直接写 CSRF cookie，POST 请求就判断是否在 URI 的白名单里面，若不在白名单再进行判断 _POST 和 _COOKIE 里是否有 CSRF token，并且判断两者是否相等，只有在存在且相等的情况下才通过校验，否则提示错误403。这一步的逻辑其实是建立在发起 CSRF 攻击的黑客理论上无法获取第三方 cookie 基础上的，得不到 cookie 便无法构造表单里的 token，就过不了这里的 csrf_verify()。

在校验完成后，为了不污染 _POST 数组，CI 调用 unset 函数处理了 _POST 数组里的 csrf token，重新生成新的 token 并写到 cookie。

// /system/core/Security.php
	/**
	 * CSRF Set Cookie
	 *
	 * @codeCoverageIgnore
	 * @return	CI_Security
	 */
	public function csrf_set_cookie()
	{
		$expire = time() + $this->_csrf_expire;
		$secure_cookie = (bool) config_item('cookie_secure');

		if ($secure_cookie && ! is_https())
		{
			return FALSE;
		}

		setcookie(
			$this->_csrf_cookie_name,
			$this->_csrf_hash,
			$expire,
			config_item('cookie_path'),
			config_item('cookie_domain'),
			$secure_cookie,
			config_item('cookie_httponly')
		);
		log_message('info', 'CSRF cookie sent');

		return $this;
	}

上面是设置 CSRF 防御 cookie 的函数，cookie 属性可以从配置文件里读取

// /application/config/config.php
$config['csrf_token_name'] = 'csrf_test_name';
$config['csrf_cookie_name'] = 'csrf_cookie_name';
$config['csrf_expire'] = 7200;
$config['csrf_regenerate'] = TRUE;
$config['csrf_exclude_uris'] = array();

cookie 有效期默认是7200秒，也就是2小时，由于一旦开启 CSRF 防御，就是全局作用于所有的请求，所以有时候难免会有误伤，但 CI 并没做到在 controller 层动态配置，而是在 Input 类初始化的位置调用 csrf_verify() 函数完成校验。当然，CI 开放了白名单策略，也就是配置文件里的 $config['csrf_exclude_uris'] ，可以把不需要做 CSRF 防御的 uri 添加到该值里面。

总结

从源码里不难看出 CI 通过比较 _COOKIE 和 _POST 中的 token 值来做 CSRF 防御，咋一看似乎觉得 _COOKIE 和 _POST 的内容对客户端来说都是可控的，但仔细思考一下，在 CSRF 的攻击场景下，攻击者是无法读取到受害者的 cookie 信息的，这也是该防御方式有效的前提所在。