标签：CSRF Pikachu 修改 token csrf 靶场 大白 请求
Pikachu靶场-csrf
跨站请求伪造目录
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=xiaohei@88.com&Change=Change】
于是，他实施了这样一个操作：把这个链接伪装一下，在大白登录xxx网站后，欺骗他进行点击，大白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
—因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
2.大白点击了小黑发给的链接，并且这个时候大白刚好登录在购物网上;
—如果大白安全意识高，不点击不明链接，则攻击不会成功，又或者即使大白点击了链接，但大白此时并没有登录购物网站，也不会成功。
—因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做： 欺骗大白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，大白中招，小黑拿到大白的cookie，然后小黑顺利登录到大白的后台，小黑自己修改小白的相关信息。
—所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
CSRF漏洞测试流程
通过上面这个例子来看，我们判断一个网站是否存在CSRF漏洞
1，对目标网站增删改的地方进行标记，并观察其逻辑，判断请求是否可以被伪造—比如----修改管理员账号时，并不需要验证旧密码，导致请求容易被伪造;
—比如对于敏感信息的修改并没有使用安全的token验证，导致请求容易被伪造;
2.确认凭证的有效期(这个问题会提高CSRF被利用的概率)
—虽然退出或者关闭了浏览器，但cookie仍然有效，或者session并没有及时过期，导致CSRF攻击变的简单
CSRF演示
csrf（get）
首先，我们来登录一下它给的账号
这个样子
接着，我们修改他的地址为china，提交
我们发现，他的地址已经被修改
那么，我们如何判断这边存在csrf漏洞呢
我们用burp抓到的包来看一下
这个get请求实际上是向后台发送了所有的参数
在这里我们没有发现csrf 的 token
说明就是没有做防csrf的措施的
同时他是get型
说明只需要拿到这个链接，就可以进行修改了
127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=13676767767&add=CHINA&email=allen%40pikachu.com&submit=submit
其实想拿到这个链接的话也简单，我们只需要重注册一个号，然后登录修改之后，就可以获取到这个链接
我们修改一下这段链接中的内容
127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=1&add=shanxi&email=allen%40pikachu.com&submit=submit
然后将这段链接发送给allen，当allen正好登录的时候，点击了这段链接，就相当于以allen的身份来修改了自己的信息，我们来做一下演示
当前是allen在这个网站
然后他点击了这段链接
其实这个时候，他的信息已经被修改了
在抓到的包中也可以看到
其实就相当于攻击者以allen的身份来向后台提交了一个修改信息的请求
至此，一个get型的csrf就完成了
那么，如果是post型的呢？
是不是就可以防止csrf了
我们来看看
进入到post型中
我们修改一下，看看它抓到的包
提交
我们发现它的提交方式为post
所有参数在请求体中提交，我们就不能通过伪造URL的方式进行攻击
是不是不能进行攻击了呢？
其实不是，我们可以自己搭建一个站点
诱导allen点击链接，那么就会以allen身份向后台用post请求提交修改信息
怎么操作呢？
这里有个简单的操作，我们可以在抓到的包中右键
它会给我们自己生成一个脚本
我们来测试一下
修改这两个信息后，我们点击下面的Test in browser
出来这个
复制好这段链接，我们去测试一下
点击提交请求
信息被修改！
其实我们也可以在本地写一个html文件，原理一样，都是让用户来访问我们写的脚本，以达到以post请求向后台修改信息的请求。
在这个文件下，写一个post.html
内容如下
总结一下
get型的话，我们可以通过获取到的URL直接修改信息来进行攻击
post型的话，我们可以自己写一个站点，诱导用户点击链接，以post请求向后台提交修改个人信息的请求
CSRF token
那么，token是如何防止csrf的呢？
其实csrf的问题是由于链接容易被伪造
那么如果每次请求的时候，都给他加一个随机的token呢，后台每次会对这个随机码进行验证，不容易被伪造
我们看看它
提交
可以发现多了一个token值
那这个token值是什么呢
每当我们访问这个页面的时候，它就会生成一个token值（随机数）
而每次提交的时候，后台会对token进行验证
这样的话就可以有效的防止csrf
看看后台源码
可以看到，它每次都会对前端后台的token进行验证
攻击者无法伪造！
常见的防范措施
通过上面的学习
我们总结出了csrf的防范措施
增加token
对关键操作增加token值，让攻击者无法伪造
关于安全的会话管理
1，不要在客户端端保存敏感信息（比如身份认证信息）;
2，测试直接关闭，退出时，的会话过期机制;
3，设置会话过期机制，比如15分钟内无操作，则自动登录超时;
访问控制安全管理
1，敏感信息的修改时需要对身份进行二次认证，比如修改账号时，需要判断旧密码;
2，敏感信息的修改使用post，而不是get ;
3，通过http头部中的referer来限制原页面
增加验证码
一般在登录界面，也可以在一些修改重要信息的修改表单中
标签：CSRF,Pikachu,修改,token,csrf,靶场,大白,请求 来源： https://blog.csdn.net/qq_53083285/article/details/121108618
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。