58金融的CSRF防御实践

导读
防范CSRF攻击对于互联网企业来说意义重大,本文结合58金融的实践场景,旨在帮助大家共同提高nodejs服务的安全性 。
 
背景
Web端的跨站点请求伪造(Cross Site Request Forgery)攻击,简称CSRF攻击,存在巨大的危害性 。CSRF里,攻击者借用了受害者的身份对服务器发送请求,对服务器来说这个请求是完全合法的,但是却完成了攻击者所期望的一个操作:危害小的如以受害者的名义发帖子,危害大的可以冒用受害者的账号下单甚至转账 。
举个例子,受害者无意访问到了某个邪恶网页,该网页里只需要定义一个图片:
<img src=https://www.isolves.com/it/aq/wl/2020-11-12/” 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服务安全 。
常见认知误区
【58金融的CSRF防御实践】网上有很多文章介绍使用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是否正确匹配


推荐阅读