ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

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

2022-07-19 21:33:25  阅读:251  来源: 互联网

标签:Web 浏览器 请求 攻击 用户 Referer CSRF 安全漏洞


简介

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攻击。

转自:程序员 https://www.dianjilingqu.com/

标签:Web,浏览器,请求,攻击,用户,Referer,CSRF,安全漏洞
来源: https://www.cnblogs.com/yuanyuzhou/p/16495834.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有