pikachu靶机学习记录

（环境准备：win2008+phpstudy）

暴力破解

基于表单的暴力破解

首先随意输入一个用户名和密码，Burpsuite抓包

发现没有验证码及其他限制，可以肆意爆破，由于左上角的提示按钮给出了答案，下面处于演示需求做一个简单爆破。


爆出一个账密：admin：123456

验证码绕过(on client)

首先明确两个概念：验证码一般被用来做什么，以及验证码是怎么认证的。
我们一般使用验证码作什么？

1：防止登录被暴力破解
2：防止机器人恶意操作

验证码认证流程
1：客户端请求登录页面，后台生成验证码

后台使用算法生成图片，并将图片响应给客户端
同时将算法生成的值全局赋值存到SESSION中

2：校验验证码

客户端将认证信息和验证码一同提交
后台对提交的验证码与SESSION里面的进行比较

3：客户端重新刷新页面，再次生成新的验证码

验证码算法中一般包含随机函数，所以每次刷新都会改变

客户端验证码是个啥
由于题目是“验证码绕过(on client)”，所以可以列出客户端验证码的常见问题：

使用前端js实验验证码（纸老虎）
将验证码在cookie中泄露，容易被获取
将验证码在前端源代码中泄露，容易被获取

首先先来试试这个页面，账密胡编，测试发现：

不输入验证码会报错
输错验证码会报错
正确输入验证码才会报：用户名或者密码错误

行吧，那就换一种个思路。首先需要明确BurpSuite是一个代理，是客户端浏览器和服务器之间的一个中间人，那么思路就可以是先输入正确的验证码跳出浏览器客户端，进入到BurpSuite中，再由Burpsuite篡改验证码，去验证服务器端是否有验证码验证。

方案1：修改验证码
发现服务器不管验证码错误

方案2：删除验证码
发现服务器不管验证码丢失，操作同上。大致可以判断，是如下逻辑：

我这里选择方案2，执行直接爆破，操作内容同基于表单的暴力破解，不再赘述

验证码绕过(on server)

先来说一下服务端验证码常存在的问题

验证码在后台过期时间太长，导致验证码可以长期被使用
验证码校验不严格，逻辑出现问题
验证码以明文的形式出现在HTTP响应包里面
验证码设计的太过简单，存在规律，可以被猜到

来看一下目标站点，长这个样子

测试发现，验证码为空，验证码填写错误都会报错，正确填入验证码之后，BurpSuite更改验证码或者删除验证码都会出错，说明服务器和客户端都做了验证码校验，那么首先考虑验证码的可用时长问题。
BurpSuite中的包不要管了，停止截断，浏览器那边手动刷新验证码，获取一个新的验证码之后就不要再动浏览器了，拿着这个新的验证码写到BurpSuite中试着连发几个包，证明是否存在验证码有效期问题

通过更改账密发现服务器返回的是username or password is not exists～说明验证码没有过期，那就爆破


再次爆破成功
实验的逻辑如下：

token防爆破?

来看一下题目，token在这里是不能防爆破的，i see you here

先用BurpSuite重放试试，发现更改账密时，服务器的响应中有新的token，那其实可以拿每次失败后返回的新的token去做下一次测试，那这样是话是可以爆破的

1：把截断下来的内容发送到Intrude模块，注意选择的攻击模式！
为了方便实验，这里只选择密码和token作为对象。

2：来到Options模块，使用Grep - Extract 通过正则提取返回信息中的内容，如下图所示，先勾选，然后点add发现弹出的页面是空白的话再点一下Refetch response就能看到响应包了，确认目标之后选中即可，然后复制一下token值，就可以点击ok关闭页面了

3：设置为Always

4：线程设置为1

5：第一个payload是密码字典，第二个payload就是token值，粘贴上刚才复制的token值

6：填一下Grep - Match，方便一会找出答案！！！其中login success是在前面的实验中发现的，只要登录成功就会返回这个信息

7：发起攻击

8：于是，很轻松的找出了密码

防爆破的一些手段

设计安全的验证码（安全的流程+复杂而又安全的图形）
对认证错误给出次数限制，超出次数就锁定账户一段时间
使用双因素认证

XSS（跨站脚本）

实验逻辑如下图：

XSS漏洞的常见类型
危害：存储型 > 反射型 > DOM型
1：反射型
交互的数据一般不会被存储在数据库里面，一次性的，所见即所得，一般出现在查询类页面等

2：存储型
交互的数据会被存在数据库里面，永久性存储，一般出现在留言板，注册页面等

3：DOM型
不会与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题，一次性的类似反射型

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

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

反射型xss(get)

首先来试着随便输一下测试代码，然后查看页面源代码


可以看到它没做任何过滤，直接上<script>alert(/xss/)</script>在输入代码的时候发现有长度限制，先看看它是不是前端的，能不能绕过

有戏（注意，要先改长度限制，再输入payload）

反射型XSS（POST）

1：按照提示登陆

2：输入一个XSS代码<script>alert(/xss/)</script>

3：回车弹窗

存储型xss

方法同【反射型xss(get)】，先来一个测试代码，接着查看页面源代码。


看起来没有做过滤，那就直接上payload<script>alert(/xss/)</script>

DOM型xss

思路依然是先来一个测试代码，然后查看页面源代码


所以，只需要闭合<a href='"+str+"'>即可，payload可以构造为：#' onclick="alert(/xss/)">

DOM型xss-x

老套路，测试代码+页面源代码


发现和上一题基本一样，payload继续用#' onclick="alert(/xss/)">

XSS盲打

