CSRF攻击

一、CSRF漏洞简介

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

二、CSRF攻击原理

  1. 用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;

  2. 在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;

  3. 用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B;

  4. 网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;

  5. 浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。

三、CSRF与XSS的区别

**XSS:**hack发现存在xss漏洞的网站—>制造payload—>将带有payload的网址发送给用户诱导点击—>执行payload获取黑客获取到敏感信息—>hack利用敏感信息进行操作数据修改

CSRF: hack发现存在CSRF漏洞的网站—>制造payload—>将带有payload的网址发送给用户诱导点击—>用户浏览了存在CSRF漏洞网站的情况下同时点击hack制作的payload链接,执行payload并且修改数据

**区别:**XSS是由hack诱导用户点击之后获取敏感信息,hack自己通过敏感信息进行下一步工具

**区别:**CSRF由hack构造payload诱导用户点击,用户点击的过程中同时浏览了存在漏洞的网站,由用户发起hack所制作的payload请求,修改信息

CSRF与XSS的区别:最大的区别就是CSRF没有盗取用户的Cookie,而是直接的利用了浏览器的Cookie让用户去执行某个动作。

四、防御CSRF攻击

CSRF的防御可以从服务端和客户端两方面着手,防御效果是从服务端着手效果比较好,现在一般的CSRF防御也都在服务端进行。
服务端的CSRF方式方法很多样,但总的思想都是一致的,就是在客户端页面增加伪随机数。

目前防御CSRF攻击主要有三种策略:

1.验证HTTP Referer字段;
2.在请求地址中添加token并验证;
3.在HTTP头中自定义属性并验证。

1) 验证header字段
常见的是Referer和Origin,Referer容易绕过,且会包含有一些敏感信息,可能会侵犯用户的隐私,而Origin字段代表最初请求,更建议使用。

根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。在通常情况下,访问一个安全受限的页面的请求都来自于同一个网站。比如某银行的转账是通过用户访问http://www.xxx.com/transfer.do页面完成的,用户必须先登录www.xxx.com,然后通过单击页面上的提交按钮来触发转账事件。当用户提交请求时,该转账请求的Referer值就会是
提交按钮所在页面的URL(本例为www.xxx. com/transfer.do)。如果攻击者要对银行网站实施CSRF攻击,他只能在其他网站构造请求,当用户通过其他网站发送请求到银行时,该请求的Referer的值是其他网站的地址,而不是银行转账页面的地址。因此,要防御CSRF攻击,银行网站只需要对于每一个转账请求验证其Referer值即可,如果是以www.xx.om域名开头的地址,则说明该请求是来自银行网站自己的请求,是合法的;如果Referer是其他网站,就有可能是CSRF攻击,则拒绝该请求。

2) Token令牌机制
当前最成熟的防御机制,但若存在验证逻辑及配置问题则存在绕过风险。Token的生成机制通常和session标识符挂钩,将用户的token与session标识符在服务端进行匹配。当下已经有很多开源库和中间件都可以实现token生成。

CSRF攻击之所以能够成功,是因为攻击者可以伪造用户的请求,该请求中所有的用户验证信息都存在于cookie中,因此攻击者可以在不知道用户验证信息的情况下直接利用用户的cookie来通过安全验证。由此可知,抵御CSRF攻击的关键在于:在请求中放入攻击者所不能伪造的信息,并且该信总不存在于cookie之中。鉴于此,系统开发人员可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务端进行token校验,如果请求中没有token或者token内容不正确,则认为是CSRF攻击而拒绝该请求。

token的值通过服务端生成,表单提交后token的值通过POST请求与参数一同带到服务端,每次会话可以使用相同的token,会话过期,则token失效,攻击者因无法获取到token,也就无法伪造请求。

3) 验证自定义header
如基于cookie的csrf保护,验证cookie中的某些值和参数必须相等

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
CSRF(Cross-Site Request Forgery)攻击又称为跨站请求伪造或者被动式攻击攻击者通过伪造合法用户的请求发送到Web应用程序,从而达到不正当的目的。攻击者通常需要诱导用户执行某些操作(如点击链接、访问网站等),以触发CSRF攻击CSRF攻击的工作原理是攻击者构造一个恶意请求,然后诱导用户访问带有恶意请求的页面。当用户访问该页面时,浏览器会自动发送请求到Web应用程序,由于请求中包含了用户的合法身份认证信息(如cookie等),Web应用程序无法区分该请求是否是用户本人的操作,从而执行了攻击者构造的恶意请求。 例如,攻击者可以在某个社交网站上发布一条欺骗性的链接,诱导用户点击该链接。当用户点击链接后,浏览器会自动向Web应用程序发送一条请求,该请求中包含了用户的身份认证信息和攻击者构造的恶意请求。由于Web应用程序无法判断该请求是否是用户本人的操作,因此会执行该恶意请求,从而导致CSRF攻击成功。 为了防止CSRF攻击,开发者可以采取以下措施: 1. 在关键操作(如修改密码、转账等)中增加CSRF令牌验证,确保请求是由合法用户发出的。 2. 对用户输入的数据进行有效的过滤和验证,避免恶意请求被执行。 3. 不要在GET请求中执行关键操作,避免恶意链接导致的攻击风险。 4. 使用HTTPS协议加密用户的身份认证信息,避免信息被篡改或窃取。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

huang0c

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值