58金融的CSRF防御实践( 二 ) _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攻击。