1：先尽可能多的提交一下

2：按照提示登陆后台


3：登陆进去之后报了弹窗

XSS之过滤

大小写绕过<ScriPT>alert(/xss/)</ScriPT>
双写绕过 <scri<script>pt>alert(/xss/)</scr</script>pt>

XSS之htmlspecialchars

输入#' onclick='alert(1)'（建议手敲）

XSS之href输出

使用伪协议javascript:alert(1);

XSS之js输出

使用payload'</script><script>alert(/xss/)</script>


使用payloadtmac';alert(1);//

CSRF

参见https://blog.csdn.net/weixin_44288604/article/details/108307644

SQL注入

数字型注入（POST）

1：BurpSuite改包，添加 or 1=1#

2：结果如下，存在注入

字符型注入（get）

1：写入payloadkobe' or 1=1#

2：存在注入

搜索型注入

1：写入payload%' or 1=1#

2：存在注入

XX型注入

1：写入payload') or 1=1#

2：存在注入

INSERT/UPDATE注入

1：首先注册账户

2：基于报错注入用户名处payload就为

kobe2' or updatexml(1,concat(0x7e,version()),0) or '

密码随意写一个就行

3：存在注入

Delete注入

1：由于是Delete注入，先留言一条

2：BurpSuite抓包，橙色标记部分为添加的payload+or+updatexml(1,comcat(0x7e,database()),0)

3：注入成功

"http header"注入

1：根据提示填写账号

2：由于是"http header"注入，在点击“login”之前开启BurpSuite抓包，并把抓到的数据包发送到重放模块
3：橙色部分为payloadevil' or updatexml(1,concat(0x7e,version()),0) or '

盲注（base on boolean）

举例如下：构造payloadkobe' and length(database())>6#

有回显，说明存在注入

盲注（base on time）

构造payloadkobe' and sleep(5)#
会有大概5秒左右的延时，说明存在注入

宽字节注入

BurpSuite改包，把数据修改为橙色部分的payloadkobe%df' or 1=1#

存在注入

RCE

exec"ping"

直接构造payload：127.0.0.1 & net user

exec"eval"

直接构造payloadphpinfo();

File Inclusion

本地文件包含

1：准备一个txt文件

2：随便选择一个，提交查询，获取页面

3：修改URL

192.168.50.129/pikachu-master/vul/fileinclude/fi_local.php?filename=1.txt&submit=提交查询

4：成功包含

远程文件包含

1：使用kali来做远程主机
2：在kali的/var/www/html/目录下新建phpinfo.txt

3：启动apache服务

4：访问kali正常

5：远程包含成功

Unsafe Filedownload

随意点开一个图片，BurpSuite抓包，橙色部分为payload

成功下载系统中的其他文件

Unsafe Fileupload

client check

直接上传一句话木马失败，根据题目，怀疑是前端限制

删除前端限制

重新上传一句话木马

MIME TYPE

看到这个标题，就知道是修改文件类型绕过，固定套路

橙色部分为payloadimage/jpg

上传成功

getimagesize()验证

图片木马，固定套路
1：制作图片木马

2：上传

3：根据文件上传成功的路径，打开图片看一看

由于是以图片格式打开的，所以无法直接利用，可以通过文件包含，getshell
观察图片木马成功上传的路径和本地文件包含的路径，可以得出包含图片木马的路径，进而getshell

http://192.168.50.129/pikachu-master/vul/fileinclude/fi_local.php?filename=../../unsafeupload/uploads/2020/09/29/6191325f731b7f3be29049099880.jpg&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2

over permission

水平越权

计划以lucy的身份水平越权lili
1：lucy登陆系统

2：把lucy修改为lili

3：查看成功

垂直越权

根据提示，猜测应该是pikacu越权admin。

1：pikachu登陆，发现自己只有查看权限

2：管理员登陆，有添加用户权限

3：admin添加新用户，BurpSuite抓包，发送到重放模块，然后停止截包

admin添加了一个新用户haha

4：admin退出登陆，pikachu登陆系统，目的是为了获取pikachu的cookie，保持截断数据包

5：来到重放模块
（1）把cookie换成pikachu的
（2）修改一下新建用户的信息

6：代理模块停止截包
7：pikachu登陆成功，会看到自己添加的用户alice

…/…/

目录遍历

其实跟不安全的文件下载类似，就是非法指定一个路径下的文件。
这里选择非法访问”概述“页面
1：首先看到”概述“的URL是这样的

2：点开一个目录遍历
3：修改URL，在”目录遍历“页面成功访问到”概述“页面

敏感信息泄露

IcanseeyourABC

提示说，很多地方都泄露了，先去页面源代码看看

发现测试账号，并成功登陆进来

PHP反序列化

php反序列化漏洞

使用payloadO:1:"S":1:{s:4:"test";s:29:"<script>alert(/xss/)</script>";}

XXE

XXE漏洞

构造payload<?xml version = "1.0"?> <!DOCTYPE note [ <!ENTITY hacker "xxe"> ]> <name>&hacker;</name>

URL重定向

不安全的URL跳转

把4个超链接都点一遍，发现第4个存在参数

把参数更改成一个地址就行了，按回车就会跳转

SSRF

SSRF(curl)

1：打开页面后有一个超链接，点一下
2：注意到URL里面有一个地址

3：篡改地址

SSRF(file_get_content)

方案1：直接子修改地址
注意：写的是http://baidu.com，是http，不是https

方案2：读取页面源码
payload：?file=php://filter/read=convert.base64-encode/resource=ssrf.php

复制，然后base64解码