大柚子

这世界不过如此

一、概述

业务逻辑漏洞是应用程序的设计和实现中允许攻击者引发意外行为的缺陷。这可能使攻击者能够操纵合法功能来实现恶意目标。这些缺陷通常是由于未能预料到可能发生的不寻常的应用程序状态,从而未能安全地处理它们。

主要造成此漏洞的原因有如下两种:


1、逻辑漏洞是指由于程序逻辑不严导致一些逻辑分支处理错误造成的漏洞。
PS:举例:对于和程序逻辑有关的逻辑漏洞,比较典型的就是上传文件处的条件竞争了。
有漏洞的文件上传处理逻辑一般是先保存文件、然后判断文件后缀是否在白名单里,如果
是,则保留文件;如果不是,则删除文件。这种处理逻辑,可以用时间竞争的方法绕过,
即多线程上传文件,同时上传多个相同文件,让程序在同一时间处理不过来。在这时候访问
上传的文件(也可以说等待删除的文件)就可以触发该漏洞

2、逻辑漏洞的产生除了和程序逻辑有关还与对用户控制的参数处理不足有关。
PS:举例:对用户控制的参数处理不足的逻辑漏洞,比较典型的就是“0元购”。
即在购物的时候改变购买金额,而后端没对这个参数进行校验,就产生了这个漏洞

二、业务逻辑代码分析

1、启动webgoat环境,进入业务逻辑漏洞界面

2、页面中是一个双因子认证功能,尝试这个功能,提交验证,F12查看真正的请求接口:http://127.0.0.1:8080/WebGoat/auth-bypass/verify-account

3、根据获取到的接口,在idea直接搜索该接口的实现代码,在源码发现此接口的实现类是:org.owasp.webgoat.auth_bypass.VerifyAccount类的completed方法

4、分析代码,先用“parseSecQuestions”方法处理用户传进来的值,保存参数名包含“secQuestion”的参数名和参数值,跟进

5、接着把取出来的参数名和参数值放入“verificationHelper.didUserLikelylCheat”方法处理,继续跟进

6、”didUserLikelylCheat“方法的处理逻辑为先对传进来的参数个数与数据库里的安全问题个数比较,如果相等,返回true。接着对传进来的参数名“secQuestion0″和”secQuestion1“所对应的值和数据库里”secQuestion0“和”secQuestion1“对应值做比较,只有都相等的情况下返回true。否则为false。

7、所以针对上述情况,在我们不知道密保的情况下,跳过这个判断条件,进入下一个if。

8、跟进”verificationHelper.verifyAccount“方法,此方法逻辑为,分别判断密码问题数量、密保问题一、密保问题二、有任意一个条件不满足的话,就进入if语句,返回false。

注:在这里,看逻辑其实是很正常的,但是要考虑到一个点,代码中从请求中获取密保问题1和密保问题2的参数名是写死的为”secQuestion0″和”secQuestion1″,那如果我取不到”submittedQuestions.containsKey(“secQuestion0”)“和”submittedQuestions.containsKey(“secQuestion1”)“的值,那if的判断语句就是false,就不会进去if条件语句,结果就会进入最后语句return true了。

9、那么这里的利用条件就很明显了,只要改变密保问题的参数名就能达到绕过密保问题认证了(注:密保问题数量得是两个,且密保参数名必须是”secQuestion“开头

10、使用burpsuit进行抓包,修改密保的参数名,进行重放,利用成功

三、业务逻辑漏洞代码审计技巧

1、对于审计逻辑漏洞来说,最方便的是从功能点出发,查看程序处理流程。有无处理不当、有无未过滤参数等等。

2、每一个功能点都有可能有逻辑漏洞。全部审计比较耗时间,可以先看几个经常会有问题的功能点,如忘记密码处、支付订单处、文件上传处、用户登录/注册处、发送验证码处等等。

可参考:https://zhuanlan.zhihu.com/p/261429532

Print Friendly, PDF & Email

发表回复

您的电子邮箱地址不会被公开。