Pikachu：CSRF（跨站请求伪造）

Posted 2021-03-03 fhbbs

CSRF(跨站请求伪造)概述

　　Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
　　这里列举一个场景解释一下，希望能够帮助你理解。
场景需求：
　　小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。
　　先看下大白是如何修改自己的密码的：
　　登录---修改会员信息，提交请求---修改成功。
　　所以小黑想要修改大白的信息，他需要拥有：1，登录权限 2，修改个人信息的请求。
　　但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
　　于是他自己跑到www.xx.com上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：
　　【http://www.xxx.com/edit.php?email=[e-mail]&Change=Change】
　　于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
　　为啥小黑的操作能够实现呢。有如下几个关键点：
　　1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
---因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
　　2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
　　---如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
　　---因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做： 欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
　　---所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
　　--对敏感信息的操作增加安全的token；
　　--对敏感信息的操作增加安全的验证码；
　　--对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。

CSRF(get)

　　当然，我们得先登录，在右侧的提示给出了几个用户，根据那几个用户进行登录：

 

 

 

 　　登陆了之后，用户现在更改用户信息时，我们就可以抓到它的包，然后修改其中的内容，毫无疑问我们需要Burp Suite。点击修改个人信息：

 

 　　修改完成后不要点击submit，进行代理，打开Burp Suite，然后点击submit，再看Burp Suite，已经抓到了包：

 

 　　我们从提交的请求来看，后台没做CSRF token（令牌）防御，同时也是通过GET请求来提交修改信息，我们拿到这个，修改一下，然后让lili点击就好，我们构造的URL中把地址china改为England，lili一点击就修改了地址：

　　切记！！此处一定要把选中的内容复制，这是我们伪造链接的关键步骤。然后点击Forward发送数据包。之后伪造连接就是将上图中的复制的内容，在前面加上我们攻击者的ip：

　　http://192.168.1.4/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18656565545&add=England&email=lili%40pikachu.com&submit=submit HTTP/1.1

　　解除代理，lili点击了这个链接以后，我们看到地址已经被改为England：

　

　　这个看似很厉害，但是实际上满足条件比较严苛，比如lucy必须是登陆状态，而且防范意识较低，才可以。

　　另外这个与反射型的XSS也不同，CSRF与XSS的区别是，CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。

CSRF(post)

 　　登录，我这里还是登录lili，我们把住址修改为post，抓包发现post型并没有显示url中，是以form表单的请求提交：

　　Post型的不能通过伪造url来进行攻击，跟xss里post型是一致的。攻击者搭一个页面，诱导用户点进来，当用户点击时会自动向存在csrf的服务器提交post请求来修改个人信息。我们这里编写一个post.html页面，将这个页面放在放到 pikachu-master/vul/csrf/csrfpost/ 路径下，然后启动 apache 服务（phpStudy中启动的服务中就包括Apache服务）：

post.html内容

 

 

 　　上图中action中的内容就是链接：

　　http://192.168.1.4/pikachu-master/vul/csrf/csrfpost/csrf_post_edit.php

　　lili点击链接，然后发现跳转页面，住址已经被修改为post：

 

CSRF(Token)

　　CSRF的主要问题是敏感操作容易被伪造，加入Token会让请求不容易被伪造，每次请求，都增加一个随机码，随机生成，无法预测没有规律，后台每次对这个随机码进行验证，正确才能进入，类似于验证码，但是无需我们自己输入。

　　进入Pikachu平台的CSRF（token）页面并登录，修改个人信息，把地址修改为token：

 

 　　设置代理，点击submit用Burp Suite抓包，看看包里面的数据状态，我们发现有token生成，由于token是随机的，我们就无法伪造URL了。所以我们没办法入侵：

 

 　　我们看一下后台的源码（路径如下）：

 

 

 　　每次点击修改个人信息 都会去访问 token_get_edit_.php 这个文件，这个文件就会生成一个token，value就是后端发过来的，type是隐藏的，在前端看不到，但是在源码中能看到。每次点提交，token也会被提交到后台，后台会对token进行验证，如果和当前session里面的token相等，才会让你提交。

常见的CSRF防范措施

1、增加token验证（常用的做法）

    对关键操作增加token参数，token值必须是随机的，每次都不一样

2、关于安全的会话管理（避免会话被利用）

（1）不要再客户端保存敏感信息（比如身份认证信息）；

（2）测试直接关闭，退出时的会话过期机制；

（3）设置会话国企机制，比如几分钟内误操作，自动登陆超时。

3、访问控制安全管理

（1）敏感信息的修改时需要对身份进行二次认证，例如:修改账号时，需要验证旧的密码。

（2）敏感信息的修改使用POST，而不是GET

（3）通过http投不中的referer来限制原页面。

4、增加验证码：

    一般用在登陆（防暴力破解），也可以用在其他重要信息操作的表单中（需要考虑可用性）