http referer 验证防御方法_【知识点】5个防御CSRF的小技巧

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

作者：laobo

文章出处：WEB前端安全——XSS和CSRF

目录

• CSRF的危害
• CSRF具有的特点
• CSRF的防御

1 CSRF的危害

• 用户的登录态被盗用
• 完成业务的请求
• ......

2 CSRF具有的特点

• 伪造请求不经过网站A
• 伪造请求的域名不是网站A

3 CSRF的防御

因为伪造GET请求的难度比POST请求的难度小（打开一个URL或是请求一个资源便是一个GET请求），所以对于涉及业务操作的接口，尽量用POST请求，另外，CSRF的防御手段可以根据CSRF的特点来入手。

3.1 增加验证码

CSRF的一个特点是伪造请求不经过网站A,那么我们可以通过增加网站A的验证手段，例如增加图形验证码或短信验证码等等，只有通过验证的请求才算合法。但是这种方案拥有两个局限性，一个是增加开发成本，另外一个是降低用户体验。

3.2 cookies设置sameSite

对于CSRF的第二个特点伪造请求的域名不是网站A,那么通过限制cookies不被其他域名网站使用,来达到防御的目的，具体的做法是：

cookies设置sameSite属性的值为strict，这样只有同源网站的请求才会带上cookies。但是此方案有浏览器兼容问题。

3.3 验证referer

第二个特点同时会造成伪造请求的referer不是网站A，因此我们可以限制不信任的请求来源。具体做法是：

后端可以根据HTTP请求头的`referer`来判断请求是否来自可信任网站。但是这个方案也有局限性，攻击者可以设置请求不携带referer，所以这个方案适合用于辅助。

3.4 验证csrf token

这是目前相对成熟的方案之一，具体的做法是：

服务端随机生成token，保存在服务端session中，同时保存到客户端中，客户端发送请求时，把token带到HTTP请求头或参数中，服务端接收到请求，验证请求中的token与session中的是否一致。

这个方案适用于前后端不分离的项目和前后端分离的项目，对于前后端不分离的项目，token可以直接在编译模板的过程中写到表单的隐藏字段中，这样发送请求不需要额外的操作；而对于前后端分离的项目，token可以在登录时写入到cookies中，发送请求时，js读取cookies中的token，并设置到HTTP请求头中。

3.5 更换登录态方案

因为CSRF本质是伪造请求携带了保存在cookies中的信息，所以对session机制的登录态比较不利，如果更换JWT（JSON Web Token）方案，其token信息一般设置到HTTP头部的，所以可以防御CSRF攻击。

对于两种登录态方案的优劣，这里就不展开了。