CSRF浅谈

一个简单的问题，你能借助CSRF漏洞干什么呐？

0x00 CSRF漏洞？

CSRF（全称：Cross Site Request Fogery，跨站请求伪造），顾名思义，黑客伪造了一个可以发起请求的页面，正好你访问了，还带上了一些cookie信息（身份信息），该页面就会向目标站点发起请求，发起的请求操作等同于本人去发起的请求，例如转账啊、修改资料等等

例如小王在登录了“XX网银”后，突然发现一个小广告，内容很诱惑，因此你忍不住点进去了，然后五分钟后舒服了…回来看自己的“XX网银”账户居然没钱了！！！

想到我也看过这个XX广告，立马看了看自己的XX网银，还好我没钱！

0x01 如何检测CSRF漏洞是否存在？

借助BurpSuite，抓包后，去除HTTP头中的Referer字段，看看某些涉及到“增删改查”的操作是否还能正常执行，如果正常执行，那么就存在CSRF漏洞。

另外还可以借助BurpSuite上的Engagement tools –> Generate CSRF PoC功能，来生成CSRF POC，验证是否存在该漏洞

与此同时，可以借助CSRFTester工具来检测

0x02 如何防御？

CSRF就是一种欺骗了服务器的漏洞，本来应该是A网站前端向A网站后端服务发起请求的，结果在B网站前端向A网站后端发起请求，结果也能执行成功！

针对CSRF漏洞，目前主流处理方式：

• 请求操作验证Token
• 校验Referer
• 自定义HTTP头中一些值

那么，在这个过程当中，主要三个步骤：

1. 发起正确的请求
2. A服务器接受请求
3. A服务器处理并返回结果

那么，我们需要针对如上三个步骤来

步骤一当中，由于HTTP是无状态，所以就依赖于cookie和session来确认用户身份，在一个所以请求当中必定需要带上身份信息

这些cookie，由于浏览器的同源策略，所以就存在同源CSRF和跨域CSRF两种

针对步骤一，随机生成一个强token到页面中，每次操作请求都需要带上Token，Token每次执行完或没执行，刷新后都需要更新并销毁之前的session

针对步骤二和三，服务器需要判断Referer来源，确保是用户在当前站点发出的请求，与此同时，保证该站点不存在XSS之类的漏洞，对于用户内容输出的地方做好HTML实体编码以及，在步骤三处理请求过程中，首先需要校验的是Token或者自定义的一些属性，校验不通过则返回错误信息，并且终止后续逻辑，同时还要销毁原有效token，再生成新的token，也需要保证Token的强度

0x03 总结

CSRF常用利用场景包括请求伪造、Hijacking、蠕虫等等，至于想要扩大战果，隐式地长线钓大鱼就好了~