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

willin 发布于2019-06-21 16:47 / 556人阅读

摘要：本文给大家介绍另一种防的方法。第三方请求开始前我们先了解一下第三方请求，什么样的请求被称为第三方请求简单来说就是在一个网页上发起一个不同源的请求，那么我们可以称为第三方请求。这一切都不需要做生命周期的管理，也不用担心会丢失或被中途被篡改。

前言

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

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

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

第三方请求

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

在一个页面上发起一个第三方请求可以分为有异步请求和同步请求：
1、异步请求 指的是在当前页面上通过 script、 link、img、fetch、XHR 等方法发起的请求，这些都不会让页面发生变化，也不会打开新的页面。
2、同步请求 指的是在当前页面点击标签，或

提交、 JS 调起的 location.href、window.open() 等方式发起的请求，这些方式可能会使当前页面刷新或者打开新的页面。

第三方cookie

通过 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

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

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

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

// a.html
 open b.com

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

Strict or Lax ?

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

登录态关键的 cookie 都可以设置为 Strict。

后台根据用户的登录态动态新建一个可以用于校验登录态的 cookie ，设置为 Lax ，这样的话对外推广比如微博什么的，你希望用户在微博上打开你的链接还能保持登录态。

如果你的页面有可能被第三方网站去 iframe 或有接口需要做 jsonp ，那么都不能设置 Strict 或 Lax。

GPU云服务器云服务器说说你所了解的人工智能外呼系统阿里云服务器你了解了吗人工智能一种现代方法人工智能一种现代的方法

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/11399.html

电商安全无小事，如何有效地抵御 CSRF 攻击？

摘要：与攻击相比，攻击往往很少见，因此对其进行防范的资源也相当稀少。不过，这种受信任的攻击模式更加难以防范，所以被认为比更具危险性。通过实时升级系统快速同步最新漏洞，避免零日攻击。现在，我们绝大多数人都会在网上购物买东西。但是很多人都不清楚的是，很多电商网站会存在安全漏洞。比如乌云就通报过，国内很多家公司的网站都存在 CSRF 漏洞。如果某个网站存在这种安全漏洞的话，那么我们在购物的过程中...

赵连江 2019-06-21 16:26 评论0 收藏0
提高NodeJS网站的安全性：Web服务器防黑客攻击技巧

摘要：尽管这样，我们还没有形成很多的安全准则。在这篇文章中，我会分享一些关于提高安全性方面的技巧。注跨站脚本攻击发生这种情况时，攻击者注入可执行代码的响应。这样可能会被跨站点脚本攻击。毫无疑问，Node.js现在是越来越成熟。尽管这样，我们还没有形成很多的安全准则。在这篇文章中，我会分享一些关于提高Node.js安全性方面的技巧。不用eval，赢得朋友你不仅仅要避免使用eval ...

waterc 2019-06-21 16:25 评论0 收藏0
总结 XSS 与 CSRF 两种跨站攻击

摘要：但最近又听说了另一种跨站攻击，于是找了些资料了解了一下，并与放在一起做个比较。脚本中的不速之客全称跨站脚本，是注入攻击的一种。 XSS：跨站脚本（Cross-site scripting） CSRF：跨站请求伪造（Cross-site request forgery）在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。...

jcc 2019-08-19 17:53 评论0 收藏0
干货分享｜安全测试起航之旅

摘要：众所周知软件测试分为四大类型，分别是功能测试自动化测试安全测试和性能测试，而安全测试是在功能测试和自动化测试之后，性能测试之前执行的，以免安全测试后修改的一些问题会影响性能。云智慧汪晓宇安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。一句话总结，安全测试就是检查产品是否满足安全需求的过程。众所...

Riddler 2019-05-29 16:58 评论0 收藏0