导语

防范CSRF攻击对于互联网企业来说意义重大，本文结合我们的金融业务的实践场景，旨在帮助大家共同提高nodejs服务的安全性。

背景

Web端的跨站点请求伪造(Cross Site Request Forgery)攻击，简称CSRF攻击，存在巨大的危害性。CSRF里，攻击者借用了受害者的身份对服务器发送请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作：危害小的如以受害者的名义发帖子，危害大的可以冒用受害者的账号下单甚至转账。

举个例子，受害者无意访问到了某个邪恶网页，该网页里只需要定义一个图片

<img src=” https://hellobank.com/transfer/money/to/?accountId=6225&money=100” />，即可达到以受害者的名义向helloback的服务器发送该请求。如果恰好受害者之前访问过hellobank，受害者的合法cookie很有可能会被自动带上一起发送给hellobank服务器，进而通过后者的身份校验，最终转账100元给6225账号。

上面只是一个简单伪造get请求的例子，事实上post请求也可以同样伪造，而且攻击方式也更为复杂。例如，CSRF结合XSS，受害者没有访问过任何邪恶网页的前提下也会被CSRF攻击成功。

由上可见，CSRF攻击的危害性极大，特别是对于金融业务，很多接口都是和货币产品相关，被攻击成功的话后果非常严重。我们的金融业务全部web流量都由nodejs承接，由nodejs负责防御web相关的安全攻击。针对CSRF攻击，我们建立了一套专门的防御方案，在此分享给大家，共同提高web服务安全。

常见认知误区

网上有很多文章介绍使用Http请求头的referrer字段检测是否CSRF，以及介绍使用Post请求代替Get请求来防御CSRF。其实这些手段仅仅是增加了CSRF攻击的难度，并不能真正意义上防御。

想要100%防御CSRF攻击，不仅涉及到后端（服务器）的工作，也涉及到前端（浏览器）的JavaScript代码改造。而且更为重要的是，光靠技术手段远远不够，更需要前后端达成并遵守一套开发规则，才能彻底杜绝CSRF攻击。

开发规则

我们在众多实际项目中总结出如下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攻击返回403状态码。需要注意的是根据koa2的洋葱模型，下面代码应该放置在post路由中间件之前。

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

【转载文章，侵删】