csrf学习

跨站请求伪造

原理

利用受害者尚未失效的身份认证信息（cookie、会话等），诱骗其点击恶意链接或访问包含攻击代码的页面（钓鱼），在受害者不知情的情况下以受害者的身份向发送请求，从而完成非法操作。

CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全

与XSS最大区别就是csrf并没有盗取cookie而是直接利用

图里解释很清楚了，就不赘述了

还是老生常谈的银行转账的问题

已知受害者在银行以GET请求来完成银行转账的操作，http://www.mybank.com/Transfer.php?toBankId=11&money=1000

而攻击者构造的代码是

1	<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

当受害者登录银行，然后被钓鱼或是诱导点击了攻击者的链接，这样以GET的方式进行了转账操作

后面改进的示例就不列举了，大概总结就是$_REQUEST既可以获取get请求的数据，也可以获取post请求的数据，当后台使用$_REQUEST获取数据时还是存在无法区分

在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题

利用

最好是有目标站点的CMS，在本地搭建并构造一下例如创建管理员，开放权限等数据包，通过钓鱼等手段诱导管理员点击，执行数据包；要是没有目标站点的cms，也可以尝试抓包构造一下，不过有一定难度

总结

CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的

防御手段

Referer Check

验证http referer字段

referer就是记录了请求的来源（同源策略）

然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全

因为服务器并不是什么时候都能取到Referer，也可以通过抓包修改进行绕过，所以也无法作为CSRF防御的主要手段。但是用Referer Check来监控CSRF攻击的发生，倒是一种可行的方法