逻辑漏洞是指由于程序逻辑输入管控不严或者逻辑太复杂,导致程序不能够正常处理或处理错误,逻辑漏洞根据功能需求的不同产生的漏洞方式也不同。一般出现在网站程序的登录注册、密码找回、验证方式、信息查看、交易支付金额等地方。
这类漏洞不同于常见WEB漏洞,常见WEB漏洞都可以总结为一定的范式,而逻辑漏洞不行
逻辑漏洞出现的原因也是有很多种,需要有一定个人经验积累才能在代码审计过程中发现此类漏洞
首先将所有逻辑漏洞的问题分为前端和后端两个部分,先测试绕过前端规则限制再测试绕过后端规则限制,一般情况下只要能够突破原有规则限制的都就可以算是漏洞。
挖掘逻辑漏洞总体步骤分为以下三步:
未授权访问敏感数据接口
短信api接口泄露被恶意调用
数据库接口泄露,导致数据可被恶意操作
万能验证码:
程序员在开发验证码模块时,为了方便调用验证码验证功能是否完善,故意设置了几个万能的验证码作为测试数据。在开发结束后由于程序员的疏忽,没有删除该测试验证码数据从而导致该漏洞的产生。
验证码回传:
通过抓包的方式,可以看到验证码内容回显在了数据包中;或者通过查看网页源代码可以看到验证码中的内容,导致正确验证码可以被直接读取利用到。
删除验证码绕过:
通过抓包将验证码的值删除或者直接删除验证码参数,然后将修改后的数据包进行重放导致验证码验证被绕过。
验证码爆破:
此处验证码爆破通常是指手机短信验证的方式,由于没有对输入同一个验证码的次数做限制,并且验证码的内容太简单,例如4位或者6位的纯数字组成。可以通过Burp的Intruder模块对验证码内容进行爆破,直到匹配到正确的验证码。
验证码重放
首先,输入错误的验证码,进行抓包重放一次,观察验证的返回的数据包内容,再用正确的验证码再进行抓包重放,对比两个数据包的差异,然后根据这些差异验证码是否失效。
然后将正确的验证码发送至Burp的Intruder模进行不断的重放,比较这些数据包是否都是正确验证码时返回的一样内容,如果数据包内容一样说明存在验证码重放的漏洞。
验证码与手机号未统一匹配
首先用自己的手机收到正确验证码,在点击注册时拦截包将手机号改为其他手机号,如果成功的话就注册了别人的手机号,这是因为后端仅验证了验证码是否是正确的而没有验证验证码是否与手机匹配。
尝试不断重放发送验证码的数据包,查看手机是否在短时间内收到了多条短信,是的话则存在短信轰炸漏洞,这是因为后端没有对发送手机短信做时间/次数限制。
如果后端对短信验证码做了限制,那么可以尝试以下几种方式进行绕过:
首先用一个账号登陆系统后,通过抓包修改用户参数,可以达到查看或者修改他人账号的目的,尽量对多接口或者多功能模块进行不断测试越权操作。同时也要多个账号登陆,分析对比这些账号数据包中的请求参数差异,通过修改这些存在差异的参数,看看是否能够达到越权操作的目的。
越权漏洞又分为平行越权,垂直越权和交叉越权。
可能存在用户个人信息页面、密码找回处以及各种调用到用户信息数据的地方,通过抓包查看返回信息是否加载了一些敏感的数据信息,比如查询用户信息的时候也将用户的密码数据在数据包中回显了;或者在用户个人资料页面,通过抓包修改用户ID参数,可以通过遍历查询到其他账号的用户资料,导致用户信息泄露;
通常发生在忘记密码处,由于系统没有严格匹配用户忘记密码时的验证方式,通过抓包修改用户参数,导致任意用户的密码都能够被重置。
比如某个忘记密码功能处采用手机号短信验证的方式来重置用户密码,如果该验证手机号没有对用户账户进行绑定,那么就可以通过输入任意手机号接收短信验证,然后就可以利用该验证码重置用户密码了。
很多中小型的购物网站都存在订单金额任意修改漏洞。在提交订单的时候抓取数据包或者直接修改前端代码,然后对订单的金额任意修改。
经常见到的参数大多为:rmb 、value 、amount 、cash 、fee 、money 等
关于支付的逻辑漏洞这一块还有很多种思路,比如相同价格增加订单数量,相同订单数量减少产品价格,订单价格设定为负数等等。
有些业务的接口,因为缺少了对用户的登陆凭证的较验或者是验证存在缺陷,导致黑客可以未经授权访问这些敏感信息甚至是越权操作。
一般容易出现在文件导出下载,JSON数据页面,第三方应用页面等位置。
常见案例:
实际上还有很多案例,他们都存在一个共同的特性,就是没有对用户的登陆凭证进行效验
有些关键性的接口因为没有做验证或者其它预防机制,容易遭到枚举攻击。
常见案例:
cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单,导致黑客可以对cookie的效验值进行一个枚举。或者通过修改cookie中的某个参数可以登陆其他用户,即cookie仿冒。
token一般是操作令牌,每个用户在登录系统时,服务器会为每个用户生成token令牌作为操作凭证。如果token设计太过于简单,那么可能会被破解;或者token没有设置过期的时间,使得用户token不唯一,导致用户token存在被盗用的风险。
auth设计缺陷
经常研究逻辑漏洞的人可能会对以下URL很熟悉
www.xxx.com/resetpassword.php?id=MD5
用户修改密码时,邮箱中会收到一个含有auth的链接,在有效期内用户点击链接,即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数,那么这里就存在一个问题了,Windows环境下rand()最大值为32768,所以这个auth的值是可以被枚举的。
如下面这个代码可以对auth的值做一个字典。
$a=0;
for ($a=0;$a<=32768;$a++){
$b=md5($a);
echo "\r\n";
echo $b;
}
然后重置某个账号,并且对重置链接内的auth进行枚举。
通常这种漏洞比较容易出现在活动页面的会员优惠开通,而且要考虑到支付后要比正常购买优惠才算是漏洞。
注意:在做溢出测试时,有可能导致目标服务器宕机,需要向授权单位申请授权后才能进行测试。
一些网站中的限时活动设置了活动时间范围,可以通过抓包尝试更改时间参数为活动未限定范围内的。
前端加密、后端解密校验。比如在用户登录时,通过抓包发现用户密码被加密传输了,可以利用一些解密工具进行破解,如:Burp解密或者一些在线解密网站。
首先在没有验证码或者验证码可以被绕过的情况下,尝试5次或者10次账号密码登陆,检测目标是否封禁账户,如果没有封禁规则,可以不断进行爆破。采用账号密码爆破,对于一些商城、应用、政府、学校采用撞库方式判断是否存在该账号(需要准备各类字典:手机号撞库、邮箱撞库、姓名撞库)。
url跳转漏洞也叫开发重定向漏洞,可以把用户重定向到攻击者自己构造的页面去,简单的说就是可以跳转到任意指定的url。一般出现在验证跳转、sso登陆等位置。
服务端未对传入的跳转url变量进行检查和控制,可能导致可恶意构造任意一个恶意地址,诱导用户跳转到恶意网站。
危害:
http://www.xxx.com?url=https://www.baidu.com
替换url参数后能够跳转到对应页面,但是一些网站可能会对url跳转做限制,可以尝试绕过bypass
1.利用问号绕过限制,最终跳转到京东页面
url=https://www.baidu.com?www.jd.com
2.利用@绕过限制,最终跳转到京东页面
url=https://[email protected]
3.利用斜杆反斜杠绕过限制
4.利用#绕过限制
url=https://[email protected]
5.利用子域名绕过
6.利用畸形url绕过
7.利用跳转IP绕过
在支付环节中由于逻辑不严谨而产生的漏洞称为支付漏洞。
只要有参数,都可以修改,都有可能出现问题。
通常使用两个账号来对比测试,这样可以更快发现可疑参数
正常的逻辑是用户购买商品,然后价格累加得到一个总价进行扣款。这个时候就会产生逻辑问题:如果说用户购买的商品是负数了,那么计算的总数就是负数。反过来钱给用户
正常的逻辑是a-b-c-d 循环渐进的进行流程操作。这个时候就会产生逻辑问题:可以直接从中绕过某一个过程进入到下一步操作。如果说有一项是支付的操作,那么也就会产生支付绕过,如果说有一项是验证机制,就会绕过验证直接进入下一步。
直接对下单的金额进行修改值,这里可以使用fd或者burp抓包
把商品放入购物车点击下单支付,会跳转到微信,支付宝等第三方支付平台。这个时候还可以继续在购物车中加入商品,支付结束之后,商家发放的商品是现在的购物车里面的东西。
购买成功之后,继续重放请求,可以让购买的商品一直增加。购买成功之后,会有一个银行对商户网站跳转的过程,如果反复进行操作,有几率会导致商品反复购买和增加,但是不需要付更多的钱。
金钱做了签名认证之后,修改后不通过,但是在里面仍然会有一个参数对金额产生影响导致问题产生。
订单替换发生在支付之后的事件处理,同时向服务器发起二次支付请求一个多一个少,支付金额少的,然后支付之后进行替换,告知服务器订单支付完成,并且过程可以反复的回放。
需要两个收款人,一个是正常的商家,一个是伪造的商家
产生在paypal类似的国际支付的场景。
在支付过程中发生用户替换现象,首先登陆自己的账户,然后取得另外一个人的账户名等有效信息,在业务流程中用对方的用户名替换自己的用户名,用对方的余额购买完成后,再替换自己的账户名,这样就形成别人的钱买自己的东西
强制攻击发生在暴力破解的情况下,如果一个商家运用一个自己的网店,接入第三方支付接口,由于设计上的不当导致商家与第三方支付约定的密钥Key可以单独被MD5加密,导致可以使用MD5碰撞技术对密钥进行破解,攻击者可以设计简单的密钥加密信息使得MD5加密是可以用MD5碰撞技术进行暴力破解。
内置支付功能的app为了设计上的方便有可能会把Md5或者是RSA的私钥泄漏导致攻击者反编译apk之后获取密钥信息使得交易信息可以被篡改。
13.函数修改:apk反编译之后的函数修改,可能导致商家在最后一步向支付方提交订单时未验证信息的准确性,仍然被篡改。