zzbozheng

2018-09-01 21:03

关于防CSRF你需要了解的另一种方法

本文作者:IMWeb zzbozheng 原文出处:IMWeb社区 未经同意,禁止转载

前言

网站通常会使用 cookie来记录用户的登录状态,但并非安全,因为 cookie被允许在第三方网站(也不仅限于第三方)发起的请求中携带,因此利用这一点可以达到 CSRF 攻击。本文不再对 CSRF 的原理作过多阐述,点击这里了解CSRF
如果别人问起防 CSRF 的方法有哪些,大家通常会说出:Token + Referer,该方案在业界已经非常成熟。当一个问题有了解决办法后,就很人有人会去了解别的方案,我想听听不同的声音。

有位社会人曾经说过:有趣的灵魂万里挑一。

本文给大家介绍另一种防 CSRF 的方法。

第三方请求

开始前我们先了解一下第三方请求,什么样的请求被称为第三方请求?简单来说就是在一个网页上发起一个不同源的请求,那么我们可以称为第三方请求。

在一个页面上发起一个第三方请求可以分为有 异步请求 和 同步请求:
1、异步请求 指的是在当前页面上通过 scriptlinkimgfetchXHR 等方法发起的请求,这些都不会让页面发生变化,也不会打开新的页面。
2、同步请求 指的是在当前页面点击 <a> 标签,或 <form>提交、 JS 调起的 location.hrefwindow.open() 等方式发起的请求,这些方式可能会使当前页面刷新或者打开新的页面。

通过 a.com 的页面发起 a.com 的请求,会带上第一方 cookie(first-party cookie)。
通过 a.com 的页面发起 b.com 或 c.com 的请求,会自动带上第三方 cookie(third-party cookie) CSRF 就是利用第三方请求会带上第三方 cookie的弱点来达到在一个不信任的域下也可以达到的危险操作。

关于SameSite

正如文章开头所说的防 CSRF 可以直接上方案 Token + Referer,但是人家 Google 就是要改变世界,怎么说? Google 提了一份草案 ,给 cookie新增 SameSite 属性,通过这个属性可以标记哪个 cookie只作为同站 cookie(即第一方 cookie,不能作为第三方 cookie),既然不能作为第三方 cookie,那么别的网站发起第三方请求时,第三方网站是收不到这个被标记关键 cookie,后面的鉴权处理就好办了。这一切都不需要做 token 生命周期的管理,也不用担心 Referer 会丢失或被中途被篡改。

SameSite 的应用

SameStie 有两个值:Strict 和 Lax:

SameSite=Strict

严格模式,使用 SameSite=Strict 去标记的 cookie在任何情况下(包括异步请求和同步请求) 都不能作为第三方 cookie。

SameSite=Lax

宽松模式,使用 SameSite=Lax 去标记的 cookie在异步请求 和 form 提交跳转的情况下 都不能作为第三方 cookie。

现在给 b.com 的 cookie bbb1 设置一波看看效果。

document.cookie="bbb1=1; SameSite=Strict";
document.cookie="bbb2=2; SameSite=Lax";
document.cookie="bbb3=3;";

注:为了代码简洁,这里就不再设置 domain,path,expires 什么的了。

设置完毕后,马上打开 Chrome 调试面板看看 cookie:

我们可以看到这里 cookie bbb1 的 SameSite 一列被设置了 Strict,bbb2 被设置了 Lax ,说明设置成功了。 在 a.com 页面中试着异步请求 b.com

// a.html
<img src="http://www.b.com" />

打开宇宙最强抓包工具 whistle 抓包看看 bbb1 和 bbb2 有没有被带到 b.com

我们可以看到 bbb1 和 bbb2 没有被带到 b.com ,只看到了 bbb3,很完美。

再看看同步请求:
这里在 a.com 页面上写了一个 <a> 标签。

// a.html
<a href="http://www.b.com"> open b.com </a>

通过抓包结果我们可以看到 bbb2 被 设置了 SameSite=Lax 后,在同步请求的方式下,是可以把 cookie bbb2 带到 b.com 的,而 bbb1 依然没有被带上。

Strict or Lax ?

那么问题来了,两种模式我们应该分别在什么场景下使用呢?

  • 登录态关键的 cookie都可以设置为 Strict。
  • 后台根据用户的登录态动态新建一个可以用于校验登录态的 cookie,设置为 Lax ,这样的话对外推广比如微博什么的,你希望用户在微博上打开你的链接还能保持登录态。
  • 如果你的页面有可能被第三方网站去 iframe 或 有接口需要做 jsonp ,那么都不能设置 Strict 或 Lax。
0条评论

    您需要 注册 一个IMWeb账号或者 才能进行评论。