1-暴力破解
1暴力破解漏洞
暴力破解攻击&暴力破解漏洞概述
对暴力破解的理解:暴力破解=连续性的尝试+字典+自动化。
其实就是去猜可能的密码,经过不断的试账号和密码,找出正确的账号密码,达到暴力破解的目的。
最重要的部分就是字典,一个好的字典可以大大加快破解速度。
常用的账号密码(弱口令),比较常用的账号密码,系统初始设定的账号密码,比如常用用户名/密码TOP 500等。
互联网上被脱裤后账号密码(社工库) ,差不多就是撞库,也就是拿已知的一个库去尝试登录另外一个库。比如CSDN当年泄漏的约600w用户信息。
使用指定的字符使用工具按照指定的规则进行排列组合算法生成的密码,特定的字符很多,像手机号、出生日期,姓名等等。
对于暴力破解漏洞的话,如果个网站没有对登录接 实施防暴力破解的措施,或者实施 了不合理的措施,称该网站存在暴力破解漏洞。
1是否要求用户设置了复杂的密码
2是否每次认证都使用安全的验证码
3是否对尝试登录的行为进行判断和限制
4是否在必要的情况下采用了双因素认证…等等。
存在暴力破解漏洞的网站可能会遭受暴力破解攻击,但该暴力破解攻击成功的可能性并不是100% !
2测试流程
3字典优化技巧
4基于表单的暴力破解
简单,直接进行抓包,根据返回长度判断用户名与密码的正确性,在这里介绍一下attack的四种方式及及其优缺点
5验证码绕过(onclient)
验证码的认证流程
验证码仅仅在前端的javascript中进行验证 前端生成的验证码,服务器并不校验 只需要输入一次正确的验证码抓到请求包后将验证码删除即可重复发送登陆请求进行爆破.
发送到repeater模块可以进行一些自定义的修改,点击sent,可以得到response,当vacode不填或者乱填,后台并不会提示,只是提示用户名或密码不存在,说明后端不存在对验证码的一个验证.
观察下面的源代码,仅仅输入用户名和密码,没有对验证码进行验证
6验证码(on server)
进行抓包,发送到repeater,输入错误的验证码,或者不输入,会发现后端进行提示,验证码输入错误,或者未输入验证码 ,由此可判断,后端对验证码进行了判断.
把正确的验证码记录下来,然后去数据包中输入,点击sent,会发现提示username or password is not exists~,然后把账号或者密码改了,会发现后台仅仅提示username or password is not exists~,而不会提示验证码相关问题,说明验证码可重复多次利用.
因此只需要对账号和密码进行add,验证码只需要那个正确的验证码,然后抓包即可.
解决方法,设置过期时间,是使验证码即及时的得到销毁
7token可以防爆破吗?
2-CSS-cross-site scripting
有三种类型
XSS是一种发生在前端浏览器端的漏洞,所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理,导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
所以在XSS漏洞的防范上,一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤:对输入进行过滤,不允许可能导致XSS攻击的字符输入;
输出转义:根据输出点的位置对输出到前端的内容进行适当转义;
反射型xss-get
先根据提示输入一个kobe,发现弹出以下内容
然后我们随便输入一个内容,比如lizhiwei520,点击F12,查看源代码,ctrl+f,搜索,发现输入的内容到达了前端,被加载到了p标签中
然后我们利用这一点,插入一个script脚本,但是我们需要对输入内容的长度进行一下修改,点击F12
修改长度,
输入内容<script>alert(6)</script>
反射性xss-post
点击一下提示,然后进行登录,继续输入<script>alert(6)</script>,发现没有长度限制,而且url里面没有恶意代码.
我们使用bp进行抓包,然后输入666点击submit,然后将请求包的message修改为xss的payload并放包.按下图进行操作
然后放行
查看前端代码,xsspayload被插入了标签当中
存储型xss
顾名思义也就是我们输入的内容会被存储到数据库中,当用户访问时页面会将数据库的查询结果显示到页面上
<svg/οnlοad=confirm(17)>
页面会不断的弹出一个弹窗
点击删除,又会出现上面的弹窗 (我也不知道为什么会这样子)
DOM型xss
DOM XSS的XSS代码并不需要服务器解析响应的直接参与,触发XSS靠的就是浏览器端的DOM解析,可以认为完全是客户端的事情,无法通过WAF防护。
js中,从url中获得参数并将其作为js执行,就有可能导致DOM XSS
本关我们输入666后,点击click me下面显示出来what do you see?查看前端代码发现666直接赋值给了a标签的href,这就导致了xss漏洞产生.
于是我们直接使用payload触发xss
输入下端的代码
javascript:alert(1)
然后点击what do you see,即可弹出弹窗
DOM型xss-x
继续输入上一关的payload javascript:alert(1)
继续点击
盲打xss
XSS盲打不是一种漏洞类型而是一种xss漏洞的利用方式,攻击者可以在网站留言板、反馈建议等功能点提交恶意的xss payload,如果该网站存在xss漏洞,当管理员在后台查看用户留言页面时就会执行xss payload,xss盲打最主要的目的是通过加载外部的恶意js文件(通过xss盲打平台生成)获取管理员后台的Cookie信息,攻击者就可以使用管理员的身份访问网站后台从而进一步发动攻击
先随便输入一个内容,然后进行提交,发现我们输入的内容并没有在前端显示出来,也就是我们输入的内容 提交到了后台,也就是只有管理员才能看到我们输入的内容
那么如果我们在前端输入了这种跨脚本的内容<svg/οnlοad=confirm(1)>,提交然后发现这个内容也不会在前端进行输出
然后ne.我们模拟管理员进行一下在后台的登录,就会弹出我们输入的内容
xss绕过
既然已经知道有过滤了,那么我们尝试输入一些内容进行尝试
输入一个666,如图
我们再输入一个 <script>,发现内容被过滤了
我们再试一下双写绕过 ,<scrscriptipt>
发现还是无法绕过
那么我们再尝试一下大小写绕过 <SCript>alert(1)</SCript>,发现成功了
查看前端代码
我们再查看一下后端源码,路径如下
发现仅仅对<script进行了过滤
xss之htmlspecialchars
htmlspecialchars() 函数把一些预定义的字符转换为 HTML 实体
输入框的值会成为a标签的href属性
预定义的字符是:
&(和号) 成为&
" (双引号) 成为 "
' (单引号) 成为 '
< (小于) 成为 <
> (大于) 成为 >
htmlspecialchars默认不对'
进行处理,所以此处我们的payload可以设置为1' onclick='alert(1)'
我们咋在这里输入一个javascript:alert(1)
然后点击就会出现弹窗
xss之href
我们在这里直接输入一个javascript:alert(1),然后点击就会出现弹窗
查看源码,会发现我们如果输入单引号,双引号,尖括号都会被过滤掉
如果我们进行防范的话, 只允许在http,https开头的这这个协议,才允许输出,然后再进行htmlspecialchars进行特殊处理,就可以起到一定的防范作用
xss之js
javascript的payload无非就是去构造一个闭合
我们先随便输入一个数据,然后F12查看源代码,然后发现我们输入的内容进入到了script的一个标签
并且呢没有进行闭合,于是我们进行闭合,并且输入一个新的语句x'</script><script>alert(1)</script>
3-csrf跨站请求伪造
Cross-site request forgery 简称为“CSRF”,在CSRF的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接),然后欺骗目标用户进行点击,用户一旦点击了这个请求,整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。
CSRF与XSS的区别:CSRF是借用户的权限完成攻击,攻击者并没有拿到用户的权限,而XSS是直接盗取到了用户的权限,然后实施破坏。
防止CSRF攻击
--对敏感信息的操作增加安全的token;
--对敏感信息的操作增加安全的验证码;
--对敏感信息的操作实施安全的逻辑流程,比如修改密码时,需要先校验旧密码等。
csrf-get
首先我们进行一下登录,使用kobe
点击修改个人信息
修改手机号为6666666,打开抓包,然后点击submit,然后打开burp,点击右键右键请求包 → Engagement tools → Generate CSRF PoC
点击Test in browser
然后点击copy
然后把复制的网站输入到一个新的标签页当中
返回到抓包中点击drop,返回之前的kobe用户页面,由于我们点击的drop,所以手机号并没有成功修改,这时我们将抓包关闭,然后进入刚才复制链接的那个网站,点击submit,点击之后页面跳转至个人信息页面,并且手机号已经发生了改变.
csrf-post
此关与上一关的方式相同,只不过请求的方式发生了改变
csrf token
生成一个token,如果有token,就先进行销毁,然后再生成一个新的token,把token放到session里面,目的是为了下一次提交请求的时候进行对比,同时会把这个token值echo到前端,hidden到前端的页面当中.
token值是不断的在发生变化,刚开始token是这个值
刷新一下后
我们先登录一个账户,比如kevin,然后我们先修改手机号,然后进行抓包,发送到repeater当中,点击send,获取到新的token,然后我们将新的toke替换到前面,并且将性别修改为girl,点击send,发现修改成功
我不理解!!!
4-sql-注入
SQL注入漏洞主要形成的原因是在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的“数据”拼接到SQL语句中后,被当作SQL语句的一部分执行。
MYSQL数据库的包容性比较强,如果你输错了数据的类型,MYSQL数据库会自动将其转换成正确的数据类型,比如输入1)、1"、1-等,只要数字后面的字符不是闭合符的,数据库都会把你输入的错误的数据转换成正确的数据类型。
但是,若输入的数字后面的字符恰好是闭合符,则会形成闭合,若闭合后形成的sql语句是错误的,那么sql语句执行就会错误,从而造成页面显示错误。
数字型注入
SQL注入漏洞主要形成的原因是在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的“数据”拼接到SQL语句中后,被当作SQL语句的一部分执行。 从而导致数据库受损
在这里,我们先选择1,然后点击submit,发现,只出现了一个信息,然后我们进行抓包,并且将后面的id添加 or 1=1,然后我们点击forward,发现页面中出现了全部用户的信息,如图
在这里,我们还可以输入许多的payload,在这就不一一列举了
在这里需要许多mysql的知识
字符型注入(get)
这里我们先随便输入一个username,比如我们先输入kobe,然后查看url中有显示,于是我们开始执行sql注入,在这里,我们开始查看源码
于是我们在这里需要构造一个闭合使用(')
解释一下为什么这么构造而不是kobe or 1=1。
因为原本的程序会自动给你输入的字段加上一对单引号使得sql语句能够被查询
如:正常输入kobe
那么传入后台的语句就是:select 字段1,字段2 from 表名 where usrname='kobe';
而如果我只是简单输入kobe or 1=1的话,传入后台的语句就是:select 字段1,字段2 from 表名 where usrname='kobe or 1=1';
可以看到 kobe or 1=1就被当成了一个整体传输,那么自然系统只会返回“用户名不存在”所以我们构造paylload kobe’ or 1=1#
传到后台就是:
select 字段1,字段2 from 表名 where usrname=‘kobe’ or 1=1#';
这样子的话,首先kobe’标志着一条语句的结束,而#把剩下的那个单引号给注释掉了,最终就能够执行两条sql语句。
接下来的步骤判断字段的个数,看回显点,爆库,爆表,爆字段,都和以上的数字型注入一致,区别就是类型不同,本题为字符型,单引号闭合,其他注入语句和以上一致。
搜索型注入
我们在这里输入一个l,点击搜索,我们发现页面中弹出了如下内容,也就是进行了一个模糊搜索,模糊匹配
而且我们发现上方url有显示,于是我们在这里执行sql语句注入,我们查看源代码
发现这里使用了%进行闭合 ,还是使用上面一样的套路,
爆库:http://127.0.0.1/pk/vul/sqli/sqli_search.php?name=k%' union select database(),2,3%23&submit=%E6%90%9C%E7%B4%A2
爆表:http://127.0.0.1/pk/vul/sqli/sqli_search.php?name=k%' union select group_concat(table_name),2,3 from information_schema.tables where table_schema=database()%23&submit=%E6%90%9C%E7%B4%A2
爆列:http://127.0.0.1/pk/vul/sqli/sqli_search.php?name=k%' union select group_concat(column_name),2,3 from information_schema.columns where table_name='users'%23&submit=%E6%90%9C%E7%B4%A2
爆数据:http://127.0.0.1/pk/vul/sqli/sqli_search.php?name=k%' union select username,password,level from users%23&submit=%E6%90%9C%E7%B4%A2
读文件:http://127.0.0.1/pk/vul/sqli/sqli_search.php?name=k%' union select 1,2,load_file('C:/Windows/win.ini')%23&submit=%E6%90%9C%E7%B4%A2
xx型注入
还是构造一个合法的闭合,在这里还是查看源码
') or 1=1#
sqli基于函数报错的方式来使用
updatexml(1,concat(0x7e,database()),0) or'
//0x7e是十六进制(~)的代码
我们'只需要把database()换成我们想要的语句,就可以获取到相关的数据了
语法:updatexml(xml document, XPathing, new_value)
第一个参数:XML_document是String格式,为XML文档对象的名称,也就是表中的字段名
第二个参数:XPath_string (Xpath格式的字符串)
第三个参数:new_value,String格式,替换查找到的符合条件的数据
insert-update注入
意思即为前端输入的信息最终会通过insert这个操作插入到数据库里面去,原因是因为在接受前端数据的时候没有做一个放sql注入的一个处理
先随便输入一个单引号,然后密码也随便输入一个,点击提交,会发现进行了报错,意味着我们提交的这个内容参与了后台sql的一个拼接.
在这里我们输入' or updatexml(1, concat(0x7e, database()), 0) or '
然后我们就获取到了数据库名称
同样的我们进行登录,登录之后还是在某一栏输入payload ' or updatexml(1, concat(0x7e, database()), 0) or '
然后又会获取到数据库的名称
deleate注入
先随便输入一条留言,然后点击删除,进行抓包
将其发送到repeater
然后再id后面输入这么一段payload 1 or updatexml(1, concat(0x7e, database()), 0)
因为它是通过get请求提交的,所以使用url进行编码
报错函数-extractvalue()的使用
http header注入
了解一下什么是"http header"注入
有些时候,后台开发人员为了验证客户端头信息(比如常用的cookie验证), 或者通过http header头信息获取客户端的一些资料,比如useragent、accept字段等,会对客户端的http header信息进行获取并使用SQL进行处理, 如果此时没有足够的安全考虑则可能会导致基于http header的SQL注入漏洞。
首先我们进行登录
进行一下抓包,发送到repeater,然后修改user agent为' or updatexml(1,concat(0x7e, database()), 0) or '
或者修改cookie ,也会出现上述效果.
sql盲注
什么情况下使用布尔类型的盲注?
没有返回SQL执行的错误信息
错误与正确的输入,返回的结果只有两种
什么情况下使用时间类型的盲注?
页面上没有显示位和SQL语句执行的错误信息,正确执行和错误执行的返回界面一样,此时需要使用时间类型的盲注。
时间型盲注与布尔型盲注的语句构造过程类似,通常在布尔型盲注表达式的基础上使用IF语句加入延时语句来构造,由于时间型盲注耗时较大,通常利用脚本工具来执行,在手工利用的过程中较少使用。
当我们构造一些payload输入进去的时候,并不会把一些多余的内容输出到前端,
在这关,我们首先输入kobe' and 1=2#,会发现没有报错信息,难道这里不存在sql注入漏洞吗?让我们接着尝试,我们输入kobe' and 1=1#
或者是先输入kobe' or 1=1#,会发现提示用户名或密码不存在,然后我们继续输入kobe' or 1=2#,就会出现下图这个界面
由此可见,只有输入为真的时候,才会输出正确的信息 .
我们再这里使用length这个函数做长度的判断
由此得出长度为7,在这里我们输入kobe' and length(database())=7#
接下来我们开始开始介绍time型
在本题中,我们发现无论输入什么都是i don't care who you are
于是我们在这里要考虑一个时间的盲注 .
在这里我们输入kobe' and if(length(database())=7, sleep(1),5)#
意思为:若length(database())=7正确,延迟1秒返回:若不正确,延迟5秒返回
然后经过不断的实验就能得出
宽字节注入
当某字符的大小为一个字节时,称其字符为窄字节.
当某字符的大小为两个字节时,称其字符为宽字节.
所有英文默认占一个字节,汉字占两个字节
宽字节注入是通过编码绕过后端代码的防御措施,列如正则过滤和转义函数转义。
客户端采用GBK编码格式,数据库对用户输入进行转义\ ,转移符\的编码为%5c,添加编码%df,组成%df%5c,此时编码表达为繁体字連,从而绕过转义符让'逃逸。
我们在这里进行抓包,使用以下payload进行sql注入,判断存在宽字节注入,然后forward
kobe%df'+or+1=1#
我们输入kobe%df%27+order+by+2+--+ 页面未报错
然后我们输入kobe%df%27+order+by+3+--+,发现页面报错
接下来使用union联合查询获取数据库名和版本号
kobe%df%27+union+select+database(),version()+--+
5-RCE(remote command/code execute)
ping
在这里我们先输入127.0.01
然后我们在后面拼接一个命令,比如127.0.0.1&&ifconfig
还可以进行以下命令的拼接
127.0.0.1&&dir
127.0.0.1&&whoami
我们在这里对源码进行一下查看,会发现直接对变量进行了拼接,未进行任何处理
evel
在本关,我们直接进行一下代码分析
这里直接用eval执行了post传递过来的txt的值
比如我们在这里直接输入phpinfo(); 它机会直接将我们输入的当作代码执行
6-文件包含漏洞
local
首先我们先上传一个球员名称,然后我们查看一下他的请求
这个请求实际上是上传了一个文件名,然后后台对指定的目标文件去做对应的操作,引文这个文件是前端传到后端的,所以我们可以在前端修改这个文件名,然后上传到后端,
于是我们把这个文件改成后台的固定的一个配置文件
输入..\..\..\..\..\..\windows\system32\drivers\etc\hosts
通过目录跳转的方式,最终会跳到根路径下面
remote
我们先打开配置文件进行修改
修改完成后就不会进行提示了
我们先搭建一个恶意站点,然后将filename后面的路径改成我们的远端路径
fopen在本地去打开一个文件名,然后新建一个一句话木马.php文件
然后把内容填进上面这个文件去,然后关掉,意味着,一旦这个代码被执行,就会在本地生成一个一句话木马文件,里面的内容是一个system函数,接受一个远端的请求传过来的一个x的参数的值,system函数是php下面直接执行系统操作命令的一个函数,所以传过来的参数都会当作系统命令去执行
7-不安全的文件下载
1.不安全的文件下载概述
文件下载功能在很多web系统上都会出现,一般我们当点击下载链接,便会向后台发送一个下载请求,一般这个请求会包含一个需要下载的文件名称,后台在收到请求后 会开始执行下载代码,将该文件名对应的文件response给浏览器,从而完成下载。 如果后台在收到请求的文件名后,将其直接拼进下载文件的路径中而不对其进行安全判断的话,则可能会引发不安全的文件下载漏洞。
此时如果 攻击者提交的不是一个程序预期的的文件名,而是一个精心构造的路径(比如../../../etc/passwd),则很有可能会直接将该指定的文件下载下来。 从而导致后台敏感信息(密码文件、源代码等)被下载。
当我们点这个图片的时候,就会把***.png传到后台,然后后台就会找这个文件,把这个文件读取之后,又会响应输出到前端,浏览器就可以把他下载下来,所以呢,如果后端的代码控制不够严格,这个地方就可能出现漏洞了.一般来说测试这种文件下载漏洞来说,我们可以通过目录便利这种方式去做一个测试.
比如我们在filename后面输入..\..\..\..\..\..\windows+一些配置文件的路径
..\..\..\..\..\..\是一个目录跳转到操作方式,经过多次跳转之后,就会跳到根目录下面,然后就会直接把这个文件下载下来,
8-不安全文件的上传
client check
我们先上传一个php文件,然后他会提示我们上传的文件不符合要求,然后我们看一下这个限制是不是在前端进行的呢,我们点击F12,看一下前端的源码
意思是用in put标签去on change ,就是当他的状态发生改变的时候就会去调用这个checkfileext
我们在这里查看一下后端的源码
事实上在这里就是我们可以看到一个叫做checkfileext这么一个函数,这个函数呢其实就是通过了javascript去对你上传的内容进行了一个限制,
所有在前端进行的操作只能起到一个辅助性的作用
于是我们通过控制台直接把oncheck里面调用的函数给删掉
上传文件的时候一定要知道上传到什么路径下面,如果在实践的过程中,如果没有告诉你实际的上传路径,这就需要我们自己进行一个判断
MIME type
我们首先进行一下介绍
我们还是上传一个php文件,然后后台会进行提示,
我们直接看一下代码
首先呢,他会去获取前端的一个请求,然后定义了一个数组,也就是对应的要上传的图片类型,然后对上传的文件通过tpload_sick函数进行一个检查
我们开始做演示,先上传一个正常的图片,然后进行抓包.会发现contenttype类型为image/jpeg
所以呢,事实上我们只要修改contenttype的类型然后就可以了.这与我们upload靶场一样
getimagesize
对目标文件的十六进制进行一个读取 ,然后读取投几个字符串,看他符不符合这么一个要求
所以呢,我们可以伪造一个图片,前面的内容保持一致,然后在后面插入一些恶意的代码
我这里上传的是一个之前upload做过的图片马 ,这也算成功了,里面又一句话木马的php
然后我们再来讲一下防范措施
9-Over permission
水平越权
我们首先进行登录,然后点击查看个人信息.然后查看上面url,发现提交的是一个get请求,因为我们首先登录的是lucy,那么我们如果把lucy名字换成其他的,是不是也能查看到别人的信息呢?然后我们进行一下操作,将lucy换成lili发现成功的查看到了lili的信息.
垂直越权
我们首先拿超级管理员的账号进行登录,超级管理员具有添加用户的功能,我们在这里添加一个账户
抓一下包,提交的是一个post请求,我们发送到repeater,然后再火狐上退出登录,然后send,点击一个重定向,然后就直接重定向到一个登陆页面,然后我们登录一下,看一下账号有没有添加成功,发现没有添加成功.
然后我们退出登录,用普通管理员的账号进行登录.然后打开burp,把当前用户登录的cookie给他复制一下.然后找到我们刚才之前的那个post请求,将其cookie换成普通管理员的cookie,然后send.回到fire,点击一下刷新,会发现又添加了一个用户
10-目录遍历
目录遍历漏洞概述
在web功能设计中,很多时候我们会要将需要访问的文件定义成变量,从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时,便会将请求的这个文件的值(比如文件名称)传递到后台,后台再执行其对应的文件。 在这个过程中,如果后台没有对前端传进来的值进行严格的安全考虑,则攻击者可能会通过“../”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来,形成目录遍历漏洞。
看到这里,你可能会觉得目录遍历漏洞和不安全的文件下载,甚至文件包含漏洞有差不多的意思,是的,目录遍历漏洞形成的最主要的原因跟这两者一样,都是在功能设计中将要操作的文件使用变量的 方式传递给了后台,而又没有进行严格的安全考虑而造成的,只是出现的位置所展现的现象不一样,因此,这里还是单独拿出来定义一下。
需要区分一下的是,如果你通过不带参数的url(比如:http://xxxx/doc)列出了doc文件夹里面所有的文件,这种情况,我们成为敏感信息泄露。 而并不归为目录遍历漏洞。(关于敏感信息泄露你你可以在"i can see you ABC"中了解更多)
首先我们先点一下链接,发现是传了一个文件名到后台,然后后台对这个文件进行一个读取
于是我们可以通过..\..\..\..\..\..\进行目录跳转
11-敏感信息泄露
由于后台人员的疏忽或者不当的设计,导致不应该被前端用户看到的数据被轻易的访问到。 比如:
---通过访问url下的目录,可以直接列出目录下的文件列表;
---输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
---前端的源码(html,css,js)里面包含了敏感信息,比如后台登录地址、内网接口信息、甚至账号密码等;类似以上这些情况,我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞,但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。 因此,在web应用的开发上,除了要进行安全的代码编写,也需要注意对敏感信息的合理处理。
我们查看源代码,发现前端有注释没有删掉,就可以用这个账户进行登录
或者是我们先进行登录,然后点击F12,打开网络,查看cookie
使用md5解密,就能知道密码
12-php反序列化漏洞
我们提交一个序列化好的内容,如果里面有一个恶意的内容,我们把它提交到后台,因为后台会对数据进行反序列化,会自动地去调用魔法方法.比如我们输入一个
O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
O:1:"S":1:{s:4:"test";s:64:"<script>window.location.replace('http://www.baidu.com')</script>";}
实现网站恶意跳转到指定页面 .
13-xxe
xml的介绍
xxe漏洞发生在应用程序解析XML输入时,没有禁止外部实体的加载,导致攻击者可以构造一个恶意的XML
<?xml version="1.0"?>
<!DOCTYPE ANY[
<!ENTITY f SYSTEM "file:///C:/Windows/System32/drivers/etc/hosts">
]>
<x>&f;</x>
例如我们输入这段代码,就会出现下图内容
14-URL 重定向
我们先随便点击,发现点击第三个跳转到了页面首页,于是
测试直接将此处的url的值改为www.baidu.com发送请求包查看是否会跳转,经测试发现成功跳转至百度,此处存在url重定向漏洞,攻击者可以将该url发送给受害者点击,然后进行钓鱼攻击.
15-SSRF
curl
SSRF漏洞常用协议:
1)HTTP(s):最常用到的一种协议,可以用来验证是否存在SSRF漏洞,探测端口以及服务。
2)file:本地文件传输协议,可以用来读取任意系统文件
3)dict:字典服务器协议,dict是基于查询相应的TCP协议,服务器监听端口2628。在SSRF漏洞中可用于探测端口以及攻击内网应用
4)ghoper:互联网上使用的分布型的文件搜集获取网络协议,出现在http协议之前。可用于攻击内网应用,可用于反弹shell。
如果我们将url后面的内容换成百度的网址,就会再这个页面出现百度.
file_get_content
本关使用了file_get_contents() 函数,该函数将指定 URL 的文件读入一个字符串并返回。
file_get_contents 与 curl的区别:
curl 支持更多协议,有http、https、ftp、gopher、telnet、dict、file、ldap;模拟 Cookie 登录,爬取网页;FTP 上传下载。
fopen / file_get_contents 只能使用 GET 方式获取数据。
我们直接使用file协议读取系统配置文件
file:///c:/windows/win.ini.
所以就pikachu打完....