CSRF攻击

CSRF攻击原理

---

什么是csrf？

CSRF（Cross-site request forgery）跨站请求伪造：也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

其实说白了，csrf漏洞的成因就是网站的cookie在浏览器中不会过期，只要不关闭浏览器或者退出登录，那以后只要是访问这个网站，都会默认你已经登录的状态。而在这个期间，攻击者发送了构造好的csrf脚本或包含csrf脚本的链接，可能会执行一些用户不想做的功能（比如是添加账号等）

举例说明

银行网站A，它以GET请求来完成银行转账的操作，如：http://xxx.xxx.xx.xx/xxx.php?id=11&money=1000

　　危险网站B，它里面有一段HTML的代码如下：

　　<img src=http://xxx.xxx.xx.xx/xxx.php?id=11&money=1000>

　　首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

　　为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的<img>以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://xxx.xxx.xx.xx/xxx.php?id=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......

csrf危害

攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

csrf一般存在平行权限中，因为高权限的可能页面不太一样

在举个例子。比如一个网站平台，客户可自行注册用户，注册完成如果修改密码页面未对旧密码进行验证，且该页面input框未添加token也就是说存在csrf漏洞，那么我们可以注册一个同权限用户，构造一个csrfpoc，把他隐藏在一个其他人也可以访问到的页面上，然后诱导其他人去方位这个页面，如果访问了，那么他的密码就已经被修改了

CSRF挖掘

---

检测CSRF漏洞是一项比较繁琐的工作

最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder等。

以CSRFTester工具为例，CSRF漏洞检测工具的测试原理如下：使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。

 

抓包查看是否存在token值，抓包工具可以使用burp，在burp中也可以直接生成csrfpoc进行测试

与XSS的区别

---

从漏洞存在的位置上（CSRF存在于所有请求-响应模式的功能上，XSS存在于将用户输入回显前端web页面的位置上），从攻击效果上（CSRF主要是执行网站自身已有功能，XSS主要是用于获取Cookie）都有区别。

但对于初学者最直接的还是利用角度。当时面试说的是CSRF是利用B网站攻击A网站，XSS（反射型）是将A网站的Cookie发到B网站，这理解是没错的。这里再举个例子更具象化地说明：

CSRF防御

---

Referer头检测法 

Referer标识当前请求的来源页面，浏览器访问时除了自动带上Cookie还会自动带上Referer，所以服务端可以检测Referer头是否本网站页面来决定是否响应请求。

Referer是浏览器自动带上的，基于认为浏览器没有相关漏洞的前提下，我们可以认为攻击者是没法伪造Referer头的，也就是检测Referer头的方法是可靠的。

但该方式有时会不受认可，一是因为浏览器是可以设置禁止发送Referer头的，如果使用该方式那么禁止Referer头的浏览将无法正常使用，这可能会降低用户使用体验。二是因为由于移动端的崛起当下流行前后端分离app和web共用一套后端代码，但app是不会自动带Referer头的，如果使用该方式app端不好处理。

token检测法

token就是服务端返回给客户端类似sessionid那样一长串的类值（长是为了防暴力猜解）。csrf依赖于浏览器该问链接时自动对应网站的cookie带上，token不放cookie（一般form表单加个hidden属性的input标签来存放）csrf就没法获取token，这样我们就可以通过检测发送过来的数据包中是否有正确的token值来决定是否响应请求。

在讲清token防御的原理后，我们再来讲token的设计，因为token方式给人的感觉很复杂令人望而生畏。

我们首先明确一个问题，就是能够防止csrf攻击的token，并不需要每次请求都不一样，在用户登录后到退出前的这整个过程中的所有请求token完全可以是一样。因为（在基于没有其他漏洞会泄漏本次会话的token的设想下）黑客是无法获取用户的tokne，所以又何必每个请求都要生成一个新的token呢。（token每次请求都要不一样的想法是受防重放攻击的影响）只考滤防csrf不考滤防重放的情况下，token设计就简单多了。

使用sessionid作为token设计：在csrf中cookie是浏览器自己带上的，本质而言用户的sessionid并未丢失（也就是攻击者并不能知道sessionid是多少），基于此我们完全可以不用另传一个值只需直接将sessionid作为token即可（或者也可以做些运算比如取sessionid的某些值做个md5来做为token，意思都差不多）。判断代码类似 if session["id"] == $_POST["token"]

与sessionid同时返回的token设计：在生成sessionid的同时生成一个token（服务端token可以存于session变量中）返回给客户端，客户端保存该token每次请求时都在form表单中提交该值。判断代码类似if session["token"] == $_POST["token"]

注意项 

reffer作为header字段是可以伪造的；

origin作为header的字段同样可以伪造。没有在预防XSS攻击的基础上做CSRF防御没有任何意义；

一般使用token防御就可以了

参考

---

参考书籍：《Web应用安全权威指南》

参考文章：https://www.cnblogs.com/lsdb/p/9591399.html

参考文章：https://www.cnblogs.com/liurwei/p/9572136.html

参考文章：https://www.cnblogs.com/shikyoh/p/4959678.html