58金融的CSRF防御实践

背景

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 攻击的危害性极大，特别是对于金融业务，很多接口都是和货币产品相关，被攻击成功的话后果非常严重。 58 金融的全部 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 进行限制。此处不做详述。

作者简介：

贾建容， 58金融前端负责人，主要负责金融中后台系统架构和建设。

推荐阅读：

微前端在金融的实践应用

58金融前端脚手架的设计与实现

Java中看内存分配—Netty内存池

沙龙干货|58同城-深度学习平台资源使用率优化实践