「 Security 」 WEB安全(二)之图解 CSRF 注入

CSRF 攻击的原理

CSRF 攻击，英文全称就是 Cross Site Request Forgy，意思就是跨站伪造请求。CSRF 简单来说就是利用站点对用户的信任信息伪造一个用户的请求，去请求这个信任站点进行非法的操作。

CSRF 的破坏力主要是看被攻击者的权限，如果被攻击者权限非常小那最多也就是影响一些用户的数据或者功能，比如在某个地方插入了一些乱码或者是插入一些非法的图片。如果被攻击的权限是管理员权限，那影响将会很大甚至直接影响到了整个站点的安全，比如盗取用户数据库或者是触发交易逻辑从而导致资金损失。

CSRF 的危险性要比 XSS 更高一些，因为他会更加的难以防范。

在今天的浏览器，都是可以支持多开窗口的，既然支持多开就说明可能会同时的登录了几个站点，那么，这个就可能有 CSRF 的攻击风险。这里有个小技巧，就是不要只使用一个浏览器，用一个浏览器专门用于访问重要网站，另一个浏览器专门用于网上冲浪，这样就可以避免 session 共享的问题。换句话说就是再开个小号去 “ 玩 ”。

CSRF 攻击原理

他的攻击原理就是将一段非法的连接地址以某种方法发送给用户，诱因用户点击，而点击这个是会向另一个接口发送请求信息，在不知不觉中就暗中进行了一些敏感的操作。

攻击流程如下图：

• A/B：A 和 B 表示是正常的用户和站点之间的通信。
• C： 黑客发出了带有恶意脚本的链接伪装成一个图片或者文字。
• D：用户被这个图片或者文字所吸引，同时对她进行点击操作。
• E：在点击了这个链接之后，恶意脚本执行请求了 website 站点伪造用户请求。

CSRF 攻击的特点

CSRF 的攻击最大的特点就是利用了用户的身份信息，在用户毫不知觉的情况下进行一些非法的操作。但是这里面也有个前提，即将被攻击的网站是需要用户登录过的，也就是用户已经有了登录信息的情况下。

CSRF 攻击的防御

same-site

same-site，顾名思义就是只允许统一站点的 cookie ，话句话说就是禁止第三方的 cookie 从而减少安全风险。他的处理方法就是在设置 cookie 的时候加上 same-site 这个属性 。

这个方法是可以防御 CSRF ，但是，same-site 这个方法有兼容性问题，这个属性最开始是在谷歌浏览器 51 版本上新增的，能够支持的比较好的就是谷歌浏览器自己。所以，并不是一个比较好的解决 CSRF 攻击的问题。

referee

referer 是 HTTP 协议的请求头，里面的信息是请求源地址信息，而需要做的就是验证 referer 的地址是不是当前域，如果不是就拒绝，意思就是禁止第三方网站的请求，从而阻止 CSRF 的攻击。

这个地方需要注意一点的是，对于 referer 的校验最好是使用正则比较严谨的方法校验，是因为 referer 是一段网址，判断是否来自某个域就是判断时候包含某个域名信息，例如：

referer = "www.ke.com";
referer.indexOf('www.qq.com') > 0 ;
// false

上面的方法显然是可以，但是如果地址稍微变化一下

referer = "www.ke.com?id=www.qq.com";
referer.indexOf('www.qq.com') > 0 
// ture

很明显这样就出问题了，所以必须使用正则校验的方法验证：

let referer = "www.ke.com?id=www.qq.com";
let Reg = /^https?:\/\/www\.qq\.com/;  
Reg.test(referer) 
// false

这样才能正确的校验 referer ，但是有些场景下的跳转是不带有 referer 的或者是这个 referer 是允许发送的等等情况综合，一般也不以 referer 来校验是否合法请求。除非有些业务是纯内部或者是使用范围比较小的，那就可以考虑用这个方法。

验证码

前面提到了 CSRF 的攻击特点就是利用用户的登录信息在用户完全不知觉的情况下进行非法操作。而使用验证码这个东西的目的就是要验证该操作是否是用户操作。

以图形验证码为例，他的实现原理就是前端引入 SDK 生成一段规则，然后用户通过某种方法去进行操作，操作完成之后若符合操作条件就根据规则生成一段验证码。

这一段的验证码是会在下一次的请求中带上一起发给后端。后端在接收到请求的第一件事就是校验验证码的正确性。如果匹配则说明操作合法向下执行，若不匹配或者为空，就说明这是一个非法操作直接拦截。流程如图：

• A：用户访问 website 发送请求
• B：在某种条件下触发了图形验证
• C：在前端界面完成指定的校验操作
• D：下一次请求请求中带上验证码给服务器校验

另外一个注意点是，上面说的在某种条件下出发是因为图形验证码一般不会每次都出现，因为这个对用户的体验是在太差，所以一般都是后台有自己的一套判断规则，比如这个ip请求的比较频繁或者是多次请求登录，这个时候判断为异常操作触发验证码逻辑。

我记得以前做 h5 活动的时候，其中一个活动中页面有个按钮涉及到了给作品加分的操作，按理说应该给这个按钮设定一个最高级别的图形校验，但是产品同学却建议不要设定的太高。因为加上了最高级别的图形校验就意味着出现图形校验的概率变高，流失率也就越大。

在大厂里这个验证码组件这个东西都不需要 WEB 端的同学去开发，是由一些公司级基建相关的部门进行研发，比如像腾讯最为常见的 WEB QQ登录，登录时有时候会出现一个要求向右拖动小方块的过程，这个就是他们自己的防水墙。

如果想要了解一下整个过程，可以去程序员的后花园（npmjs）上面随便找一个，然后本地运行个简单的服务器安装试试。刚刚搜了一下，貌似下面这个还行，emm，虽然没用过

token

token 这个方法就会比图形验证码的体验效果要好一点，首先，它由后端生成一段加密过后的字符串，之后将这个字符串写进 cookie 和页面的某个位置表单域或者http头自己定义的属性里面，在提交数据的时候会从页面的某个位置取出一起随 form 和 cookie 到达后台，后台把这两段数据进行对比，通过了才算合法操作。

也可以说是在用户登录验证通过后，由服务器下发的 token 是一个身份令牌，这个是给用户的一个身份标记。每一次的请求都是会带上这个ID。

需要注意的就是，这两段数据缺一不可，必须两个都同时存在，缺少某一个都会认为是非法操作。

这个方法看似就解决了这个问题，但是再考虑一种情况，浏览器是可以多开的，如果浏览器同时多开了相同的页面，那么这几个页面只有最新的那个 token 才是有效的，因为他们会把之前的覆盖。

有更简单的方法，那个就是 CSRF Guard ，可能现在会有更好的方法，这个就不在这个进行描述了。

以上就是关于 CSRF 的介绍。

-----

免辣的毛血旺和加糖的冰美式都是没有灵魂的。