0、逻辑漏洞概要
1、身份验证漏洞
2、登录验证安全
3、登录前端验证漏洞
4、任意账号密码
5、权限类漏洞
6、其他漏洞
7、SCR中逻辑漏洞检查总结
逻辑漏洞就是基于开发人员设计程序的时候,逻辑不严密,导致攻击者可以修改、绕过或者中断整个程序,让程序按照开发人员的预料之外去执行。
比如某一网页的登录验证逻辑如下:
输入用户名验证–验证成功后输入密码–输入验证码–数据包前端传到后端处理–数据库匹配–匹配成功回包
由于整体网站可能采用前端验证,黑客可以直接篡改或者绕过某些流程,如下:
BP抓取用户名,密码、验证码特定格式–发送给后端匹配
由于网站采用前端验证,导致攻击者可以直接抓取数据包,从而绕过用户名验证的过程。如我们直接把数据返回包中的false改成true,这样就可能成功认证了。或者直接爆破。
简单来讲,只要你能修改、绕过、中断整个开发者运行软件的整体逻辑,这个便是逻辑漏洞,只是绝大部分逻辑漏洞的危害性并不高,比如:开发人员需要你先输入账号,在输入密码;但是你改变了这个逻辑,可以先输入密码,在输入账号,其实这个也是逻辑漏洞,这个漏洞没有任何危害;但是也有可能在某些特定情况下可以结合其他的漏洞可能产生新的风险
前端验证:就是通过前端技术,在浏览器(B/S模式中的B(browser)端)上面可以进行简单的数据检查,不需要后端返回结果。像直接提醒用户不合法,手机号码格式,密码长度限制这些,js代码你在浏览器右键查看页面源代码可以看到。
比如SQL注入:
程序的开发者也没有想过你可以拼接他的语言产生他预料之外的危害,他不过是按照程序逻辑完成了整个查询的动作
那么为什么会产生逻辑漏洞就很容易理解了:研发只负责满足客户的需求,大部分的研发并不懂安全,所以并不会带着黑客的思维考虑这个软件的安全。
程序的本质就是按照研发设计的逻辑运行,这个过程中出现的所有漏洞,皆可以为逻辑漏洞。
逻辑漏洞的分类(从漏洞的本质上):
1、第一点很好理解,比如永恒之蓝,sql注入漏洞、文件上传等等,均为设计的时候未能按照安全设计的方法进行,所产生的,攻击者只需要找到特定的点,执行特性的代码即可产生研发预料之外的现象
2、第二点的关键在于使用者,比如弱口令,比如匿名用户;程序开发者会设计很多便捷的功能,但是由于使用者使用不当,产生了新的问题
但是我们本节课的目的,为web逻辑漏洞,去除常见的漏洞大类,比如:sql注入、文件上传等等;我们也将讲讲部分不好分类,但是在业务测对用户有影响的漏洞,下文中的漏洞
暴力破解漏洞:使用bp里面的intruder模块。如果登录网站需要输入验证码并且验证码相对简单,这时就可以用pkav工具来尝试。
字典方面,可以自己去github上搜集常见的密码本,最好能够形成自己的密码库。
遇见复杂但是又需要爆破的网站,需要自己根据网站的具体信息编写脚本,才能更好地达到爆破的目的。
未限制爆破,即对于用户登录的地方没有做什么限制爆破的策略,因此对于这个地方可以直接使用bp来抓包放进intruder模块爆破,参考dvwalow关卡或者pikachu《基于表单的暴力破解》,不做详述。
某些具有安全意识的开发人员或运维人员,针对账户爆破问题就会使用限制攻击者IP的方式,当在短时间内有大量来自该IP的尝试登录现象时就会封锁该IP,导致该IP无法使用——》针对这种情况,建议自己写脚本,调用git开源的代理API来爆破;当然也可以直接用别人的轮子。
代理池就是一个存储了很多ip的地方,每次你访问网页的时候都会从代理池中抽取一个ip来进行网页的访问,这样就能避开ip限制。
自建轮子的方法:首先需要新建一个代理池:现在好用的一般是收费版本,这里可以自行购买,我这里拿一个代理举例,然后使用python调用代理池进行爆破。
import requests
import re
def post():
curl = "你网站靶机的IP"
proxy = {'http':'127.0.0.1:8080'} #代理地址以及端口,现在估计已经失效,如果需要使用,可以自建资源池
post = requests.get(curl,headers=header,proxies=proxy).text #请求报文
print(post) #打印网站
if __name__ == '__main__':
post()
案列讲解:python脚本结合bp抓包
有些网站管理员会限制某个账号的登录次数,如果超过限制次数,账号就会被锁定,除非管理员解锁或者设定一段时间过后自动解锁。
由于他限制了一个账号的输错密码次数,比如只允许输入5次,但是不限制你换个账号又可以输错5次(前提条件),对于这种情况,通常可以采用弱密码反过来爆破账户的方式,即设置任意的不超过爆破次数的弱密码数量来反过来爆破用户名。
但是如果管理员的设置是不管你换了什么账号,连续输入错误的次数都不能超过5次,那么这种方式就没有办法了。
多字段爆破即需要爆破多个字段大于等于2,比如说:需要同时爆破:账号密码验证码,当我们爆破一个网站时返回信息是用户名或密码错误时,大多数时候仍然使用burpsuite的Intruder模块。
但是如果不仅需要输入网页中要求填写的内容,还要从返回的数据包中拿取cookie或者session或者token的值,可以使用BP的特定模式进行爆破,也可以自己写脚本解决问题。
实验案列为:pikachu的token爆破
添加需要爆破的参数+选择攻击类型:
填写第一个需要爆破的字段的有效负载:
填写第2个需要爆破的字段的有效负载:从服务器的回报拿取cookie
勾选“从响应中提取以下项目”,然后点击“添加”:
点击“获取回复”:
选定cookie字段:
设置payload类型:
线程数改为1:
但是有些很复杂的情况下,bp里面的正则匹配都没有办法解决。这种情况下我们就会去编写一个脚本。
purl = "http://192.168.1.157/pikachu/vul/burteforce/bf_token.php" #这里需要修改
user_token = "27536628ca8f3b0818871451285" #第一个token值
proxy = {'http':'127.0.0.1:8080'} #设置代理后可以结合bp看看发送的报文,从而判断自己的脚本哪里写的不对
header = {
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0',
'Cookie': 'PHPSESSID=17u0i2fakm84eq9oc24boc8715'}
def token(response):
user_token = re.findall('value=".*."', response)[0][7:-1] #从返回包中取出token;value=".*.是个正则表达式(去站长之家上有帮我们写正则表达式的功能)
return user_token
def uandp(user_token):
f = open('result.csv', 'w') #把爆破结果储存到文件里,这里为csv格式
f.write('用户名' + ',' + '密码' + ',' + '包长度' + '\n') #给文件设置标题
sum = len(open("p.txt").readlines())*len(open("u.txt").readlines()) #密码本的总数量,得出总进度
dan = 0 #dan变量表示目前进度
for u in open("u.txt") : #从u.txt中取出每一行的值
for p in open("p.txt") : #从p.txt中取出每一行的值
u = u.replace("\n","") #过滤掉回车符
p = p.replace("\n","")
session = requests.session() #会话保持
data= {'username':u,'password':p,'token':user_token,'submit':'Login'} #我们要传入的post的初始数据
response = session.post(purl,data=data,headers=header).text #得出回显页面
user_token = token(response) #把response发给token这个函数
result = u + ',' + p + ',' + str(len(response)) #result记录着用户名密码以及响应包长度
f.write(result + '\n') #把户名密码以及响应包长度这些信息输出到文件
dan = dan + 1 #进度加1
print("进度:"+str(dan)+'/'+str(sum)) #输出到终端
# print(response)
f.close()
if __name__ == '__main__': #条件成立,就运行uandp模块
uandp(user_token)
我们还可以魔改这个脚本,可以改成多线程多进程的,这样就可以变快!
注意点:一定要有u.tx(用户名字典)t,p.txt(密码字典),result.csv这几个文件
限制登录频率爆破即限制在一定的时间内爆破的次数,比如10分钟内只允许爆破10次,对于这种方式可以采用延时爆破的方式,但是可能需要时间比较久,但总比手工爆破舒服,在bp上如下文设置,该时间以ms为单位(1000ms=1S)
Authorization爆破,狭义上单纯指basicbase64爆破,比如tomcat的密码在传输的时候,是采用base64编码的,而广义上可以泛指经过编码过后的用户名与密码。
下面我们以tomcat的basic爆破举例:环境可以采用vulhub的tomcat8环境
cdvulhub-master/tomcat/tomcat8#路径
docker-composeup-d#开启环境
#后台路径为:http://192.168.10.223:8080/host-manager/html
实验演示:BP爆破
选择爆破位置和爆破类型:
添加攻击载荷(字典)+对payload的处理–base64编码:
如果网站是采用md5加密的话,BP里面我们就选择md5编码
(和上面的authorization使用BP爆破是相同步骤)!
渗透测试中,有时会遇到密码从客户端到服务端中间通过前端js代码将密码加密后,在发送给服务器,所以这个时候,我们可以采用bp上自带的加密方法进行加密。
常见的加密手法有MD5或者RSA;如果需要JS的复杂加密,也可以读懂JS的加密逻辑自定义Python进行爆破,或者使用python的pyexecjs包来帮助你执行JS文件复现加密方法。
常用的在线网站:大小写转换、base64加密、md5加密
网站有复杂的加密的爆破举例:
在网站进行登录,并让BP抓包:
抓包,发现密码部分应该是经过了加密:
所以我们现在想要去网站源码中寻找描述加密规则的语句。
先用开发者工具查看,我们输入的密码在源码中的变量名是什么:
发现存储我们输入密码的变量名叫txt_password,于是我们就在源码中搜索txt_password字段:
把这段代码复制出来,然后继续寻找这段代码中的txt_password字段
了解到加密规则:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hkcpg3kG-1681261858890)(typora_photo_逻辑漏洞/image-20230410190159164.png)]
然后我们就可以根据他的加密规则编写脚本。
session:用于网站需要持续连接(会话)的时候。session相当于就是告诉服务器我们已登录的一个证明。
漏洞介绍:会话固定攻击是利用服务器的session不变机制,借他人之手获得认证和授权,然后冒充他人;session是登录成功后网站才会给我们的。我们可以把别人已经成功登录的session拿去过来,然后拿去登录。
session失效:在网站中退出登录后,或者是在网页中超过一定时间没有经过操作后就会自动退出登录。
漏洞原理:在请求登录过程时候,URL带有一个session,登录成功之后会将登录成功的信息绑定到这个session中,攻击者可以发送带有session的URL给相关工作人员诱导其登录,相当于获取了其身份信息
漏洞点:在GET方法请求登录时候带有session值——参数和值都在url中,所以我们就可以拿到session
举例:如果我们登录一个网站后会看到url后面有一堆好像乱码的东西,我们就可以把这个带乱码的url复制下来,然后开启浏览器的无痕模式把url复制进去。如果复制完后发现不需要我们进行登录就已经登录成功的话,我们这个网站是存在session漏洞的。
危害:只要黑客抓取到你和网站通信的报文,找到了session,我们就可以不需要账号密码以别人的身份登录网站。
修复思路:只要避免在URL中带入session信息即可比较有效的防御另外也要注意POST请求中带有sessionid进行session固定攻击,虽然可利用性比较低,但是建议修复如下,测试方法可以直接赋值session然后更换浏览器打开或者使用无痕模式打开即可,如果直接访问,不需要登录,说明存在该漏洞
cookie:cookie是保存在电脑本地的,用户成功登录后服务器才会办法;他相等于一个令牌,保存了用户在网站中存储的数据。
漏洞介绍:通过伪造cookie信息能够伪造其他用户进行登录。
漏洞原理:开发者为了方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在cookies中,网站通过获取得到的cookies进行授权或者身份验证
漏洞点:cookie中有明显或者只是简单编码、哈希的字段时候修改lsLogin值为1可以判定为用户已经登录
漏洞修复:Cookie不应该存储可理解的身份信息和登录信息。按照规定,cookie对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行,避免篡改如果某网站的cookie:asp163=admin,那黑客只需要等待管理员登录成功、网站存在登录信息后即可进行登录,构造报文进行登录,安装editthiscookie可以迅速看cookie值。
Cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单,导致黑客可以对cookie的效验值进行一个枚举。
有的网站的cookie更简单,直接采用以用户名、邮箱号或者用户ID等来作为cookie的判断标准。或者是单纯对用户的cookie做个简单的md5或base64的加密———》这样的话,黑客只要知道了加密规则以及cookie值的选取方式,那么就可以伪造cookie,等到这个用户上线后进行登录。
cookie的查看:在已经登录网站的情况下,按住F12,点击“控制台”,在最底下的命令行中输入document.cookie就能搜索到cookie值
如果黑客偷到了这个cookie后,把这个cookie输入到他自己的网页里的请求包后就可以登录了。
点击退出登录以后,cookie就会被销毁,只有再次成功登录后服务器才会颁发cookie。
有些业务的接口,因为缺少了对用户的**登陆凭证(session和cookie就是凭证)**的较验或者是验证存在缺陷,导致黑客可以未经授权就可以访问这些敏感信息甚至是越权操作。
案列一:后台页面访问
某电商后台主页面,确实凭证的检查,不需要账号密码登录,直接在管理员web路径后面输入main.php之类的即可进入。——使用御剑或者扫描器,扫描网站的后台,然后看到了admin/main.sapx之类的路径,我们就可以去尝试。
案列二:某航天公司订单ID枚举
因为我们会发现这个订单实际上是有规律的。
验证码可爆破,即验证码过于简单,例如验证码中字符数量过少,比如只有四位组成,且只包含0-9的数字还没有干扰点(比如两个字母连在一起,这样会导致机器做不了很好的识别),亦或者验证码可以被猜测到(这种情况很少见,但并不是没有)
可以使用PKAV工具来进行带验证码的爆破,先用burpsuite来抓包,再将抓取的数据包放在pkav里,pkav里面就有验证码的识别功能。甚至可以使用python调用api,或引入智能算法的计算来识别验证码。
验证码复用,即登录失败后验证码不刷新,仍然可以使用上一次登录时的验证码且有效,这样就存在爆破风险漏洞。
如织梦后台的验证码就有这种漏洞,而且导致织梦后台有这个漏洞的原因是织梦使用的框架V57有漏洞。只要一个版本的框架中有这个漏洞,那么所有使用该版本框架的软件都会有这个漏洞。
测试方法如下,抓包后输入对的验证码后,反复发送查看回包可以看到,没有出现验证码错误,出现的是用户名不存在,那么这里还出现一个点,用户名爆破,只要输入账号错误和密码错误回显不一样,就可以算成用户名可爆破漏洞。
而且只要验证码正确一次后,他的验证码貌似就不会修改了。这个时候我们把数据包丢给intruder就行了,在intruder中开始爆破账号密码,不用在意验证码了。
验证码绕过,即验证码可以通过逻辑漏洞被绕过,通常分为以下情况:
• 案列一:验证码验证返回状态值
原理:验证码传到后端后,后端实际上只是负责进行验证码的匹配。决定用户是否能够成功登录的是前端,而前端是通过后端发送的报文中是false还是true来判断用户能否成功登录的。
我们拦截请求后可以修改数据包:
但是最好的办法是先拿到一个成功登录的报文,查看登录成功后url会跳转到那里——我们在修改一个报文的时候不仅仅是要把status的值由n改成y,还需要把url也给填充了。
• 案列二:点击获取验证码时,直接在返回包中返回验证码,通过抓包的来观察reponse包(还不懂)
解释:这种情况就是,你在请求验证码的时候抓一个包,点击burp中的Do intercept 然后再forward 放包,验证码有可能会出现在返回包中。
验证码的客户端验证**:验证码的生成和验证码的校验**都在客户端进行(有客户端的js代码实现的),只要验证码没有输入正确,数据包就不会被发送。只有验证码输入正确后,数据包才会发送。而后端是完全没有验证码检查的机制的。
通过查看源代码发现验证码是前端验证码,可以通过直接抓包的方式在bp里边爆破,参考pikachu-bf_client.php
验证有无客户端验证漏洞的方式:开启BP,然后在登录网页中点击更换验证码,看BP中有没有抓到登陆页面的前端发送的POST请求来向后端索要新的验证码。
绕过方式1:
只要验证码输入正确,通过前端校验后,我们用BP抓到包后,一直发送数据包都不会有任何问题;就算把验证码修改掉了也依旧能够正常发送数据包。
绕过方式2:
直接把验证的代码给删除掉:
删掉以后就相当于那两个框框的js代码就不会被前端引用了。
如下,某网站存在一个链接http://1XX.XX.XX.XX:9080/setup访问这个重置链接,点击修改管理员密码,可以重置密码,但是我们不知道旧密码是多少,只能输入新密码.
我们就随便输旧密码,然后输入一个自己定的新密码。然后服务器回包的时候,数据包里面就会有一个false的字段,我们把这个字段改成true后我们再放行,此时会显示修改密码成功。
有验证码模块,但验证模块与业务功能没有关联性,此为无效验证(也就是我们随便输入一串数字都能通过验证,这个验证码就是假的),一般在新上线的系统中比较常见。
最好在做测试的时候先试一下,有很小的概率可以成功。
下面用一个案例进行举例说明:获取短信验证码后,随意输入验证码,直接输入两次密码,可成功更改用户密码,没有对短信验证码进行验证
短信轰炸是手机验证码漏洞中最常见的一种漏洞类型。在测试的过程中,对短信验证码接口进行重放,导致大量发送恶意短信有两种情况,一种是完全没限制发短信的频率,另外一种是每60秒发一条短信。
情况一:没有限制时,任意下发短信时,直接放到Intruder中,一直发送就可以了。
情况二:发送验证码有一定时间间隔。
在测试过程中,可通过编写Python脚本来计算短信下发时间间隔,实现短信轰炸。我们只要能找到60个这样的网站,然后每个网站都使用py脚本进行调用,这样就能达到1s给别人发送一条短信(短信轰炸)
python脚本的编写可以参考上文
当在**“忘记密码”页面**,输入邮箱或者手机号后,网站会给手机或者邮箱发送验证码。用户输入验证码后,服务器会将其与正确的验证码进行对比,若相同则验证成功并进行下一步操作。网站还贴心的考虑到了:万一用户手抖输错怎么办?有两个选择:
第一个:客户重新填验证码。网站本来想着用户这次能输对了吧,没想到用户不停的手抖输错,短信不断的发到手机上**(这是短信炸弹漏洞)**。一条短信一毛钱啊,网站掏不起啊,那就试试方法2吧。
第二个:验证码再输一遍。在这种情况下,极易产生验证码爆破漏洞。
你可能会觉得输入一万条数据简直太漫长了,但是要知道我们发到网站服务器的都是数据包,验证码就在数据包中。我们只要不断的修改数据包中验证码的参数即可完整验证尝试攻击方法,如果是4位,没有多余的防御措施,直接爆破即可。
可能的防御措施:只允许验证码输入3-5次。
客户端验证是不安全的,可能导致任意账号注册、登录及重置任意用户密码等一系列问题。除了之前讲到过的把服务器的返回报文中的n改成y这一种绕过方式,还有以下几种奇奇怪怪的返回报文:
1.返回报文种直接返回明文验证码。
案例:输入手机号后,点击获取验证码。按F12调出开发者工具,然后在网络中,监听到两条json数据,发现本应该发送给用户的手机短信验证码就藏在返回数据表的ticket字段里面。用这个字段值尝试登录,发现能够登陆成功。
2.返回加密后的验证码。加密报文在应答数据包中,返回客户端,用户解密后即可获取验证码。
在修改自己的密码时,看看可否把自己的账号换成别人的(用户名/邮箱/手机),达到修改其他用户密码的目的。
首先在一个网站注册一个用户,然后修改这个用户的密码,通过抓取数据包中的参数判断哪里是校验用户,通过修改关键参数,达到任意修改其他用户密码的目的。
下面对一个网站进行模拟攻击,以便于在攻击中讲解能够更深刻的理解。
3、攻击者收到网站给的验证码(到这里都是正常的网站找回的逻辑)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iJmhNOsl-1681261858891)(typora_photo_逻辑漏洞/image-20230410235604468.png)]
4、继续填写验证码,发现还是没有什么可以利用的数据,放包过去
5、 到了修改密码的界面,填好密码后点击下一步。抓包后,观察发现这里写入了用户名和密码。
可以先右键报文,然后 Send to Intruder 之后可以爆破用户名,并将其修改为同 一个密码。 不过这里只是测试一个叫 zhagnwei 用户名,这是我们之前爆破出的一个其他的用户,如下图所示
6、发送之后,发现修改成功(这里漏洞点:原因是没有对校正的账号和修改的账号进行匹配,导致可以先通过用户验证后,去修改别人的密码)
在用户更改密码和找回密码时,会发送一个验证码到手机。填写正确验证码后,后台会在返回的报文中通过状态码来进行正确的判断。
这个时候可以通过修改返回报文中的参数(修改url和false),使页面跳转到写一部认证的页面。
(这个方式和思路就和之前讲过的一样)
在找回密码的界面,发现是通过填写手机号和返回的验证码进行身份认证。
先填写一个想要修改的手机号,验证码随意填写一个。再打开浏览器代理和 Burp 的截断,这时候点击提交后,会抓取一个
请求的数据包。再右键点击报文内容,选择如下图所示。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mUMOziey-1681261858891)(typora_photo_逻辑漏洞/image-20230411001633016.png)]
如果不知道要改成1还是改成什么,我们可以先弄一个返回成功的数据包,这样我们就知道接下来要填写什么了。
通过邮箱找回密码时,邮件中将出现一个含有==token的重置URL,该token即为重置凭证==。
从经验来看,开发人员习惯以时间戳、递增序号、关键字段(如邮箱地址)等三类信息之一作为因子,采用某种加密算法或编码生成token;攻击者可以基于能收集到的关键字段,用常见加密算法计算一遍,以判断是否可以预测出token。
下面举两个案例加以说明。
实验一:基于时间戳生成的token,这是一个靶场:
http://lab1.xseclab.com/password1_dc178aa12e73cfc184676a4100e07dac/
抓包,发现一坨好像乱码的东西,感觉就是token;然后根据感觉和经验判断这个是根据md5加密的,于是我们用md5进行解密:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mz2j5KzP-1681261858892)(typora_photo_逻辑漏洞/image-20230411002557226.png)]
发送2次数据包得到2次解码后的token后发现他们相似度很大。
然后会发现这个token值就是按照Linux的时间戳来变化的:
而且发现输入admin输入后没有返回token,那么我们根据上面的规律就可以自行创造一个admin的token。
操作流程:
发送一个aaaa,然后发送一个admin,然后发送一个bbbb。那么虽然admin的返回包里面不显示token,但是我们可以通过aaaa和bbbb的返回包推断出admin的返回包中的token的范围,然后就爆破就行。
案例二:基于关键字段生成的token某网站密码找回功能
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cw7MasOe-1681261858893)(typora_photo_逻辑漏洞/image-20230411003638851.png)]
登陆状态下修改自己的密码时,通过修改截获的数据包,将部分参数替换,从而偷龙换凤的将他人的密码修改为自己指定的密码。下面通过实例讲解。
案列如下:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TTPxZePJ-1681261858894)(typora_photo_逻辑漏洞/image-20230411004003567.png)]
密码找回流程一般包括获取短信验证码、校验短信验证码是否有效、设置新密码等三个步骤。
在第二步,校验短信验证码是否有效的结果应保存在服务端,某些网站未在服务端保存而是错误地将结果状态值下发客户端,后续又依靠前端js判断是否可以进入第三步(有漏洞了)
那么,更改应答包中的状态值,可重置其他用户的密码。下面用两个案例分析说明。
案例一:在密码找回页面http://www.xx.cn/yy/action/forgot用攻击者手机号13908081024进入密码找回流程:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w19GLhcY-1681261858894)(typora_photo_逻辑漏洞/image-20230411004426046.png)]
案例二:在密码找回页面http://www.xx.cn/yy/forgot用攻击者手机号13908081024进入密码找回流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6twZZe5l-1681261858895)(typora_photo_逻辑漏洞/image-20230411004820693.png)]
在一些大型公司或者学校的的网站上,会有介绍用户注册的指导手册,里面会介绍用户的用户名和默认密码。这时可以先用默认密码尝试爆破默认密码;或者寻找重置密码的选项,重置密码后,用默认口令尝试登陆,因为可能会未授权修改网站用户的密码。
未验证邮箱/手机号,目前很多应用为了方便用户记录自己的用户名与密码,都可以使用邮箱跟手机号作为录用户名,因此很多应用在注册的时候就要求用户填写,一般情况下该应用都会发送激活信息,用户在收到激活信息后才能登录; 然而有时候开发人员并不去审核邮箱/手机号是否有效(也就是不往手机号和qq发信息和邮件来验证有效性),所以可以利用该缺陷,任意注册账号填写邮箱后,并没有在邮箱发现任何激活信息,且直接把邮箱当作用户登录名使用。
脚本批量注册造成服务器dos应用层攻击,影响网站的正常使用,通常由于上边无验证码或者验证码不安全(验证码不安全就是说是很简单的图片验证码;或者验证码只在前端校验,后端完全没有校验功能。这样的话我们可以通过pkav工具进行图片验证码的验证,使用BP绕过验证码的校验),导致可以写脚本来批量注册,只要我们注册的量很大,他的数据库和服务器就会受不了。
若出现身份证信息注册,且**网页没有身份证的验证、真实姓名的验证**,那么就相当于网页的这个字段和其他字段没啥区别,可任意构造填写于身份证与姓名字段。
任意填写注册信息,服务端对注册信息进行审核,例如是否存在恶意标签等恶意信息,但是通过返回状态值给前端判断,一旦篡改该值就有可能绕过!!(之前也讲过很多这样的)
第一步,使用正常账号修改密码,获取验证码并通过后,服务器返回数据,保存该数据包中的信息(后面在错误包中我们需要使用)
第二步,使用burpsuite或fiddle,之后点击确定,服务器会返回验证码错误之类的信息,使用正确的信息例如{“MessageHeader”:{“MessageID”:“RSP036”,“Description”:“成功!”}}进行替换后再执行,注册成功。
具体测试方法和验证码的前端验证同理,这里不再赘述
为防止恶意用户任意注册账户,大多数网站会在用户注册中输入邮箱/手机号后对其真实性进行验证。
但是有时候==返回的验证信息会直接隐藏在返回包中,只是不在前端显示出来,或者是可以通过抓包改包手机号/邮箱,伪造该信息,劫持到验证信息==。
以某验证信息返回为例,该漏洞是在发送验证信息时会将验证信息同时发送到返回包中并将其在前端用hidden属性隐藏其值,所以**直接前端源代码查看**即可。
渗透测试中,某些不严谨的开发人员,对于注册时,当输入用户名时不会对之前数据库中存在的用户名进行检查,判断是否已经存在。
情况一:登录查看时却获取到数据库中同名用户的其他用户信息,导致其他用户信息泄露。
情况二:由于验证用户名存在时,从前端获取到的数据与从数据库获取到的数据不同,但是往数据库中写入的时候却写了相同的部分造成了用户的覆盖。
情况三:登陆时,当检测到是管理员用户名admin就给与管理权限
越权漏洞又分为平行越权,垂直越权和交叉越权(交叉越权先不用管)。
system用户是Windows中专门用来管理软件的用户;而admin用户是管理用户的最高权限者。所以这两个实际上是平级的,实际中这两个可以相互转化,这就是平行越权。
水平越权指的是攻击者尝试访问与他拥有相同权限的用户的资源,怎么理解呢?
比如某系统中有“个人资料”这个功能,A账号和B账号都可以访问这个功能,但是A账号的个人信息和B账号的个人信息不同。可以理解为A账号和B账号个人资料这个功能上具备水平权限的划分。此时,A账号通过攻击手段访问了B账号的个人资料,这就是水平越权漏洞。
系统中所有具备水平权限划分的功能,都存在水平越权的风险,以下是常出现的水平越权的功能的几种场景:
案列1:基于用户身份ID
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VzUm8EqO-1681261858896)(typora_photo_逻辑漏洞/image-20230411101015338.png)]
案例2:基于对象ID
案例3:基于文件名
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xnna8jaK-1681261858896)(typora_photo_逻辑漏洞/image-20230411101806172.png)]
垂直越权指的是一个低级别攻击者尝试访问高级别用户的资源。比如说某个系统分为普通用户和管理员,管理员有系统管理功能,而普通用户没有,那我们就可以理解管理功能具备垂直权限划分,如果普通用户能利用某种攻击手段访问到管理功能,那我们就称之为垂直越权。
案例1:
如果是通过前端js来进行验证的,而前端的js代码又是保存在我们电脑本地的,那么我们就可以通过删除前端的js代码来达到绕过检测。
比如下面示例中,我们就把alert和location给删除掉就行(这里面的location就是非法操作后会把我们跳转到的网页的地址)
漏洞介绍:通过数据包重放,可以造成短信轰炸、邮件轰炸、重复提交订单等
漏洞原理:后台未进行相关操作的技术导致数据包重放漏洞点:短信验证码、邮件校验、提交订单等功能。
修复方案:修复思路(针对短信、邮件)
构造一个Hashmap
只要某个邮箱或者电话号码次数够了,就不能继续发送了或者计算两次发送的时间间隔,时间过短就不继续发送了
通用修复方案:需要建立token机制或验证码机制,一次有效
就是之前讲过的那些,会导致短信轰炸、邮件轰炸、重复提交订单的所有漏洞都可以说是存在“数据包重放漏洞”,所有不用懵逼。
漏洞介绍:条件竞争是指一个系统的运行结果依赖于不受控制的事件的先后顺序。当这些不受控制的事件并没有按照开发者想要的方式运行时,就可能会出现bug(漏洞)。尤其在当前我们的系统中大量对资源进行共享,如果处理不当的话,就会产生条件竞争漏洞。说的通俗一点,条件竞争涉及到的就是操作系统中所提到的进程或者线程同步的问题,当一个程序的运行的结果依赖于线程的顺序,处理不当就会发生条件竞争。
漏洞修复-修复思路:限制同一时间内访问方法的只有单一线程
案列与实操如下:
如果网站检查到我们上传的不是.gif\jpg的文件,就会把我们的文件删除。所以梳理一下,网站的删除流程是先判断是不是白名单允许的文件格式,如果不是就删除;
我们的攻击思路:因为网站是先判断再删除,所以我们只要在网站把我们写好的“一句话木马的php文件”(用于生成木马,只要这个文件被访问一次就会生成木马)删除之前执行一次我们的php文件,那么我们就可以getshell了。所以我们就一直用BP进行数据发送,然后写一个py脚本来不断发起访问,只要发的够快让网站删除速度来不及,那就我们就有机会访问我们的php文件。
py访问脚本:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8XoeAzcb-1681261858897)(typora_photo_逻辑漏洞/image-20230411105058217.png)]
BP不断发送数据包:
如下图,py脚本显示成功访问页面:
很多中小型的购物网站都存在【订单金额任意修改】漏洞。在提交订单的时候抓取数据包或者直接修改前端代码,然后对订单的金额任意修改,就可以实现0.1元支付,甚至还可以把货物的数量进行修改。还可以尝试把货物数量和价钱改成负数。
经常见到的参数大多为:rmb、value、amount、cash、fee、money
关于支付的逻辑漏洞这一块还有很多种思路,比如相同价格增加订单数量,相同订单数量减少产品价格,订单价格设定为负数,无限叠加优惠券等等
有些关键性的接口因为没有做验证或者其它预防机制,容易遭到爆破攻击。常见账号爆破,密码爆破,验证码爆破,上文都已经提及,还有其他的:
快递公司的优惠券枚举:因为都是数字,所以直接BP枚举爆破,分为4段payload来爆破就行。
某电商会员卡卡号用BP枚举爆破——4位卡号
支付漏洞是高风险漏洞也属于逻辑漏洞,通常是通过篡改价格、数量、状态、接口、用户名等传参,从而造成小钱够买大物,甚至可能造成0元购买商品等等,凡是涉及购买、资金等方面的功能处就有可能存在支付漏洞
商户网站接入支付结果,有两种方式,一种是通过浏览器进行跳转通知,一种是服务器端异步通知。
1.浏览器跳转通知:
基于用户访问的浏览器,如果用户在银行页面支付成功后,直接关闭了页面,并未等待银行跳转到支付结果页面,那么商户网站就收不到支付结果的通知,导致支付结果难以处理。而且浏览器端数据很容易被篡改而降低安全性(这种方式数据经过了客户端浏览器,极大的可能性被第三方恶意修改)
2.服务器端异步通知:
该方式是支付公司服务器后台直接向用户指定的异步通知URl发送参数,采用POST或者GET的方式。商户网站接受异部参数的URL对应的程序中,要对支付公司返回的支付结果进行签名验证,成功后进行支付逻辑处理,如验证金额、订单信息是否与发起支付时一致,验证正常则对订单进行状态处理或为用户进行网站内入账等。
上面的描述看不太懂。简单来说就是我们支付的时候向银行发起数据包,然后银行不会回报给我们用户前端,而是发送个数据包给商铺告诉他支付成功还是失败,这样就避免经过前端了,危险减少了。
下面的案例都是基于第一种支付方式产生的漏洞:
案例1、支付三步曲——订购、订单、付款
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9FLmQJyf-1681261858898)(typora_photo_逻辑漏洞/image-20230411112857815.png)]
案例2、 重放交易
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oFA0FkFk-1681261858898)(typora_photo_逻辑漏洞/image-20230411112921929.png)]
案例3、修改商品数量:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ezpJqWz7-1681261858899)(typora_photo_逻辑漏洞/image-20230411112956321.png)]
案例4、修改支付状态:
没有对支付状态的值跟实际订单支付状态进行校验,导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功
案列:同程旅交汇低价支付高价订单订单随意修改
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IROp9N2H-1681261858900)(typora_photo_逻辑漏洞/image-20230411113119973.png)]
通过修改一些**特殊传参(如:id,username,openid)**来达到用他人的资金来干购买自己的商品。
案列如下:
案列:小程序越权积分兑换
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eoSzJgOT-1681261858900)(typora_photo_逻辑漏洞/image-20230411113719077.png)]
通过修改特殊传参(如:id,pay,test)来达到无限制试用。
案列:艺龙旅行网严重支付漏洞——因为支付的时候只校验信用卡的有效期限
1、找到关键的数据包
可能一个支付操作有三四个数据包,我们要对数据包进行挑选。
2、分析数据包
支付数据包中会包含很多的敏感信息(账号,金额,余额,优惠),要尝试对数据包中的各个参数进行分析。
3、不按套路出牌
多去想想开发者没有想到的地方。
4、pc端尝试过,手机端wap也看看,app也试试
防御方法
1、在后端检查订单的每一个值,包括支付状态;
2、校验价格、数量参数,比如产品数量只能为整数,并限制最大购买数量;
3、与第三方支付平台检查,实际支付的金额是否与订单金额一致,避免在银行只支付了1块钱,却拿着跳转报文到前端;
4、如果给用户退款,要使用原路、原订单退回,反制黑客对数据包进行处理让原本应该退给A的钱退给了B。比如:退押金,按用户原支付订单原路退回;
5、MD5加密、解密、数字签名及验证、加盐值、加混淆,这个可以有效的避免数据修改,重放攻击中的各种问题;
6、检测金额是否超过指定值(比如网站没有1块的东西,如果有订单是1块钱,就直接不允许),
7、进行人工审核等
把下面的内容逐个检测,这样网站中的所有逻辑漏洞也就被我们检查完了。
1.注册:
2.登录(是需要和数据库连动的):
找回密码:
会员系统:
传输过程
评论
验证码问题
短信轰炸
数据泄露
任意用户密码重置
支付逻辑漏洞
登录绕过
部分网站的身份验证放在了前端,因此只需要将response包中的相关字段进行修改,比如0改成1,false改成true,就可以登录任意用户账号。(虽然少,但是只要找到一个,就是高危)
水平越权
垂直越权
回密码处,填写数据后抓包查看返回信息,有可能存在敏感数据返回
任意用户密码重置
支付逻辑漏洞
登录绕过
部分网站的身份验证放在了前端,因此只需要将response包中的相关字段进行修改,比如0改成1,false改成true,就可以登录任意用户账号。(虽然少,但是只要找到一个,就是高危)
水平越权
垂直越权