前端安全 - CSRF

上一篇文章讲完了XSS，那么咱们接下来要说的就是CSRF。CSRF也是前端安全须要注意的一个重要的环节。

what

CSRF，跨站请求伪造（Cross Site Request Forgery）

简单来讲，我是A，其余站点好比B，伪装是A作来某件事情。

how

那么，请求是怎么伪造的呢？咱们来看下面这张图。

网站A：用户登陆，设置登陆信息到A的cookie

网站B：诱导用户打开网站B

网站B：页面发送来网站A的某个请求（可携带A的cookie），伪装是A操做（好比，删除一条数据）

网站A：数据被删除了！！！

why

为何呢？其实就是利用了请求的发送机制。

咱们知道cookie是绑定到域名上的，若是网站B请求了网站A的接口，那么请求是会携带网站A的cookie到网站A的服务器。

网站A收到请求以后，根据携带的cookie，就是认为是这条请求是受害者发送过来的。

固然，咱们都知道，受害者其实没有这个意思。

对cookie机制不了解的，能够看下楼主的文章 cookie & session

防范

讲到这，咱们应该都知道CSRF会让别人伪装我进行操做，那简直是太危险了，那么，咱们来看如下要怎么防范CSRF的发生。

验证码

验证码，咱们知道，CSRF就是在咱们不知情的状况下发送来请求，那么若是请求需求交互，就能够防范CSRF了。

固然，若是全部请求都要作验证码的话，用户估计不想用咱们的系统了，因此使用验证码的话仍是要谨慎。

referer校验

看一下掘金的http请求，会发现请求头会带有referer字段，referer字段是自动携带的，表示请求来源。

那么，咱们的接口能够作的处理就是对referer作一个校验，不容许的源不能进行操做，这样就能够阻止CSRF的发生啦。

不过referer校验也能够被绕过，若是用户发请求的时候，先用抓包工具改了referer参数，那么咱们作的操做就没有用了。

token校验

token校验，应该说是CSRF防范的业界标准了。

token校验要配合cookie进行处理，登陆的时候经过set-cookie，将一个sign保存在cookie中。

发送请求的时候，经过sign计算出token，而后再每条请求中携带token，服务器根据token进行校验，不经过就拒绝。

咱们看一下掘金页面发送的请求，请求都携带了token参数。

注意：因为token校验是基于cookie的，因此若是网站被XSS的话，token防范也会失效的，这个时候要解决的就是XSS问题了。

time33

上面讲到sign能够计算出token，那么到底怎么算了，业界经典就是使用time33。time33是一个字符串哈希函数。

function time33(sign) {
    let hash = 5381;
    for (let i = 0, len = sign.length; i < len; ++i) {
      hash += (hash << 5) + sign.charCodeAt(i);
    }
    return (hash & 0x7fffffff);
  }
复制代码

Q：为何叫time33

A：由于一直在乘33

Q：为何是5381

A：5381（001 010 100 000 101）听说hash后分布会更好

写在最后

CSRF的防范如今已经很完善了，接口作好配置，仍是能够很好防范的～