Halo

A magic place for coding

0%

浅谈CSRF攻击

Introduction

  上一篇博客介绍了JWT,其中在介绍token验证时提到了CSRF攻击。在今天这篇博客,我将详细地介绍一下CSRF是什么,以及需要怎么防范。

What is CSRF

  这里是我第一次介绍安全问题,首先我们大致把问题分成前端和后端,CSRF就是一个很经典的前端安全问题。我们先用一个例子去看看遇到的问题是什么?

  1. 同学A在使用Gmail看邮件,然后突然看到一封垃圾邮件,里面有一个链接,于是好奇地点了进去;
  2. 跳转到浏览器后,发现页面是空白的,好像也没有提示扣钱什么,查了一下自己的银行账户还是安全的,于是同学A就把页面关掉,觉得逃过一劫;
  3. 过了一个月后,同学A突然发现自己的steam账号被偷了,他很好奇对方是怎么登进去的,因为登录是steam是需要验证码的,而验证码会发送到Gmail;
  4. 于是同学A打开Gmail,仔细搜了下验证码的邮件,然后他发现他的发件箱出现了这封邮件,然后就发现问题了,原来他的auto filter中设置了一条转发规则,凡是遇到steam系统发送的邮件,都会自动转发一份到xxx@abc.com(攻击者的邮箱)这个邮箱;
  5. 然后同学A想起了一个月前发生的事情,那条链接,它又找到了那封邮件,点开那条链接,然后看了下源码,发现里面会发起一个POST请求,往自己的auto filter中添加一条转发规则。

  于是事情就水落石出了,同学A首先登陆了Gmail,所以浏览器就会记录下Gmail的cookie,然后后面攻击的链接点开后,直接发起一个POST请求,请求的时候浏览器会自动带上cookie,对于Gmail来说,对cookie的验证是通过的,所以它认为这是来自用户的合法请求,于是一条转发规则就这样在用户不知情的情况下被创建了。

  这个就是Gmail著名的CSRF漏洞问题:https://www.davidairey.com/google-gmail-security-hijack/

  通过这里例子,我们知道了一个CSRF的攻击到底是怎么样了。然后我们从理论的角度看看CSRF是什么。

  CSRF(Cross-Site Request Forgery),中文叫跨站请求伪造,指的是攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求,通过利用受害者在被攻击网站已经获取的认证凭证(cookie),绕过后台的用户认证,达到冒充用户对被攻击的网站执行某种操作的目的。

  在上述的例子中,第三方网站就是那个垃圾邮件里面的链接,被攻击网站就是Gmail的服务器,受害者当然就是同学A了。所谓跨站就是从第三方网站跨到了被攻击网站。为什么是跨域的呢?因为通常来说本域下的防护会做的比较好,而外域更加有可能被攻击者掌握,所以就叫跨域。但是如果本域下有类似的漏洞,那就会带来更加严重的问题。

Characteristics of CSRF

  1. 攻击的发起方一般是第三方网站,而被攻击的网站无法做防护,因为仅凭cookie根本分不清是不是用户的真实操作;
  2. 攻击的手段一般是冒充用户进行提交操作,而不是直接窃取数据,因为浏览器返回的结果是在用户的界面上,根据浏览器的同源策略的限制,攻击者也无法获取返回的结果。因此CSRF重点的防护对象是允许用户操作的界面,而对于读请求则风险较低;
  3. 整个攻击过程,攻击者都无法获取用户的身份凭证,他只是冒用,而没有窃取;

How to deal with CSRF

  我们了解了CSRF的攻击原理后,就来看看怎么对应用做一个基本的防护。

  • 阻止不明外域的访问
    • 访问是也进行同源检测;
    • 使用samesite cookie;
  • 提交操作请求时,要求带上本域信息
    • CSRF token;
    • 双重cookie验证;

同源检测

  既然CSRF攻击的一大特点是从外域进行访问,那么可以直接在访问的时候就判断origin是否来自外域。这里又有一个问题,服务器怎么知道是来自哪个域呢?我们要确保这个信息是可靠的,才能做到同源检测。

  通常在http协议中,每个异步请求都会携带两个Header,用于标记来源域名:

  • Origin Header
  • Referer Header

  这两个header在浏览器发起请求时会自动带上,并且不能由用户自定义内容填写,所以服务器是可以利用这两个header的域名来知道请求的来源域。接下来我们就来看看怎么利用这两个header去做检测。

