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中的某些值和参数必须相等

posted @ 2022-07-06 18:24  爱吃_白菜  阅读(541)  评论(0)  编辑  收藏  举报