一个express老系统csrf漏洞修复

一个运行快两年的express框架web系统，被安所有门审核存在csrf漏洞，项目使用的先后端分离的形式，全部功能操做，经过ajax调用后端接口来完成，查了不少资料，一个基本的防护思想就是验证随机数了，为何随机数就能够实现csrf的防护呢？本文将针对该问题进行分解

什么是csrf

csrf(跨站请求伪造)是一种网络攻击方式，怎么实现这种攻击方式呢？
1.登陆受信任网站A，并在本地生成Cookie
2.在不登出A的状况下，访问危险网站B，B站存在一个针对A站恶意的路由操做，如删除某条记录
用户操做后，就会删除形成对A站的攻击
若是不知足以上两个条件中的一个，就不会受到CSRF的攻击

示例1：
　　银行网站A，它以GET请求来完成银行转帐的操做，如：
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
　　危险网站B，它里面有一段HTML的代码以下：
　　<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
　　首先，你登陆了银行网站A，而后访问危险网站B，噢，这时你会发现你的银行帐户少了1000块......
虽然存在着巨大的不肯定性，可是这种漏洞危害性也是巨大的

csrf的防护策略

针对以上的攻击方式，咱们要采起防护措施

• 验证 HTTP Referer 字段

HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在一般状况下，访问一个安全受限页面的请求来自于同一个网站，好比须要访问 http://bank.example/withdraw?...，用户必须先登录 bank.example，而后经过点击页面上的按钮来触发转帐事件。这时，该转账请求的 Referer 值就会是转帐按钮所在的页面的 URL，一般是以 bank.example 域名开头的地址。而若是黑客要对银行网站实施 CSRF 攻击，他只能在他本身的网站构造请求，当用户经过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客本身的网站。所以，要防护 CSRF 攻击，银行网站只须要对于每个转帐请求验证其 Referer 值，若是是以 bank.example 开头的域名，则说明该请求是来自银行网站本身的请求，是合法的。若是 Referer 是其余网站的话，则有多是黑客的 CSRF 攻击，拒绝该请求。
因为Referer能够篡改，因此这种方案安全性较低。

• 验证码的方式

每一次操做前添加验证码，该种方案较繁琐，通常不会采用。

• 随机数验证

如今csrf防护主要采用该种方式，基本流程

1. 服务端产生一个随机数，发送到客户端
2. 客户端在表单提交时，携带该随机数
3. 在服务端验证该随机数

基本的防护思想就是这样的流程，那么怎么来怎么实现这样的业务代码。

因为项目是一个老的系统，因此采起切面处理的方式，

1. 在服务端生成一个随机数csrf,而后加密生成csrftoken，而后将这两个值发送到客户端
2. 在请求时将header中携带csrftoken
3. 服务端验证加密后csrf和csrftoken是否相等

该种方案略显复杂，精简一下

1. 服务生成一个随机数token，设置cookie
2. 在客户端生成通过md5(token)生成一个csrftoken，在请求时携带在header中
3. 在服务端，取cookie中的token，通过md(token)算法后和header中的csrftoken作比较