KPPW最新版SQL注入漏洞九,也是全局问题导致的大面积注入,这里申明不是在刷漏洞,因为每一个问题都很严重,都能引发很多问题...
KPPW最新版SQL注入漏洞九,也是全局函数的问题,导致大面积注入...
文件/control/user/account_auth.php
这里包含了/auth/$code/control/index.php文件,这里的code我们设置为email
当然code有('realname','enterprise','bank','mobile','email')这五中形式
进入/auth/email/control/index.php文件:
第三步验证时,$active_code和$email_a_id参数进入验证函数audit_auth
跟进,文件/auth/email/lib/keke_auth_email_class.php
这里参数$email_a_id又进入函数get_auth_info
跟进,文件/lib/sys/keke_auth_base_class.php
到这里,参数$auth_ids = $email_a_id,进入了sql语句
但是当$auth_ids有逗号分隔的话,就进入下面那一条语句in ($auth_ids),在整个参数传递的过程中$auth_ids没有过滤,这里也没有加引号保护,导致注入。
下面我们来看看任何导致大面积注入
问题出在get_auth_info函数,位于文件/lib/sys/keke_auth_base_class.php
lib下面的文件都是系统的全局调用文件,这里的keke_auth_base_class.php也是一样,在所有关于认证的功能里面都会调用,如下面四个文件:
前面两个就是我们这里的漏洞分析,看看下面连个。
以及
这里是在del_auth和review_auth函数处调用了漏洞函数get_auth_info
而且进入这两个函数的参数都是没有处理的,最后都直接进入了sql语句,导致sql注入
而且del_auth函数在认证过程中被调用的地方是21处...
review_auth函数在认证过程中被调用的地方是17处...
所以罪魁祸首get_auth_info函数,可以引发大面积的sql注入问题。
总结
邮件认证时,发送邮件:
成功发送认证邮件后,看看邮箱收到的认证链接:
然后copy认证链接,构造参数email_a_id,注意这里的id后面的一个必须存在的id,如这里的2,构造后请求为:
这里会演示5秒后返回:
说明这里username+passw的第一个字符为a,继续即可注入出username+password的值
sql执行日志: