一： 概述
跨站请求伪造（cross site request forgery,csrf）是一种攻击，它强制终端用户在当前对其身份验证后的web应用程序上执行非本意的操作。
可以这么理解：CSRF是跨站点请求伪造(Cross—Site Request Forgery)，跟XSS攻击一样，存在巨大的危害性。
攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
在网上找到了一张很好理解的图：
CSRF攻击的着重点在伪造更改状态的请求，而不是盗取数据，因为攻击者无法查看对伪造请求的响应。借助社工的一些帮助（例如通过电子邮件或聊天发送链接），攻击者可以诱骗用户执行攻击者选择的操作。如果受害者是普通用户，则成功的CSRF攻击可以强制用户执行状态更改的请求，例如转移资金，更改其电子邮件地址等。如果受害者是管理账户，CSRF可能会危及整个web应用程序。
?
XSS与CSRF的区别：
XSS： XSS漏洞——构造payload——发送给受害人——受害人点击打开——攻击者获取受害人的cookie——攻击者使用受害人cookie完成攻击
CSRF： CSRF漏洞——构造payload——发送给受害人——受害人点击打开——受害人执行代码——受害人完成攻击（不知情）
?
二：关键点
CSRF是一种欺骗受害者提交恶意请求的攻击。它继承了受害者的身份和特权，代表受害者执行非本意、恶意的操作。对于大多数站点，浏览器请求自动发送与站点关联的所有凭据，例如用户的会话cookie，IP地址，Windows域凭据等。因此，如果用户当前已对该站点进行了身份验证，则该站点将无法区分受害者发送的伪造请求和受害者发送的合法请求。
?
?
三：目标
CSRF攻击目标是能够更改服务器状态或数据的业务或功能，例如更改受害者的电子邮件，密码或购买商品。强制受害者查询数据，对于攻击者来说没什么用，因为无法获得服务器响应。因此，CSRF攻击针对引起状态变化的请求。
有时可以将CSRF攻击存储在易受攻击的站点上。这些漏洞被称为“存储的CSRF漏洞”。这可以通过简单的在接受HTML的字段中存储IMG或IFRAME标记，或通过更复杂的跨站点脚本攻击来实现。如果攻击可以在站点中存储CSRF攻击，则攻击的严重性会被放大。特别是受到攻击的可能性增加，因为受害者比互联网上的某个随即页面更有可能查看包含攻击的页面。
?
?
四：CSRF攻击如何触发？
1、<a href="转账连接">大爷来玩呀</a>
2、<img src=""> 利用src的链接
?
五：实战：CSRF场景复现
需要一个bank网站源码，很可惜没得源码。
以下为视频部分截图
首先开启一台虚拟机，（视频中的IP地址：172.16.132.161，这是银行自身的）把bank这个文件夹放到phpstudy/www目录下。
里面有个config.inc.php文件，这是关于数据库的配置
需要一个bank的数据库，那么怎么用phpstudy来部署一个bank数据库呢？
确保bank文件夹下有bank.sql文件
登录 admin/123456
然后用另一个浏览器登录另一个账号，test/123456
让test对admin进行转账操作，发现转账成功。
再用另一个浏览器登录hacker账号 hacker/123456
然后启动另一台虚拟机（视频中ip为172.16.132.131，这是攻击者搭建的），在phpstudy/www目录下有个CSRF文件夹，
这是csrf/get.html源码内容
要完成攻击过程需要四个角色：server，被攻击者，攻击者，hacker_server
给张图便于理解
各个页面的登录均用具体的IP，不要用127或者localhost
在172.16.132.161的虚拟机上用浏览器登录admin账号：
再没有安全退出的情况下，访问了不明网站，比如172.16.132.131，如下图，点击了点击就送
然后切回自己的admin界面，然后发现账户余额少了钱。
此时，我们进入黑客登录页面，刷新一下，账户余额增加了
那为什么会出现这种情况呢？
一般完成转账需要三个角色，原账户，目标账户，转账金额。但是上图只有目标客户和转账金额，原账户是以cookie的方式存在的。
虽然浏览器是131网址，但是有重定向到161地址，那么存在161地址的cookie就会转移到这里来。
?
以上场景中是利用img标签发送的get请求。那么是不是把关键操作使用post请求，就能够防御CSRF漏洞了呢？答案是否定的。
post方式：
即使转账操作使用Post方法，攻击者也可以通过构造表单的方式来伪造请求，核心代码如下：
<meta charset='utf-8'>
<form name='csrf' action='http://172.16.132.161/bank/action.php' method='post'>
<input type='hidden' name='username' value='hacker'> // hidden隐藏的标签
<input type='hidden' name='money' value='1000'>
</form>
<script>document.csrf.submit()</script>
<img src="./1.jpg"><br />
<!--<a href='javascript:document.csrf.submit()' style='color:red;font-size:100px'>倚天不出，谁与争锋</a> <br />
此处可以利用JS来自动提交隐藏的表单，但是页面会跳转到self.php并且显示转账记录。这看起来就不是那么“友好”了。
那么，有没有办法做到“不知不觉”呢？
实战：与XSS的结合添加后台账号，攻击者可以通过XSS来触发CSRF攻击，就不需要搭建服务器了。因为可以利用JS来发送请求。
通过研究受害网站的业务流程，攻击者可以构造如下代码。（把以下代码插入cms系统的留言板）
<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open(\'post\',\'http://172.16.132.161/cms/admin/user.action.php\',false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send(\'act=add&username=hacker&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0\');
</script>
然后在后台管理就可以通过hacker/123456登录后台
?
六：CSRF防御
6.1 无效的防御
很多防御方式都没有办法解决CSRF的问题。
1、使用秘密cookie
所有的cookie，即使是秘密的cookie，也会随着每个请求一起提交。无论最终用户是否被欺骗提交请求，都将提交所有身份证令牌。
2、仅接受POST请求
可以开发应用程序以仅接受用于执行业务逻辑的POST请求。误解是由于攻击者无法构建恶意链接，因此无法执行CSRF攻击。不幸的是，这种逻辑不正确。
有许多方法可以让攻击者欺骗受害者提交伪造的POST请求，例如在隐藏值的攻击者网站中托管的简单表单。此表单可以由javascript自动触发，
也可以由认为表单会执行其他操作的受害者触发。
3、多步交易
多步交易不足以预防CSRF。只要攻击者可以预测或推断完整的事务的每个步骤，就可以实现CSRF。
4、URL重写
这可能被视为一种有用的CSRF预防技术，因为攻击者无法猜测受害者的会话ID，但是，用户的会话ID在URL中公开，
所以不建议通过引入另一个安全漏洞来修复一个安全漏洞。
5、HTTPS
https本身无法防御CSRF。但是，https应被视为任何预防措施值得信赖的先决条件。
?
6.2 有效的防御
1、验证referer字段
根据HTTP协议，在http头中有一个字段叫referer，它记录了该http请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自同一个网站。
比如某银行的转账是通过用户访问http://172.16.132.161/bank/action.php?username=hacker&money=1000&submit=%E4%BA%A4%E6%98%93 页面完成，
用户必须登录，并且访问，http://172.16.132.161/bank/index.php ，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的
referer值就会是转账按钮所在页面的URL。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求
到银行时，该请求的referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求，验证其referer值，如果是以172.16.132.161
的地址或域名，则说明该请求是来自银行网站自己的请求，是合法的。如果referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。
但是referer也是可以修改的，功与防无时无刻不在互相斗争。。
2、添加Token验证
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于cookie中，因此攻击者可以在不知道这些验证信息的
情况下直接利用用户自己的cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于cookie之中。
鉴于此，系统开发者可以在http请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token
或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
3、二次验证
二次验证，就是在转账等关键操作之前提供当前用户的密码或者验证码。二次验证可以有效防御CSRF攻击。
4、用户养成良好的习惯
对于普通用户来说，多学习并具备网络安全知识以防御网络攻击是不现实的。但若用户养成良好的上网习惯，则能够很大程度上减少CSRF攻击的危害。例如，用户上网时，
不要轻易点击网络论坛，聊天室，及时通讯工具或者电子邮件中出现的链接或者图片，及时退出长时间不使用的已经登录的账户，尤其是系统管理员，应尽量登出系统的
情况下点击未知的链接和图片。除此之外，用户还需要在连接互联网的计算机上安装合适的安全防护软件，并及时更新软件厂商发布的特征库，以保持安全软件对最新攻击的实时跟踪