CSRF简析
csrf漏洞称为"跨站请求伪造",跟XSS一样，属于web攻击的一种，CSRF利用服务器对用户网页浏览器的信任，而XSS利用的是用户对网页,服务器的信任，要区分开
原理
攻击者构造一个特殊的网页或者url，发送给被攻击者，被攻击者打开后，会以被攻击者的名义向这个服务端发送一个恶意请求，但是这个请求在服务端看起来是完全合法的，从而处理了攻击者发送的恶意请求！
可以这样子理解：
用户A：正常用户
网站B：具有csrf的网站(http://127.0.0.1/shop.php?money=10000&name=用户D)
攻击C：攻击者
用户A登录了某个银行的界面,并且在本地保存了登录的cookie，打算转账给用户D10000元，此时攻击C也在这个网站中有账户，并且还发现了有CSRF漏洞，漏洞就在于
http://127.0.0.1/shop.php?money=10000&name=用户D
这一个url中，如果将name=用户D改成name=攻击C的话，然后将这个url的页面发送给用户A，如果服务端没有经过各种验证的话，就会直接相信这是用户A需要执行的转账操作，然后用户A在浏览器打开后，就会执行转账操作
利用条件
综合上述： 1.用户A需要登录进网站，并且保存Cookie 2.用户A点击恶意构造的连接 3.服务端没有任何防护
实例
靶机：DVWA
在左侧找到CSRF，然后点进去
原账户密码:
username:admin
password:password
这里的意思就是改密码，改了之后，当前账户的密码就更换了
更改后的账号密码:
username:admin
password:123
更改之后用admin:123重新登录
完了以后，抓包看看url构造
抓包或者在url地址栏，看到GET请求
http://xxxxxxxxx/vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change#如果我们将password_new=123&password_conf=123中的123改成其他的字符数字会不会更改密码？肯定会的啦
如果发动一波csrf攻击呢？看👇 如果要构造一个简单的界面你的话，直接写几句
<html>
<head></head>
<body
<a href='http://xxxxxxxxx/vulnerabilities/csrf/?password_new=hack&password_conf=hack&Change=Change#'>
点我</a>
></body>
</html>将password_new=123&password_conf=123改成password_new=hack&password_conf=hack，也就是说如果点击的话，密码就会变成hack 现在模拟"自己打自己"
打开创建好的html界面，然后点击"点我"，点了之后，如果你在之前已经登录了dvwa，就会直接跳转到
出现下面的password changed就意味着修改成功，现在logout重新登陆一下，用账号密码admin:123重新登录一下，发现已经报错"Login faild"，再用账号密码admin:hack试一下，发现可以登录...
这是一常见的csrf的漏洞利用方式，常见的还有转账，发邮件等操作
防御手段
回想一下CSRF攻击成功的前提本质是什么？
答：攻击者能猜测所有重要操作的参数!!!
比如说修改账号密码的一个URL：
http://xxx.xxx/xg.php?username=vfree&password=vfree如果要执行一个csrf攻击修改vfree的密码，只需要将password的参数修改即可
既然知道了参数是可以预测的，那么防御反其道而行之，就是添加一些攻击者无法预测到的参数 何谓反其道而行之呢?
- 验证码 验证码在一定程度上可以防御CSRF的攻击,也是最简单粗暴防御的方法，验证码是强制用户与页面进行交互操作，因此，在某种程度上，是可以起到一定的防御作用，但是还有值得考虑的一个问题是"用户体验"的问题，验证码如果遍布整站的话，必然会影响到用户对网站的体验效果,所以验证码依然是美中不足的一个效果
- Referer验证
来源页: 网站A：a.com 网站B：b.com 如果网站A接入了网站B的友情链接，那么如果有人从网站A访问网站B的话，Referer就会记录到来源页是网站A
Referer是head的一部分，用于记录来源页，常用于防盗链，如果针对csrf的防御的话，Referer也是起到可以在某种程度上的作用，通过判断Referer是不是来源于自己网站的域名，来判断是不是csrf攻击,如下就是示例代码:👇
<?php
$file = $_GET['filename'];
$referer = $_SERVER['HTTP_REFERER']; //接收Referer
if($referer!='http://vfree.ltd/'){ //判断Referer是不是来源于http://vfree.ltd/
die('referer not from vfree.ltd');
}else{
echo 'good';
echo file_get_contents($file);
}
?>以上只是示例代码，时间有限，不做深入研究，通过获取$_SERVER['HTTP_REFERER']来加入判断来源是否是vfree.ltd的网站，如果是，则继续执行接下来的操作，反之，直接die掉，模拟发送请求:
import requests
from requests.models import Response
url = 'http://127.0.0.1/ces.php?file=index.html'
head = {'Referer':'hacker'} # referer设置成hacker
response = requests.get(url,headers=head)
print(response.text)输出
referer not from vfree.ltd效果如此，通过判断referer也是不错，因为如果攻击者如果要发送csrf攻击，referer只能在自己的服务器上构造请求，于是，referer也指向了攻击者的服务器地址，即便如此，依然有不足之处，referer头是由浏览器提供的，就是服务器不是什么时候都能取到referer头，很多用户在出于隐私问题，都不会选择发送referer头，没有referer头发送至服务器，服务器可能就会判断这是csrf攻击，这么一来，用户体验不就不佳了么!处于以上种种原因，Check Referer头依然不是作为防御CSRF攻击的最佳方法
- Token 目前对付csrf攻击的最佳手段，非Token莫属了，Token简单来说就是临时令牌，csrf攻击本质是攻击者知道重要的操作参数才能成功~上面介绍了一种验证码的方式，但是碍于用户体验的原因，不是最佳的选择，Token的出现弥补了这一个短板，首先token无需与用户进行交互，完全是浏览器和服务器的事儿，用户基本上无需做什么来操作token。其次就是token是服务器产生的随机数，当用户发来请求后，会返回一个token，并且在session也会同时放置一个token，当用户在次需要进行操作请求时，会带上token，收到请求后，服务器会将token从session取出和请求带上的token进行对比，如果一致，则操作合法，反之，不合法！也因此，token在不影响用户的使用上，还可以有效阻挡csrf的攻击，一举两得！！！
部分图片源自于网络，如有侵权，请联系删除！！！谢谢