脚本宝典收集整理的这篇文章主要介绍了浅析CSRF攻击和防御，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

一、什么是CSRF攻击

CSRF是跨站点请求伪造(Cross—SITe Request Forgery)，跟XSS攻击一样，存在巨大的危害性。@H_126_15@

 

通俗理解：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

 

二、CSRF攻击如何产生

1、一个CSRF攻击需要2个条件：

1)登录了一个受信任的webA，并且本地存放了Cookie；

2)在不关闭A的情况下，访问了危险webB；

只要A网站没有做好相应的CSRF防护，满足这两个条件的用户就会中招，攻击者并不需要获取受害者的Cookie。

 

？问题：攻击者没有获取cookie如何利用cookie进行攻击？

cookie遵从SameSite，SameSite 可以有下面三种值：

• None。浏览器会在同站请求、跨站请求下继续发送 cookies，不区分大小写。

• Strict。浏览器将只在访问相同站点时发送 cookie。

• Lax。与 Strict 类似，但用户从外部站点导航至URL时（例如通过链接）除外。 在新版本浏览器中，为默认选项，Same-site cookies 将会为一些跨站子请求保留，如图片加载或者 frames 的调用，但只有当用户从外部站点导航到URL时才会发送。如 link 链接

如果 SameSite 属性没有设置，或者没有得到运行浏览器的支持，那么它的行为等同于 None，Cookies 会被包含在任何请求中——包括跨站请求。

 

*拓展：大多数主流浏览器正在将 SameSite 的默认值迁移至 Lax（如下图）。如果想要指定 Cookies 在同站、跨站请求都被发送，现在需要明确指定 SameSite 为 None。可以比较有效阻止跨站请求伪造攻击（CSRF）

  

 

 

2、攻击产生的本质原因

1）由于正常网站的WEB服务器验证不够严格：只验证了用户的SESSION存在，即为登录状态，且无法保证某一次请求一定为该用户发出的。

2）浏览器cookie不过期。

 

三、漏洞检测

 

抓取正常请求的数据包，如果不存在token验证，去掉请求头中Referer字段再重新提交，如果服务器返回正常页面，基本可以确定存在CSRF漏洞

 

四、防御CSRF之道

 

1、尽量使用POST

GET接口容易被人利用，仅需一个img标签，而img标签不能被过滤。

但POST也不是万无一失，攻击者可以构建一个form

 

2、加入验证码

因为攻击者是发出一个“伪请求”，所以在提交账号密码的时候可以让用户输入验证码，确保这是用户行为。

 

3、验证Referer

http请求首部字母段中，Referer能够记录当前请求中 URI 的原始获取方。

攻击者如果要对目标网站进行CSRF攻击，只能在自己的站点去构造请求，所以referer会记录到和当前站点不同的域名，在后端进行判断，可以直接拒绝来自不同域名的请求。

但在某一些浏览器中发送请求时可以篡改referer的值或者其他head的值，从而跳过验证继续进行CSRF攻击。

 

4、Anti CSRF Token

由于攻击者可以完全伪造用户请求，直接利用用户储存的cookie跳过验证。

所以防御的关键在 请求时攻击者伪造不了用户信息，且用户信息不能存储在cookie中。

 

综上：可以在http的form表单或者头信息（head）中传递随机产生token,将token存储在服务端,服务端通过拦截器验证token有效性，校验失败（如果请求中无token或者token错误）的拒绝请求。

 

5、加入自定义header

原理与第4点类似。

 

 附录

√视频：https://www.bilibili.COM/video/BV1iW411171s

√文章：https://xz.aliyun.com/t/8186

√进阶：https://xz.aliyun.com/t/7911

脚本宝典总结

以上是脚本宝典为你收集整理的浅析CSRF攻击和防御全部内容，希望文章能够帮你解决浅析CSRF攻击和防御所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。