某微SQL注入分析长文

==========正文==========‍‍

首先找到存在注入的server.jsp文件，发现该页面会接受一个参数名为invoker的参数

然后对该参数进行了判空和前缀检查。从页面中可以看出当参数不包含com.api.mobile.mode时代码会对该参数进行一次base64解码

分析一下try代码块执行步骤：

1.首先通过Class.forName(invoker)来加载一个类

2.判断该类是否为BaseMobileAction.class的派生类，若不满足则抛出异常，程序终止

3.当满足条件时，进入if代码块，通过class.getConstructor方法获取一个构造函数对象，该构造参数形参为

ClassName(HttpServletRequest.class, HttpServletResponse.class)

然后通过newInstance进行实例化(等同于new Object(HttpServletRequest.class, HttpServletResponse.class))

最后调用该实例的execute_porxy()方法即注入点

至此，jsp页面代码分析完毕，我们接下来分析这个漏洞是如何产生的：

首先，要加载的类要符合一个前置条件：是BaseMobileAction.class的派生(子)类。由此我们可以先看看该类长啥样

可以看到此处该类是一个抽象类，继承至BaseAction.class，它拥有两个构造函数，根据jsp页面中的代码可以得知它加载的是第一个构造函数，此处没有特别的信息。再回头看发现该类并没有页面中调用的execute_proxy方法，这是为什么呢。因为该方法是继承于它的父类即BaseAction.class。

让我们再次跟进该父类

终于找到了执行的方法，可以看见该方法执行了本类的execute方法，不过此方法是抽象方法，需要继续往下看真正的实现代码。此时，我们需要回过头去寻找继承至BaseMobileAction.class的类，最终可以找到com.weaver.formmodel.mobile.mec.servlet.MECAction.class(这是真正存在漏洞的类)，通过观察可以发现该类的要执行的execute方法首先执行了getAction方法，我们需要去查找这个方法做了什么

最终我们找到了该方法，其实就是获取了请求中的key为action参数值

然后顺着if判断的流程我们可以找到这次触发漏洞的代码，当action=customQuery时，执行customQuery方法，继续跟进

接下来我们可以很清楚的看见这段代码存在sql拼接的问题，首先关注33行其实执行的是str8，而str8中的sql语句里字段，表和条件语句都是可控的，最终可以构造参数完成任意数据查询

POC：

/mobilemode/mobile/server.jsp?action=customQuery&invoker=Y29tLndlYXZlci5mb3JtbW9kZWwubW9iaWxlLm1lYy5zZXJ2bGV0Lk1FQ0FjdGlvbg==&selectField=*&table=HrmResourceManager&whereClause=1%3D1&triggerCondition=1&value=1

POC验证

‍

原文始发于微信公众号（虚拟尽头）：某微SQL注入分析长文