导航
导航
文章目录
  1. 什么是CSRF(跨站点请求伪造)
  2. CSRF进阶
    1. 浏览器Cookie策略
    2. 只有GET请求么?
  3. CSRF防御
    1. 验证码
    2. Referer Check
    3. Anti CSRF Token

Web安全之CSRF

前端面试过程中遇到的另一个最多的问题就是web安全了,之前博客有分享过XSS攻击的内容,这次聊聊CSRF攻击。CSRF是一种常见的攻击,但是也是web安全中最容易被忽略的一种攻击方式。

什么是CSRF(跨站点请求伪造)

根据字面意思,大概能猜到,CSRF攻击就是攻击者伪造了用户的请求,在用户不知道的情况下,以用户的名义向服务器发送恶意请求。常见的场景是,用户首先登陆一个正常(下面称为被攻击网站)的网站,攻击者诱使用户在不关闭被攻击网站的同时打开攻击者的页面,这时攻击者就可以以用户的名义给被攻击网站发送恶意请求了。可以看出CSRF是有条件的,首先用户要登陆被攻击网站,并生成Cookie,然后在不登出被攻击网站的同时,访问攻击网站。这两个条件缺一不可。

CSRF进阶

浏览器Cookie策略

CSRF之所以能成功,主要还是因为用户的浏览器成功发送了Cookie的缘故。浏览器所持有的Cookie分为两种:一种是“Session Cookie”,又叫“临时Cookie”;另一种是“Third-party Cookie”,也称为“本地Cookie”。
Third-party Cookie,服务器在Set-Cookie时指定了Expire时间,只有到了Expire时间后Cookie才会失效,而Session Cookie则没有指定Expire时间,浏览器关闭后就失效了。如果浏览器从一个域的页面中,要加载另一个域的资源,由于安全原因,某些浏览器会阻止Third-party Cookie的发送。由于新打开的页面和原来的页面在同一个浏览器进程中,所以Session Cookie将会被发送。

IE浏览器处于安全考虑是禁止浏览器在<img>、<iframe>、<script>、<link>等标签中发送第三方Cookie的。当前的主流浏览器中,默认会拦截Third-party Cookie的有:IE6~8、Safari,不会拦截的有:Firefox、Opera、Chrome等。

只有GET请求么?

在CSRF攻击流行之初,有一种错误的观点认为CSRF攻击只能由GET发起,这种错误观点的形成原因是大多数CSRF攻击发起时,使用的HTML标签都是<img>、<iframe>、<script>等带src属性的标签,这列标签只能够发起一次GET请求,而不能发起POST请求。然而,对于攻击者来说,有若干种方法可以构造出一个POST请求。最简单的方法就是在一个页面中构造好一个form表单,然后使用javascript自动提交这个表单。

1
2
3
4
5
6
7
8
9
10
11
<form action="http://www.a.com/register" id="register" method="post" accept-charset="utf-8">
<input type="text" name="username" value=""/>
<input type="password" name="password" value=""/>
<input type="submit" name="submit" value="submit"/>
</form>
<script>
var f = document.getElementById("register");
f.inputs[0].value = "test";
f.inputs[1].value = "passwd";
f.submit();
</script>

CSRF防御

验证码

验证码是对抗CSRF攻击最简单有效地防御方法。CSRF攻击往往是在用户不知情的情况下构造了网络请求。而验证码则强制用户必须与应用进行交互,才能完成最终请求。
但是验证码并不是万能的,我们不可能给页面的所有操作都加上验证码。

Referer Check

Referer Check在互联网中最常见的应用就是“防止图片盗链”。同理,Referer Check也可以被用于检查请求是否来自合法的源。

Anti CSRF Token

CSRF攻击存在的本质原因还是网页中重要操作的所有参数都是可以被攻击者猜测到的。攻击者只有预测出url所有参数与参数值,才能成功地构造一个伪造的请求。所以我们可以通过把参数加密,或者使用一些随机数,从而让攻击者无法猜测到参数值。
我们可以给请求新增加一个token,这个token值是随机的。

1
http://host/path/delete?username=abc&item=123&token=[random(seed)]

由于token的存在,攻击者就无法再构造出一个完整的url来实施CSRF攻击了。

本文总阅读量: