CSRF实操

网站：靶场
条件：注册两个账号，burp

---

原理

CSRF攻击攻击原理及过程如下：

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。

---

实操

1、注册两个账号后，个人资料显示不一样的数据
2、从中选一个账号，修改个人资料
3、burp抓包，点击确认修改

粘贴到网页则可以实现修改

可以看到修改前

修改后

证明存在csrf漏洞

---

进阶

入侵总不能让别人点按钮吧
所以修改一下
复制上面的网页代码
修改这段

变成

意思是：把需要点击按钮的操作变成直接调用函数
这么一来，别人一访问网站就已经被改变了信息

防御

参考李二大眼文章

1、判断请求头中的 Referer
这个字段记录的是请求的来源。比如 http://www.example.com 上调用了百度的接口 http://api.map.baidu.com/service 那么在百度的服务端，就可以通过 Referer 判断这个请求是来自哪里。

在实际应用中，这些跟业务逻辑无关的操作往往会放在拦截器中（或者说过滤器，不同技术使用的名词可能不同）。意思是说，在进入到业务逻辑之前，就应该要根据 Referer 的值来决定这个请求能不能处理。

在 Java Servlet 中可以用 Filter（古老的技术）；用 Spring 的话可以建拦截器；在 Express 中是叫中间件，通过 request.get(‘referer’) 来取得这个值。每种技术它走的流程其实都一样。

但要注意的是，Referer 是浏览器设置的，在浏览器兼容性大不相同的时代中，如果存在某种浏览器允许用户修改这个值，那么 CSRF 漏洞依然存在。

2、在请求参数中加入 csrf token
讨论 GET 和 POST 两种请求，对于 GET，其实也没什么需要防范的。为什么？因为 GET 在“约定”当中，被认为是查询操作，查询的意思就是，你查一次，查两次，无数次，结果都不会改变（用户得到的数据可能会变），这不会对数据库造成任何影响，所以不需要加其他额外的参数。

所以这里要提醒各位的是，尽量遵从这些约定，不要在 GET 请求中出现 /delete, /update, /edit 这种单词。把“写”操作放到 POST 中。

对于 POST，服务端在创建表单的时候可以加一个隐藏字段，也是通过某种加密算法得到的。在处理请求时，验证这个字段是否合法，如果合法就继续处理，否则就认为是恶意操作。

这个 html 片段由服务端生成，比如 JSP，PHP 等，对于 Node.js 的话可以是 Jade 。
这的确是一个很好的防范措施，再增加一些处理的话，还能防止表单重复提交。

可是对于一些新兴网站，很多都采用了“单页”的设计，或者退一步，无论是不是单页，它的 HTML 可能是由 JavaScript 拼接而成，并且表单也都是异步提交。所以这个办法有它的应用场景，也有局限性。

3、新增 HTTP Header
思想是，将 token 放在请求头中，服务端可以像获取 Referer 一样获取这个请求头，不同的是，这个 token 是由服务端生成的，所以攻击者他没办法猜。