pikachu靶场--越权/目录遍历/敏感信息泄露/PHP反序列化/XXE/URL重定向/SSRF 【8.1】~【14.2】

目录

越权漏洞

概述

水平越权

垂直越权 

目录遍历漏洞

概述

演示

 敏感信息泄露

概述

PHP反序列化

XXE

URL重定向

概述

演示

SSRF

概述

演示



越权漏洞

概述

如果使用A用户的权限去操作B用户的数据,A的权限小于B的权限,如果能够成功操作,则称之为越权操作。 越权漏洞形成的原因是后台使用了不合理的权限校验规则导致的。

一般越权漏洞容易出现在权限页面(需要登录的页面)增、删、改、查的的地方,当用户对权限页面内的信息进行这些操作时,后台需要对当前用户的权限进行校验,看其是否具备操作的权限,从而给出响应,而如果校验的规则过于简单则容易出现越权漏洞。

因此,在在权限管理中应该遵守:
1.使用最小权限原则对用户进行赋权;
2.使用合理(严格)的权限校验规则;
3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;

水平越权

在pikachu上做对应测试:

当我们以lucy的身份登进去之后,可以看到仅仅是HTTP get请求里传参为lucy

且,后台对越权没有做合格的校检,那么当我们把URL中的参数修改后(改为lili),我们便实现了越权操作。

垂直越权 

首先有超级管理员(admin/123456),还有普通管理员(pikachu/000000)

以超级管理员身份登录,可以看到有几种权力!

以普通管理员身份登录,可以看到只有查看的权限

利用bp把普通管理员登录的cookie抓到(bp1),然后再切换到超级管理员,进行一次添加用户的操作,再次用bp抓包(bp2),然后超级管理员退出登录,让普通管理员登录,将bp2中的cookie换为bp1中的cookie,该添加用户的操作可再一次执行,也就是普通管理员实现了垂直越权。

它只判断了当前用户有没有登录,没有判断该用户有没有这一操作的权限。 


目录遍历漏洞

概述

在web功能设计中,很多时候我们会要将需要访问的文件定义成变量,从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时,便会将请求的这个文件的值(比如文件名称)传递到后台,后台再执行其对应的文件。 在这个过程中,如果后台没有对前端传进来的值进行严格的安全考虑,则攻击者可能会通过“../”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来,形成目录遍历漏洞。

看到这里,你可能会觉得目录遍历漏洞和不安全的文件下载,甚至文件包含漏洞有差不多的意思,是的,目录遍历漏洞形成的最主要的原因跟这两者一样,都是在功能设计中将要操作的文件使用变量的 方式传递给了后台,而又没有进行严格的安全考虑而造成的,只是出现的位置所展现的现象不一样,因此,这里还是单独拿出来定义一下。

需要区分一下的是,如果你通过不带参数的url(比如:http://xxxx/doc)列出了doc文件夹里面所有的文件,这种情况,我们成为敏感信息泄露。 而并不归为目录遍历漏洞。(关于敏感信息泄露你你可以在"i can see you ABC"中了解更多)

演示

初始状态:

点击超链接,其实就是访问了一个文件(多出来的这部分)

把多出来的这部分换为 ../../../../etc/passwd,便可以看到所需信息。


 敏感信息泄露

概述

由于后台人员的疏忽或者不当的设计,导致不应该被前端用户看到的数据被轻易的访问到。 比如:
---通过访问url下的目录,可以直接列出目录下的文件列表;
---输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
---前端的源码(html,css,js)里面包含了敏感信息,比如后台登录地址、内网接口信息、甚至账号密码等;

类似以上这些情况,我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞,但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。 因此,在web应用的开发上,除了要进行安全的代码编写,也需要注意对敏感信息的合理处理。

你可以通过“i can see your abc”对应的测试栏目,来进一步的了解该漏洞。

第一种情况:前端人员写完代码后,在注释部分留下了敏感信息,而且注释没有删除。

第二种情况:用web开发者工具在网络--重新载入--可以看到cookie和账号密码

第三种情况:可以在前端看到相关的版本信息。


PHP反序列化

在理解这个漏洞前,你需要先搞清楚php中serialize(),unserialize()这两个函数。

序列化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

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

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


URL重定向

概述

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

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

这个漏洞比较简单,come on,来测一把!

演示

 原来URL是i,点一下应该跳转到自己的页面,但是只要把i改为http://www.baidu.com就会跳转到百度去了,那么我们将来可以将百度URL替换为钓鱼站点或者是其他病毒网站,用前面好的网址做掩护,从而攻击受害者。


SSRF

概述

其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制

导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据

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

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

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

file_get_contents()

fsockopen()

curl_exec()

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

演示

这其实就是攻击者以存在SSRF漏洞的服务器为跳板,去攻击其他的目标服务器,以pikachu为例:

首先看到一个<a>标签

点击<a>标签之后,页面跳转,可以看到是以URL参数的方式提交了请求。

当我们把后面的URL改为www.baidu.com时,页面便会跳转到百度首页,如图所示:

这个并不是我们的浏览器直接去请求百度,而是浏览器把参数传到后端,后端的服务器通过某种方法去请求百度,然后把百度返回的数据又返回到前端来。

这就意味着我们可以通过这个漏洞对同一个内网里面的服务器去进行扫描探测,获取更多的内网资源,然后进行下一步的攻击。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
对于pikachu敏感信息泄漏的情况,我们需要采取一系列措施来保护敏感信息安全。首先,我们需要进行安全的代码编写,以避免应用维护或开发人员无意间上传敏感数据,比如避免将敏感信息存储在公开的代码库中。\[1\]其次,我们需要注意权限设置,确保敏感数据文件的访问权限正确设置,避免网站目录下的数据库备份文件等敏感数据泄露。\[2\]此外,我们可以采用传输层安全性 (TLS) 来保护数据在传输过程中的安全性,确保数据的加密传输。\[3\]另外,我们还可以对需要存储的静态数据进行加密,使用强大的标准算法、协议和密钥来保护数据的安全性。同时,我们可以使用哈希函数对密码进行加盐和哈希处理,增加密码的安全性。综上所述,通过合理处理敏感信息,采取相应的安全措施,我们可以有效地防止敏感信息泄漏的风险。 #### 引用[.reference_title] - *1* [Pikachu靶场-敏感信息泄露](https://blog.csdn.net/weixin_48899364/article/details/128504463)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^insertT0,239^v3^insert_chatgpt"}} ] [.reference_item] - *2* *3* [pikachu靶场-敏感信息泄露](https://blog.csdn.net/qq_29977871/article/details/131253238)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^insertT0,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值