Origin Header

  在部分与CSRF有关的请求中(注意是与CSRF有关的请求,正常的同域名的请求不会带上这个header,F12可以查看),请求的Header会带上Origin字段,里面包含了请求的域名。服务端可以直接利用这个信息去做同源检测。

  但有三种情况Origin字段不存在:

  1. IE11同源策略:IE11不会在跨站CORS请求上添加Origin,根本原因是IE11对same-origin的定义不同。IE认为如果跨域请求发生在不同端口之间也属于同源,则不会添加Origin字段;同时对于高度信任的域,IE也不会apply同源策略;
  2. 302重定向:302重定向时不会带上Origin,因为Origin被认为是敏感信息,因此浏览器不会把这类信息泄漏到新的服务器上(重定向的服务器)。

Referer Header

  除了使用Origin字段外,还能使用Referer这个字段,它记录了该http请求的来源地址。这个来源地址,对于ajax请求、资源请求来说,就是发起请求时页面的地址;对于页面跳转来说就是上一个页面的地址。

  但是这个Referer的值是由浏览器提供的,严格来说也不是绝对安全,具体要看每个浏览器的实现。因此在2014年W3C发布了Referrer Policy草案,对浏览器如何发送Referer做了详细的规定,目前大部分的浏览器都遵循这份草案。目前来说,只要把Referrer Policy设置为same-origin,则符合严格的同源校验要求。

  这里要注意当https跳转到http页面时,Referer会丢失。

  对于Origin和Referer都不存在的请求,最保险的做法就是都拒绝掉,但是这里会存在一种误伤。如果用户从搜索引擎搜到某个页面,然后点开,这样大概率是不同源的,那么如何过滤掉这种请求呢?

  通常来说这种页面请求的Header符合以下特性:

1
2
Accept: text/html
Method: GET

  这种Header意思是客户端向服务端请求html资源,使用的是GET方法,因此大概率就是普通的页面访问了。所以一般的网站会把这类请求放开,这也说明对于这类请求,CSRF是没有同源检测的。反过来说,对开发者而言,不要在GET的方法中去做用户数据的操作,最好就是只返回一些数据(许多网站为了减少请求次数,会把主文档GET请求带上参数实现一下产品功能,实际上这是一个风险点)。

CSRF token

  上面使用同源检测的方式实际上还是大家都遵循某个规范,然后服务端信任浏览器传过来的Header,从而进行判断。如果是使用主流的、新版的浏览器就一般没什么问题,但是如果遇到不遵守规范的浏览器就很容易gg了。此时,作为一个成熟的开发者,当然不能把锅甩给用户,就算用户使用了低版本的浏览器,我们同样也需要做好防护。因此CSRF是一种更加彻底的手段。

  重新理解CSRF的原理,是借用了cookie信息,但是从头到尾攻击者都无法知道用户的cookie具体是什么。所以我们只需要再携带多一个信息,这个信息不能在cookie中,必须是攻击者无法获取的,这样服务端就能利用这个额外的信息去做身份校验,这个额外的信息就是CSRF token。

  CSRF的验证过程主要有以下步骤:

  1. 页面加载时,遍历整个DOM tree,对其中所有的aform标签添加token,这样在请求这些资源时给服务器验证。但是对于动态的HTML代码,需要在coding中加入token;
  2. GET请求会把token放在URL后面,而POST请求则放在form中;
  3. 服务器收到请求后,拿到token,需要判断有效性。服务器生成token一般是通过一个随机生产的字符串加上时间戳组成一个新的字符串,然后加密。所以验证的过程相反,先对token进行解密,然后拿到加密的字符串和时间戳,比对加密的字符串是否一致,同时确保时间还没过期,如果两者都满足要求则验证通过。

  一般来说服务端会先生成一个csrf token返回给客户端,然后带上一个refresh token,当经过一定时间后,csrf token会过期,需要客户端重新请求,带上用户的登录信息和refresh token,去换取新的csrf token。这样通过过期的方法一定程度上提高了csrf的安全性。

  虽然CSRF token方法使用起来比同源检测要靠谱得多,但是同时也给服务端带来了压力。这个压力具体指的是,用户的session一般来说会存在单台设备上,或者是partition的存储组件上,如果每次都需要全部扫描一般的话,耗时将会是不可接受的。因此目前的做法是采用Encrypted Token Pattern,这种方式下,CSRF token是由user_id(或其他有业务意义的值)加上时间戳以及随机数再加密生成,这样在解密验证时,第一层解密后就能直接拿到user_id,然后路由到相应的服务器进行处理,实现分布式。

Summary

  这篇博客从一个实际的例子出发介绍了CSRF的过程及背后的原理,也简单介绍了两种防范的方法。

Reference

  1. 美团技术团队-如何防止CSRF攻击
  2. 浏览器的同源策略
  3. Same Origin Policy

Welcome to my other publishing channels