Pikachu漏洞平台练习
简介
Pikachu是一个带有漏洞的Web应用系统，在这里包含了常见的web安全漏洞。 如果你是一个Web渗透测试学习人员且正发愁没有合适的靶场进行练习，那么Pikachu可能正合你意。
文章目录
- 简介
- 环境
- 1、brute force（暴力破解漏洞）
-
- 0X1．基于表单的暴力破解
- 0X2．验证码绕过（on server）
- 0X3．验证码绕过（on client）
- 0X4．token防爆破？
- 2、XSS（跨站脚本漏洞）
-
- 0X1．反射型XSS（get）
- 0X2．反射型XSS（post）
- 0X3．存储型XSS
- 0X4．DOM型xss
- 0X5．DOM型XSS-X
- 0X6．XSS之盲打
- 0X7．XSS之过滤
- 0X8．XSS之HTMLspecialchars
- 0X9．XSS之href输出
- 0X10．XSS之js输出
- 3、CSRF（跨站请求伪造）
-
- 0X1．CSRF（Get）
- 0X2．CSRF（Post）
- 0X3．CSRF（Token）
- 4、SQL-Ingect（SQL注入漏洞）
-
- 0X1．数字型注入（post）
- 0X2．字符型注入（get）
- 0X3．搜索型注入
- 0X4．XX型注入
- 0X5．“insert/update”注入
- 0X6．“delete”注入
- 0X7．“http header”注入
- 0X8．盲注（bash on boolean）
- 0X9．盲注（base on time）
- 0X10．宽字节注入
- 5、RCE（远程命令/代码执行）
-
- 0X1．exec“ping”
- 0X2．exec “evel”
- 6、Files Inclusion（文件包含漏洞）
-
- 0X1．本地文件包含
- 0X2．远程文件包含
- 7、Unsafe file downloads（不安全的文件下载）
- 8、Unsafe file uploads（不安全的文件上传）
-
- 0X1．client check
- 0X2．MIME type
- 0X3．getimagesize
- 9、Over permission（越权漏洞）
-
- 0X1．水平越权
- 0X2．垂直越权
- 10、../../../（目录遍历漏洞）
- 11、敏感信息泄露
-
- 0X1． IcanseeyourABC
- 12、PHP反序列化漏洞
-
- 0X1．PHP反序列化漏洞
- 13、XXE(XML External Entity attack)
-
- 0X1．XXE漏洞
- 14、URL重定向
-
- 0X1．不安全的url跳转
- 15、SSRF（服务端请求伪造漏洞）
-
- 0X1．SSRF（curl）
- 0X2．SSRF（file_get_content）
- 总结
环境
1.Phpstudy x64
2.pickchu-master
链接: https://pan.baidu.com/s/1RTRkCQjI9V1-ZB3Iogbf0Q
提取码: dqnn
网盘里面装了靶机文件和phpstudy，下载下来之后安装phpstudy，开启apache和mysql服务。
将pickchu-master解压缩，将解压后的文件保存到phpstudy安装目录下的www文件夹下。路径如下
修改config.inc.php文件修改为下图所示，主要修改数据库密码为root。
1、brute force（暴力破解漏洞）
Burte Force（暴力破解）概述
“暴力破解”是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。
理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括：
1.是否要求用户设置复杂的密码；
2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；
3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
4.是否采用了双因素认证； …等等。
千万不要小看暴力破解漏洞,往往这种简单粗暴的攻击方式带来的效果是超出预期的!
0X1．基于表单的暴力破解
①使用burpsuite登录页面抓包，并发送到intruder模块进行爆破，得到账号admin，密码123456
0X2．验证码绕过（on server）
服务端验证码问题常见：
<1>验证码比较交单，容易被猜解出来
<2>验证码一直存于后台不过期，可以多次使用
<3>因为逻辑问题，导致验证码校验出现问题
在进行验证码绕过的时候，我们需对输入不同验证码时候的反应进行观察，如下图：账号使用123/123。验证码正确时会显示账号不存在
开始正式的爆破过程，前文主要是对验证码的问题属于哪种类型进行检查。检查结果发现并不符合前两种
①burpsuite抓包，发送到repeter，点击go，显示账号密码不存在。
②更改账号进行测试。返回结果依然是显示账号密码不存在。
③这个时候问题出现了，两次测试，我们使用的验证码都是一样的，但是前面我们测试发现，在账号错误的时候，如果验证码错误，报错问题应该是验证码错误，而不是账号密码不存在。但是我们两次不同用户登录使用的是同一个验证码，那是不是就可以说明，输入一次正确的验证码之后，这个验证码时一直有效的。所以接下来的爆破工作就和验证码无关了，我们仅针对账号和密码进行爆破就可以，实现过程同基于表单的爆破。
0X3．验证码绕过（on client）
客户端验证码问题常见：
<1>验证码在js中产生
<2>验证码出现在前端源码中
<3>验证码在请求cookie中
①F12检查，发现验证码是由前端验证产生的，那么我们就可以通过burpsuite抓包进行绕过。
②抓包，直接删掉验证码，对账号和密码进行爆破。步骤同基于表单的爆破。
0X4．token防爆破？
①在存在token的时候，我们进行爆破。需要提前知道用户名或者密码之中的一个，假设此时我们知道存在用户名admin，把password和token作为参数化进行爆破。
②对token的正则表达式进行设置，过程如下。
③同一页面下，线程设置为1
④配置完成，开始进行爆破，针对密码的爆破。和前文都是一样的，接下来主要看对token的爆破
⑤对于token的爆破，按下图步骤即可。
⑥
2、XSS（跨站脚本漏洞）
XSS（跨站脚本）概述
Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS。一般XSS可以分为如下几种常见类型：
1.反射性XSS;
2.存储型XSS;
3.DOM型XSS;
XSS漏洞一直被评估为web漏洞中危害较大的漏洞，在OWASP TOP10的排名中一直属于前三的江湖地位。
XSS是一种发生在前端浏览器端的漏洞，所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤：对输入进行过滤，不允许可能导致XSS攻击的字符输入;
输出转义：根据输出点的位置对输出到前端的内容进行适当转义;
0X1．反射型XSS（get）
①我们随便在输入框插入字符，发现ｕｒｌ中原样出现，此时可以尝试利用XSS payload
②利用payload ，但是此时发现输入框是对长度有限制的
③F12打开前端代码，是对长度做了限制，此时我们更改长度为40
④输入,弹框，这就是一个通过url传参的反射型xss。
0X2．反射型XSS（post）
①我们利用admin/123456账号登录，发现还是没有进行任何的过滤，直接构造获取cookie的payload
0X3．存储型XSS
存储型xss和反射型xss最直观的区别就是，针对用户插入的数据，存储型XSS放入服务器，但是反射型没有。
①在输入框直接插入，只要刷新页面，就会一直弹框。
②输入，可以获取cookie信息。
0X4．DOM型xss
是由前端javascript脚本动态执行导致的。
①
②
0X5．DOM型XSS-X
window.location.search 从浏览器中获取url内容，然后赋值给 str 。最后是被拼接到了标签a上。
利用方法输入’ οnclick=“alert(‘xss’)”>
0X6．XSS之盲打
①随便输出一段内容，判断这是一个存储型XSS。右边给了我们地址去后台查看。
②插入一段XSS代码测试
③进入后台地址/xssblind/admin_login.php，账号密码为admin/123456
④
0X7．XSS之过滤
进行XSS测试的时候，我们首先应该考虑的是输入和输出的变化，我们输入了什么，输出又是什么。
我们输入最基本的XSS语句去判断，他的过滤规则。
①输入
②输入alert(1)
③可以发现，这里是对
0X8．XSS之HTMLspecialchars
①我们先来看HTMLspecialchar（）这个函数
①我们在进行输入的时候，发现<>被过滤掉了，但是单引号是可以使用的。而且输入的内容是被拼接在中的
②这个时候，我们可以使用不带<>的XSS语句进行构造paylaod。οnclick=alert（1）。
首先用单引号闭合a标签，点击输出的链接即可。
0X9．XSS之href输出
①插入一段字符，进行测试，发现我们的输入实在a标签中，并且<>被转义。
②我们可以使用javacsript进行测试javascript:alert(1)
0X10．XSS之js输出
①随便输入一串字符，检查源码。我们发现这段代码会将我们的输入放入js中进行判断，然后再输出。
②那我们可以将第一<script>用我们自己插入的代码进行闭合，然后再执行我们输入的xss语句，构造如下'
3、CSRF（跨站请求伪造）
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/[email protected]&Change=Change】
于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
—因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
—如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
—因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做： 欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
—所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
–对敏感信息的操作增加安全的token；
–对敏感信息的操作增加安全的验证码；
–对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。
0X1．CSRF（Get）
①使用allen/123456登录时，修改allen的信息时，抓包，我们发现，所以的信息都是以get方式保存在url中的
②那如果我们直接对url进行修改，也可以对信息进行修改
③所以我们的利用方法就是，直接对url进行修改，并将修改后的url发送给allen，如果allen点击，那么他的信息将被修改。
0X2．CSRF（Post）
①我们使用kobe的账号进行登录，修改个人资料，抓包，发现修改的内容全部在请求体中。
②这个时候我们无法直接对url进行更改，那我们就需要自己去创建一个请求，让kobe去点击。burp中可以直接生成poc
③生成的poc里面的内容我们可以进行修改，修改为我们想要更改的内容。发送给用户 ，用户点击后，内容被修改。
0X3．CSRF（Token）
在请求地址中加入token并进行验证。
可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
4、SQL-Ingect（SQL注入漏洞）
Sql Inject(SQL注入)概述
在owasp发布的top10排行榜里，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞里面首当其冲的就是数据库注入漏洞。
一个严重的SQL注入漏洞，可能会直接导致一家公司破产！ SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。 从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。
在构建代码时，一般会从如下几个方面的策略来防止SQL注入漏洞：
1.对传进SQL语句里面的变量进行过滤，不允许危险字符传入；
2.使用参数化（Parameterized Query 或 Parameterized Statement）；
3.还有就是,目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了"拼接"的方式,所以使用时需要慎重!
我们可以通过sqlmap等工具进行测试，本文以手工为主。
0X1．数字型注入（post）
①我们选择数字进行查询，未找到可以注入的点，抓包
②我们将参数1更改为1’，重发，官产页面反应，判断是否存在注入
③开始进行手工注入，流程如下。
1、判断是否存在注入
id=1
id=1'
2、猜字段数
id=1 order by 2
id=1 order by 3
3、联合查询判断显示位
id=-1 union select 1,2
4、获取数据库
id=1 union select 1,group_concat(schema_name) from information_schema.schemata
或者
id=1 union select 1,database()
5、获取piakchu数据库中的表
id=-1 union select 1,group_concat(table_name) from information_schema.tables where table_schema=database()
6、获取user表中的列
id=-1 union select 1,group_concat(column_name) from information_schema.columns where table_name='users'
7、获取"username"、"password"的值
id=-1 union select group_concat(username),group_concat(password) from pikachu.users
或者
id=-1 union select 1,group_concat(username,'---',password) from users
获取到的值为密码经过md5加密的结果，解密即可得到明文密码。
admin–123456、pikachu–000000、test–abc123
0X2．字符型注入（get）
①出入一个字符串，观察页面反应，参数直接出现在url中传递
②我们直接在输入框进行注入即可，过程和数字型注入类似
0X3．搜索型注入
和字符型注入类似，唯一区别就是字符型的字段为2，这里字段为3。
0X4．XX型注入
我们在进行'和"闭合时都失败了，尝试其他闭合方式')成功。在进行注入的时候，令id=a')，其他语句一致。
0X5．“insert/update”注入
1、insert注入
注册页面抓包，我们在原本注册的用户名eqeq后加上'，页面报错，发现存在注入
这里我们使用一个新的函数进行注入：updatexml()
1.查找数据库
1' and updatexml(1,concat(database()),1)) #
2.查找数据库中的表
1' and updatexml(1,concat((select table_name from information_schema.tables where table_schema = database() limit 0,1)),1))#
3.查找表中的字段
1' and updatexml(1,concat((select column_name from information_schema.columns where table_name = 'users' limit 0,1)),1))#
4.字段值
username：1' and updatexml(1,concat((select username from users limit 0,1)),1))#
password：1' and updatexml(1,concat(0,(select password from users where username='admin')),1))#
2、update注入
和insert同理
0X6．“delete”注入
我们在点击删除按钮的时候，发现删除的请求是通过get方式传递的。测试为数字型注入。
步骤同insert注入
0X7．“http header”注入
我们使用账号admin/123456登录后发现HTTP头中的信息会保存在服务器。
我们此时对http header抓包进行测试，
0X8．盲注（bash on boolean）
基于布尔的盲注。这里推荐使用sqlmap进行注入。
sqlmap进行注入的基本语法是：
-u 指定url
--dbs 获取数据库
--batch 自动化注入，注入过程中不需要再手工配置一些选项
-D 指定数据库 -T 指定表 -C 指定获取的表中字段
--dump 打印数据
1.查询数据库
python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" --dbs
2.获取数据库中的表
python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" -D pikachu --tables --batch
3.获取表中的字段名
python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" -D pikachu -T users --columns --batch
4.获取字段信息
python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" -D pikachu -T users -C username,password --dump --batch
0X9．盲注（base on time）
基于时间的盲注，进行注入时，我们无法通过页面反应来判断注入的时，可使用这个方法。
--technique:选择注入技术
-T:Time-based blind ----指定为基于时间延迟注入
1.查询数据库
python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" --technique T --current-db --batch
2.获取数据库中的表【httpinfo,member,message,users,xssblind】 python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" --technique T -D pikachu --tables --batch
3.获取表中的字段名
python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" --technique T -D pikachu -T users --columns --batch
4.获取字段信息
python sqlmap.py -u "http://127.0.0.1/pikachu-master/vul/sqli/sqli_blind_b.php?name=dasda&submit=%E6%9F%A5%E8%AF%A22" --technique T -D pikachu -T users -C username,password --dump --batch
0X10．宽字节注入
主要是构建参数和闭合，其余步骤一致
5、RCE（远程命令/代码执行）
RCE(remote command/code execute)概述
RCE漏洞，可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。
１．远程系统命令执行
一般出现这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口
比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上
一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，后台会对该IP地址进行一次ping测试，并返回测试结果。 而，如果，设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，从而让后台进行执行，从而控制整个后台服务器
现在很多的甲方企业都开始实施自动化运维,大量的系统操作会通过"自动化运维平台"进行操作。 在这种平台上往往会出现远程系统命令执行的漏洞,不信的话现在就可以找你们运维部的系统测试一下,会有意想不到的"收获"-_-
２．远程代码执行
同样的道理,因为需求设计,后台有时候也会把用户的输入作为代码的一部分进行执行,也就造成了远程代码执行漏洞。 不管是使用了代码执行的函数,还是使用了不安全的反序列化等等。
因此，如果需要给前端用户提供操作类的API接口，一定需要对接口输入的内容进行严格的判断，比如实施严格的白名单策略会是一个比较好的方法。
0X1．exec“ping”
①正常情况下，我们输入ip地址127.0.0.1，返回如下
②但是由于系统对用户输入的命令未做限制，我们可以通过拼接其他的命令获取到意想不到的内容
如127.0.0.1 | dir
③我们甚至可以通过命令远程创建用户127.0.01 | net user sy 0000 /add
0X2．exec “evel”
①我们随意输入一个字符串，报错，并返回了路径信息
②我们尝试使用phpinfo();
③也可以使用其他代码进行尝试，由于我系统是搭建在windows下的，我们利用sysytem(ipconfig);对ip地址进行探测。
6、Files Inclusion（文件包含漏洞）
文件包含，是一个功能。在各种开发语言中都提供了内置的文件包含函数，其可以使开发人员在一个代码文件中直接包含（引入）另外一个代码文件。
比如 在PHP中，提供了：
include(),include_once()
require(),require_once()
这些文件包含函数，这些函数在代码设计中被经常使用到。大多数情况下，文件包含函数中包含的代码文件是固定的，因此也不会出现安全问题。 但是，有些时候，文件包含的代码文件被写成了一个变量，且这个变量可以由前端用户传进来，这种情况下，如果没有做足够的安全考虑，则可能会引发文件包含漏洞。 攻击着会指定一个“意想不到”的文件让包含函数去执行，从而造成恶意操作。 根据不同的配置环境，文件包含漏洞分为如下两种情况：
1.本地文件包含漏洞：仅能够对服务器本地的文件进行包含，由于服务器上的文件并不是攻击者所能够控制的，因此该情况下，攻击者更多的会包含一些 固定的系统配置文件，从而读取系统敏感信息。很多时候本地文件包含漏洞会结合一些特殊的文件上传漏洞，从而形成更大的威力。
2.远程文件包含漏洞：能够通过url地址对远程的文件进行包含，这意味着攻击者可以传入任意的代码。
因此，在web应用系统的功能设计上尽量不要让前端用户直接传变量给包含函数，如果非要这么做，也一定要做严格的白名单策略进行过滤。
0X1．本地文件包含
①输入框给我们提供了5个选择，当我们选择kobe时，我们在url栏可以看到参数为filename=file1.php，选择Allen Iverson 时，为filename=file2.php。
②这时，我们可以猜想一些文件名进行替换，以获取服务器文件，我们在进行文件包含前，系统是需要先开启allow_url_include=On选项的
③这个时候，我们就可以通过…/…/…/去进行包含，比如…/…/…/phpinfo.php
0X2．远程文件包含
远程文件包含需要服务器开启allow_url_fopen，本地文件包含则不需要，这个时候构造方式和本地基本相同，不过我们此时包含的文件时远程服务器上的一个文件。
我们在服务器上写一个2.txt文件，filename的值为2.txt的路径。
7、Unsafe file downloads（不安全的文件下载）
文件下载功能在很多web系统上都会出现，一般我们当点击下载链接，便会向后台发送一个下载请求，一般这个请求会包含一个需要下载的文件名称，后台在收到请求后 会开始执行下载代码，将该文件名对应的文件response给浏览器，从而完成下载。 如果后台在收到请求的文件名后,将其直接拼进下载文件的路径中而不对其进行安全判断的话，则可能会引发不安全的文件下载漏洞。
此时如果 攻击者提交的不是一个程序预期的的文件名，而是一个精心构造的路径(比如…/…/…/etc/passwd),则很有可能会直接将该指定的文件下载下来。 从而导致后台敏感信息(密码文件、源代码等)被下载。
所以，在设计文件下载功能时，如果下载的目标文件是由前端传进来的，则一定要对传进来的文件进行安全考虑。 切记：所有与前端交互的数据都是不安全的，不能掉以轻心！
①点击图片下方的链接可以直接下载图片，我们右键打开图片时，发现了如下地址
②可以发现，照片是通过filename直接获取的，那么我们是不是可以通过filename构造链接直接获取其他文件。构造如下请求，并发送。
8、Unsafe file uploads（不安全的文件上传）
不安全的文件上传漏洞概述
文件上传功能在web应用系统很常见，比如很多网站注册的时候需要上传头像、上传附件等等。当用户点击上传按钮后，后台会对上传的文件进行判断 比如是否是指定的类型、后缀名、大小等等，然后将其按照设计的格式进行重命名后存储在指定的目录。 如果说后台对上传的文件没有进行任何的安全判断或者判断条件不够严谨，则攻击着可能会上传一些恶意的文件，比如一句话木马，从而导致后台服务器被webshell。
所以，在设计文件上传功能时，一定要对传进来的文件进行严格的安全考虑。比如：
–验证文件类型、后缀名、大小;
–验证文件的上传方式;
–对文件进行一定复杂的重命名;
–不要暴露文件上传后的路径;
–等等…
0X1．client check
查看源码，发现仅仅在前端做了对后缀名的限制，我们可以通过图片马、更改后缀，修改前端代码等方式进行绕过。
①F12打开，将下图部分删掉
②然后上传一个非允许的后缀文件
0X2．MIME type
①上传文件，页面显示只能上传jpg、jpeg、png
②抓包，将文件类型修改为图片类型
③重放数据包，文件上传成功
0X3．getimagesize
①上传png图片。抓包，在包中添加一句话木马，phpinfo();，重发。
②但这个时候存在一个问题，我们的代码是在图片文件中，无法去执行，那我们就需要其他的漏洞去配合，使这个图片文件可以去以php的格式去执行。可以利用前文存在的文件包含漏洞。
9、Over permission（越权漏洞）
如果使用A用户的权限去操作B用户的数据，A的权限小于B的权限，如果能够成功操作，则称之为越权操作。 越权漏洞形成的原因是后台使用了 不合理的权限校验规则导致的。
一般越权漏洞容易出现在权限页面（需要登录的页面）增、删、改、查的的地方，当用户对权限页面内的信息进行这些操作时，后台需要对 对当前用户的权限进行校验，看其是否具备操作的权限，从而给出响应，而如果校验的规则过于简单则容易出现越权漏洞。
因此，在在权限管理中应该遵守：
1.使用最小权限原则对用户进行赋权;
2.使用合理（严格）的权限校验规则;
3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;
0X1．水平越权
A、B两个用户权限相同，不能互相查看，但是如果A通过越权操作，查看了B的信息，为水平越权。
默认用户有三个，分别为：lucy/123456,lili/123456,kobe/123456
①我们使用lucy/123456登录
②我们通过更改url中username的取值为：kobe。发现显示结果为kobe的身份信息。
0X2．垂直越权
A为低权限用户，Ｂ为高权限用户，Ａ通过越权操作进行了Ｂ才可以做的事情，为垂直越权。
默认用户有三个，分别为：admin/123456；pikachu/000000，admin为高权限用户。
①使用piakchu用户登录，仅支持查看权限
②使用admin用户登录，支持查看，也可添加新用户
③点击创建新用户PiuPiu，并使用burpsuite抓包,可看到cookie中的PHPSESSID=og1sc2csm3faneaakpq8om4027
④使用普通用户登录，抓包。
⑤将 pikachu的 PHPSESSID=3p48119uc0fua67k2kadfddotu替换掉使用admin登录时的cookie。并发送到repeter，点击go。
⑥此时，出现两个piupiu用户，一个为admin创建，一个为pikachu创建。
10、…/…/…/（目录遍历漏洞）
目录遍历漏洞概述
在web功能设计中,很多时候我们会要将需要访问的文件定义成变量，从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时，便会将请求的这个文件的值(比如文件名称)传递到后台，后台再执行其对应的文件。 在这个过程中，如果后台没有对前端传进来的值进行严格的安全考虑，则攻击者可能会通过“…/”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来，形成目录遍历漏洞。
看到这里,你可能会觉得目录遍历漏洞和不安全的文件下载，甚至文件包含漏洞有差不多的意思，是的，目录遍历漏洞形成的最主要的原因跟这两者一样，都是在功能设计中将要操作的文件使用变量的 方式传递给了后台，而又没有进行严格的安全考虑而造成的，只是出现的位置所展现的现象不一样，因此，这里还是单独拿出来定义一下。
需要区分一下的是,如果你通过不带参数的url（比如：http://xxxx/doc）列出了doc文件夹里面所有的文件，这种情况，我们成为敏感信息泄露。 而并不归为目录遍历漏洞。
这里采用title直接进行传参获取文件，那么我们可以对想要获取的文件通过…/../../进行遍历…/…/…/phpinfo.php
11、敏感信息泄露
由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。 比如：
１．通过访问url下的目录，可以直接列出目录下的文件列表;
２．输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
３．前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。 因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。
0X1． IcanseeyourABC
①F12查看页面源代码，发现这么一行。可以使用该测试账号进行登录。
②将url中的findabc.php，修改为abc.php，也可直接进行登录。
12、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:"";}
0X1．PHP反序列化漏洞
①我们通过一段代码将php代码序列化
class S{
var $test = "";
}
$a = new S();
echo serialize($a);
?>
②通过在线编辑器，执行代码获得一个序列化字符串
③得到这段序列化字符串之后，在输入框输入。
13、XXE(XML External Entity attack)
XXE --“xml外部实体注入漏洞”。
就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"
也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
0X1．XXE漏洞
①我们在输入框中输入如下代码
]>
&n;
②
14、URL重定向
不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。
如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话就可能发生"跳错对象"的问题。
url跳转比较直接的危害是:
钓鱼,既攻击者使用漏洞方的域名(比如一个比较出名的公司域名往往会让用户放心的点击)做掩盖,而最终跳转的确实钓鱼网站。
0X1．不安全的url跳转
①只有四条句子，可以点击，挨个点击一下，发现第四条的url和其他三条不同，第四条是存在参数的。
②判断过后，发现，最后出现的文字就是传参url=i的结果，那此时，我们可以将“i”这个参数更改为钓鱼网站的地址，如果这个地址存在，那么就可以进行跳转。我们使用百度作为示范更改url为：127.0.0.1/pikachumaster/vul/urlredirect/urlredirect.php?url=http://www.baidu.com在可以跳转到百度页面。
百度的网址我们可以更换为其他网站，例如自己的钓鱼网站。
15、SSRF（服务端请求伪造漏洞）
其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据
0X1．SSRF（curl）
①点击文字，跳转如下页面。
②我么可以将url内容更改为任意一个服务器进行访问，如果访问成功，则存在SSRF
uZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5Y2Ftb3JlbGc=,size_16,color_FFFFFF,t_70)
0X2．SSRF（file_get_content）
将URL改为一个服务器上存在的文件，进行访问
总结
本文就是练习过程中的一些操作，如果对于漏洞原理或者其他问题不太了解，可以查看其他博客。