58金融的CSRF防御实践

<img src=” https://hellobank.com/transfer/money/to/?accountId=6225&money=100” />

我们在众多实际项目中总结出如下6条规则。

规则1：get请求无需防御CSRF攻击。

按照HTTP语义来说，get请求仅用于查询，不能用于提交信息。也就是说任何一个get请求，都不应该导致后端业务状态及业务数据的变化。攻击者一定是希望通过CSRF攻击造成后端业务数据的变化，如发帖购物转账等，没有变化也就无需防御。（接口防恶意刷数的除外，不在本文的讨论范围）

该规则虽看似简单，实际开发中却常被接口制定者所忽略。在实际开发中我们见到很多开发中使用get请求提交信息，或者更为隐蔽的漏洞是，虽然get请求没有提交任何信息，但却导致了后端服务状态或数据库数据发生了改变。因此该规则的重点在于后端同学正确理解HTTP语义和定义前后端接口。

规则2：不携带业务cookie的请求无需防御

这条规则看似简单，但往往最容易被开发人员所忽略。CSRF的攻击者一定是希望冒用受害者的身份，通常更准确的术语是cookie，去发送某些请求到服务器以达到攻击者的目的。但如果受害者连业务cookie都没有的话，说明服务器根本不认识该受害者，攻击者的目的也就无法实现了。换句话理解：用户都没登录，不为系统识别，模拟他没有任何收益。（接口防恶意刷数的除外，不在本文的讨论范围）

举个例子，新闻网站的列表页和详情页，一般都开放给所有人查看。攻击者诱使其他非登录用户访问某个新闻页面，没有收益且不会导致新闻网站后台的业务和状态数据改变，因此一般来讲无需防范。（当然如果考虑到点击量和曝光率、广告费的话也有必要防御，这些不在本文讨论范围）

规则3：URL白名单里的post请求无需防范

业务中总会有一些接口，必须设置为禁止防御CSRF攻击。比如第三方的回调请求，一般都是对方服务器直接发起请求到我们的服务器，根本没有经过浏览器，因此肯定无法通过CSRF防御。这类请求一般是靠固定IP、业务token颁发的方式进行安全校验。我们在服务端不做CSRF检测和防御。很多银行类接口如转账，以及微信公众号配置服务器，这类请求经常需要银行服务器或微信服务器异步回调我们的业务服务器，因此必须配置白名单，绕过CSRF检测。

规则4：浏览器端发送post请求时，为header添加csrf参数，其值由业务cookie计算得出

规则5：服务器端收到post请求时，检查其业务cookie及header中的csrf是否正确匹配

为什么最后这俩条规则要放一起呢？因为这俩条规则是CSRF防御的技术核心，前后端代码配合一起作用，才能防御CSRF攻击。单独仅前端或后端防御肯定行不通。

首先，为什么要给请求增加header呢？因为受害者在访问邪恶网页时，受害者向我们的服务器所发出的请求，该请求和邪恶网页的域名一定是不同的，这也是CSRF中的Cross-Site的含义。因此受到跨域的限制，攻击者无法改变该请求的任何信息，特别是受害者的业务cookie值。

所以我们在浏览器端，给合法用户请求的header上加上csrf的参数，并且该参数的值由业务cookie计算得出。如此则攻击者无法事先知道受害者的cookie，也就无法计算出header的csrf参数。

然后在服务器端获取业务cookie以及header中的csrf值进行匹配校验，一致则认为是有效请求，不一致则认为是CSRF攻击进行拦截。

规则6：可以使用专门的CSRF cookie替换业务cookie，但要保证cookie足够随机、无法被预测

针对某些网站，其业务cookie因安全原因或其他历史原因设置为httponly，导致JavaScript无法读取。此时我们需要在nodejs端生成一个可以被JavaScript读取的cookie，专门负责处理CSRF逻辑。

上述规则可以用如下代码逻辑实现（代码仅供逻辑展示，均已脱敏仅供参考）。

这里我们选用了koa2，将判断逻辑抽象成一个函数，返回true时代表截获到了CSRF攻击。

这里可以根据业务需要，适当拓展防御措施，如根据CSRF攻击的频次考虑增加校验码流程，或对IP进行限制。此处不做详述。