登录后抓包，直接要求POC，创造确实延时语句确实实行成功。
接下来我们剖析下源码，通达OA采取了Zend加密，可以先利用SeayDzend工具进行批量解密。从要求的路径来看，入口文件在general/appbuilder/web/index.php。剖析index.php源码，创造appbuilder采取了Yii2框架。
跟进到166行，此处对Yii2进行了配置，配置在general/appbuilder/web.php中，跟进到该文件，可以创造appbuilder被分为几个小模块
剖析该漏洞路由，我们跟进到appbuilder/modules/calendar/controllers/Calendarlist Controller.php，找到actionGetcallist方法。从257行开始，$_POST转码后直接通报到$data，个中的多个元素被赋值，并代入到get_list_data方法中。
跟进到calendar/models/Calendar.php的get_list_data方法，63行开始我们创造，$begin_date、$end_date等可控字段被直接拼接到了SQL语句中，导致了SQL注入的发生。
3、一些有趣的问题
这个漏洞真的犹如表面上这么大略么，后续通过连续剖析入口文件index.php，我们创造了一些有趣的问题，下面我们逐一解答。
3.1 全局addslashes的绕过？之前剖析过通达OA源码的同学会创造，文件中一旦包含了inc/session.php，会对GPC进行全局的addslashes转义。详细的包含流程如下：
session.php-> conn.php-> td_config.php-> common.inc.php
而在common.inc.php的99-147行，除了某些键值的POST要求，其他都要做addslashes处理。
而appbuilder/web/index.php中正好引入了inc/session.php，却依然没有阻挡漏洞的发生。仔细剖析源码，创造在文件最开始6-20行，$_GET和$_POST中的参数值被base64编码。
在138-151行，$_GET和$_POST中的值被解码。
而引入inc/session.php在25行，适值此时要求的参数值处于编码状态！
因此，后续从该入口的所有要求GET、POST参数值都不受addslashes转义影响。
我们去掉上述POC中的Cookie字段，发起要求依然产生了延时，这证明SQL语句确实被实行，只是状态码变成了302。
我们连续剖析index.php，查看用户登录权限掌握的地方，跟进27行if条件，如果$_SESSION["LOGIN_UID"]存在且不为空或者0，进入if语句。
68行为else语句，判断uri中是否有”/portal/”字符串，如果没有则设置header为302跳转。熟习PHP的人该当都知道，纵然程序中实行了header(location)，后续代码的逻辑还是会连续实行，因此该SQL注入漏洞可以未授权实行。
3.3 多个模块未授权？
index.php中除了用户权限判断外，还对模块权限进行了判断。详细可以从79行开始看，定义了$b_dir_priv默认为false，通过对uri进行分割，获取模块名称。
我们直接定位到120行的if语句，如果$b_dir_priv仍旧为false，并且在
$config["params"]["skip_module"]中，设置$b_dir_priv为true。
我们看看$config["params"]["skip_module"]的定义，包含portal、hr、meeting等多个模块，上述模块可以被认为是跳过验证的模块，也就意味着如果在方法中没有做进一步验证，上述模块的所有方法都可以未授权访问，个中包含不少敏感的增编削查接口。
大略看了下未授权模块的一些方法，可以实行很多敏感操作，同时我们也找到一处未授权的SQL注入，建议利用该版本OA的用户及时升级。
4、安全产品办理方案
百度度御关WAF、高等威胁感知系统，以及智能安全一体化产品已支持该SQL注入漏洞的检测和拦截，有须要的用户可以访问anquan.baidu.com联系我们。
