位置: IT常识 - 正文
Web系统常见安全漏洞介绍及解决方案-CSRF攻击(web系统的安全现状)
编辑：rootadmin推荐整理分享Web系统常见安全漏洞介绍及解决方案-CSRF攻击(web系统的安全现状)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:web系统常见安全问题包括,web系统的安全现状,常见的web安全及防护原理,web系统常见安全问题包括,web常见的安全问题,web常见的安全问题,web的安全,web系统的安全现状,内容如对您有帮助，希望把文章链接给更多的朋友！
🐳博客主页：拒绝冗余 – 生命不息，折腾不止 🌐订阅专栏：『Web安全』 📰如觉得博主文章写的不错或对你有所帮助的话，还望大家多多支持呀！ 👉关注✨、点赞👍、收藏📂、评论。
漏洞档案简介CSRF 攻击原理伪造GET/POST请求CSRF 蠕虫CSRF 防御1.验证码2.Referer Check3.使用token验证简介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 CheckReferer 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攻击。
上一篇：【JavaScript】手撕前端面试题：事件委托 | 判断URL是否合法 | 全排列(javascript手机上)
下一篇：OpenCV实战——多尺度FAST特征检测(opencvcuda)
