Web系统常见安全漏洞介绍及解决方案-CSRF攻击

🐳博客主页：举杯同庆 – 生命不息，折腾不止
🌐订阅专栏：『Web安全』
📰如觉得博主文章写的不错或对你有所帮助的话，还望大家多多支持呀！ 👉关注✨、点赞👍、收藏📂、评论。

漏洞档案

简介

CSRF跨站请求伪造，全称Cross-site request forgery，是指利用受害者尚未失效的身份认证信息（cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，

在受害人不知情的情况下以受害者的身份向（身份认证信息所对应的）服务器发送请求

，从而完成非法操作（如转账、改密等）。CSRF是Web安全中最容易被忽略的一种攻击方式，但某些时候却能产生强大的破坏性。

CSRF 攻击原理

• 1用户打开浏览器，访问登陆受信任的A网站
• 2在用户信息通过验证后，服务器会返回一个cookie给浏览器，用户登陆网站A成功，可以正常发送请求到网站A
• 3用户未退出网站A，在同一浏览器中，打开一个危险网站B
• 4网站B收到用户请求后，返回一些恶意代码，并发出请求要求访问网站A
• 5浏览器收到这些恶意代码以后，在用户不知情的情况下，利用cookie信息，向网站A发送恶意请求，网站A会根据cookie信息以用户的权限去处理该请求，导致来自网站B的恶意代码被执行

伪造GET/POST请求

在CSRF攻击流行之初，曾经很多人认为CSRF只能由GET请求发起，因此很多开发者认为只要把重要的操作改成只允许POST请求就能防止CSRF攻击。
这种错误的观点形成的原因在于，大多数CSRF发起攻击时，使用的都是 //

在2007年Gmail CSRF漏洞攻击过程中安全研究者pdp展示了这个技巧：
首先用户需要登录Gmail账户以便获取Gmail的临时Cookie,然后攻击者诱使用户访问一个恶意页面，在这个恶意页面中隐藏了一个iframe,iframe的地址指向pdp写的一个恶意链接，这个链接的实际作用就是把参数生成一个POST表单并提交。pdp的攻击脚本会在邮箱的Filter中新建一条规则，把所有带附件的邮件都转发到攻击者指定的邮箱，由于浏览器中已经存在Gmail的临时Cookie，所以这个请求会成功。

CSRF 蠕虫

2008年9月百度曾经受到CSRF蠕虫病毒攻击，漏洞出现在百度用户中心的发送短消息功能中：

http://msg.baidu.com/?ct=22&cm=MailSend&tn=bmSubmit&sn=用户账户&con=消息内容

这个链接只要修改参数sn即可对指定的用户发送短消息，而攻击者发现另一个接口能查询出某个用户的所有好友，将两者结合起来，可以组成一个CSRF Worm-让一个百度用户查看恶意页面后，将给他的所有好友发送一条短消息，然后这个短消息中又包含一张图片，其地址再次指向CSRF页面，使得这些好友再次将消息发给他们的好友，这个Worm因此得以传播。

这个蠕虫很好的展示了CSRF的破坏性-即使没有Xss漏洞，仅仅是CSRF也是能够发起大规模蠕虫攻击的

CSRF 防御

下面看看有什么方法可以防御这种攻击。

1.验证码

验证码被认为是对抗CSRF攻击最简洁而有效的防御方法。
CSRF攻击的过程，往往是在用户不知情的情况下构造了网络请求，而验证码强制用户必须与应用进行交互才能完成最终请求。但是很多时候，出于对用户体验考虑，网站不能给所有的操作都加上验证码，因此验证码只能作为防御CSRF的一种辅助手段，而不能作为最主要的解决方案。

2.Referer Check

Referer Check即通过验证 HTTP请求头中的Referer 字段检查请求是否来自合法的“源”，检查Referer是否合法来判断用户是否被CSRF攻击。HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。比如一个发博客的操作，正常情况下需要先登录到发博客页面，提交“发布”的表单时Referer的只必然是发博客表单所有的页面，如果Referer的值不是这个页面，甚至不是发博客的域，则很有可能受到CSRF攻击。
Referer Check的缺陷在于，服务器并非什么时候都能够取到Referer，很多用户（或浏览器）出于隐私保护的考虑，限制了Referer的发送。

3.使用token验证

CSRF为什么能攻击成功？其本质原因时重要操作的所有参数都是可以被攻击者猜测到的。现在业界对CSRF的防御，一致的做法就是增加一个参数–Token。Token必须足够随机（使用足够安全的随机数生成算法），它应该作为一个“秘密”存在于服务器和浏览器中，不被第三方知晓。由于Token的存在，攻击者无法再构造出一个完整的url实施攻击。实际应用时，Token可以放在用户的Session或者浏览器的Cookie中，在提交请求时，服务器只需验证表单中的Token与用户传过来的Token(Session或Cookie中)是否一致，如果一致则认为是合法请求；如果不一致，则认为请求不合法，可能发生了CSRF攻击。