1. 项目概述从“黑盒”到“白盒”的视角转换做安全的朋友尤其是搞渗透测试的对OA系统肯定不陌生。很多时候我们拿到一个目标扫一扫端口发现一个OA登录框心里大概就有数了——这很可能是个突破口。常规操作是丢个万能密码、测测验证码绕过、再上SQL注入的payload试试。运气好一个admin or 11直接进后台运气不好可能就得换别的思路。这种从外部发起的测试我们称之为“黑盒测试”你只知道输入和输出不知道内部代码是怎么写的。但今天要聊的是另一种更深入、更“解渴”的方法代码审计。当你有机会接触到目标系统的源代码时比如作为内部安全人员、第三方安全服务商或者是在授权测试中获得了代码情况就完全不同了。你不再需要像盲人摸象一样去猜而是可以直接“看”到系统的五脏六腑。这次的项目就是针对一个典型的OA办公系统后台进行一次彻底的SQL注入漏洞代码审计。这不仅仅是找几个漏洞点更是理解这套系统在数据库交互层面的设计缺陷、编码习惯从而建立起一套针对性的防御策略。为什么OA系统是SQL注入的重灾区从我接触过的几十套不同厂商、不同年代的OA来看原因有几个一是历史包袱重很多系统是十多年前用ASP、PHP写的当时的安全意识普遍薄弱二是业务逻辑复杂涉及大量的用户输入点如公告、邮件、流程审批、人事档案查询等三是开发人员水平参差不齐为了快速实现功能字符串拼接SQL语句成了最“顺手”的选择。审计这样的系统就像在布满灰尘的老房子里寻宝需要耐心更需要方法。2. 审计环境搭建与核心思路拆解2.1 审计环境准备不只是看代码拿到一套OA系统的源代码第一步不是直接打开文件就开始看。一个高效的审计环境能事半功倍。我的习惯是搭建一个本地化的“沙箱”。首先代码仓库管理。我会用Git初始化一个本地仓库把源代码放进去。这不仅仅是为了版本控制更重要的是可以利用git grep命令进行全局关键词搜索效率比在IDE里一个个文件翻高得多。比如想快速定位所有执行SQL语句的地方直接git grep -n mysql_query\|mysqli_query\|executeQuery结果一目了然。其次本地运行环境。尽量复现生产环境。如果OA是PHP 5.2 MySQL 5.1那就在本地用Docker或虚拟机搭一套一模一样的。把系统跑起来有几个好处一是可以验证漏洞的真实性你找到的疑似漏洞点可以立刻构造payload在本地测试二是可以理解业务逻辑光看代码有时很难理解某个参数是怎么传递、在哪里使用的运行起来跟踪一下就很清晰。最后审计工具辅助。纯人工审计是基础但工具能帮我们做初步的“脏活累活”。我会使用一些静态代码分析工具例如Fortify SCA / Checkmarx商业工具规则库强大能发现很多潜在问题但误报率需要人工复核。Semgrep开源神器可以自定义规则。我通常会写一些针对性的规则比如搜索所有$_GET、$_POST变量未经处理直接拼接到SQL字符串中的模式。RIPS如果是PHP老牌PHP代码审计工具虽然已停止维护但其漏洞挖掘思路依然值得借鉴。注意工具只是辅助绝不能替代人工审计。工具报告的每一个“漏洞”都必须经过人工确认尤其是业务逻辑上下文。很多工具会把所有用户输入点都标记为潜在风险但有些输入点可能在前置逻辑中已经被严格过滤了。2.2 核心审计思路追踪数据的“一生”审计SQL注入本质上是追踪用户输入数据从进入系统到落入数据库查询语句的完整路径。我的核心思路可以概括为“源头-路径-汇聚点”分析法。1. 定位输入源头Source这是所有故事的起点。在Web应用中源头主要包括$_GET,$_POST,$_REQUEST$_COOKIE$_SERVER中的某些字段如HTTP_USER_AGENT,HTTP_REFERER文件上传内容如文件名从数据库或缓存中读取的、但最初来源于用户的数据二次注入在OA系统中需要特别关注后台管理功能模块的入口文件通常位于/admin/、/manage/目录下以及所有涉及查询、编辑、删除操作的API接口。2. 分析数据处理路径Flow数据从源头被获取后可能会经过一系列函数或方法的处理。这是审计中最关键也最繁琐的部分。你需要像侦探一样跟踪变量。有没有过滤搜索常见的过滤函数addslashes(),mysql_real_escape_string(),intval(),htmlspecialchars(), 以及自定义的filter_input(),safe()等函数。注意htmlspecialchars()是防XSS的对SQL注入无效这是一个常见的误解。过滤是否完整即使调用了过滤函数也要看是否对所有相关参数都进行了过滤。经常看到这样的代码$id intval($_GET[‘id’]); $sql “SELECT * FROM table WHERE id$id AND status‘$_GET[‘status’]”;这里status参数就被遗漏了。是否存在编码/解码过程有些系统会对参数进行base64编码传输在代码中会先解码再使用。审计时要注意base64_decode(),urldecode()等函数的位置过滤是在解码前还是解码后执行的如果过滤在前解码在后那么注入依然可能发生。3. 确定SQL语句汇聚点Sink数据最终被拼接到SQL语句中并执行的地方。常见的执行函数有MySQLi:$mysqli-query(),$mysqli-prepare()但需注意prepare如果使用不当如拼接SQL字符串后再prepare则无效。PDO:$pdo-query(),$pdo-exec()。PDO的预处理preparebind是安全的但直接使用query()拼接字符串则不安全。传统MySQL已废弃但老系统常见:mysql_query()。框架的ORM/查询构造器如Laravel的Eloquent、ThinkPHP的Db类。这些框架通常提供了安全的参数绑定机制但误用同样会导致注入。例如在Laravel中DB::select(“SELECT * FROM users WHERE id “ . $id)就是不安全的而DB::select(“SELECT * FROM users WHERE id ?”, [$id])是安全的。审计时我会以这些“汇聚点”函数为线索反向追踪传入它们的每一个变量检查其来源和过滤情况。3. 典型漏洞模式深度解析与案例实操结合常见的OA系统模块我们来看几个典型的、高发的SQL注入漏洞模式。这些模式不是孤立的往往会在同一套系统的不同角落重复出现。3.1 漏洞模式一字符串直接拼接——最“经典”的失误这是最原始、也最危险的模式。直接使用点号.将用户输入拼接到SQL字符串中。漏洞代码示例PHP// admin/user_edit.php $userid $_GET[‘id’]; $sql “SELECT * FROM oa_user WHERE id “ . $userid; $result mysql_query($sql);审计与利用分析漏洞定位通过搜索mysql_query(或SELECT * FROM等模式可以快速找到这类代码。漏洞成因$userid直接来自$_GET[‘id’]未经过任何过滤。攻击者可以传入1 OR 11最终SQL变为SELECT * FROM oa_user WHERE id 1 OR 11导致查询出所有用户。审计要点不仅要看$_GET还要看$_POST。在后台的“编辑用户”、“删除公告”、“查询日志”等功能中极为常见。对于数字型参数应强制转换为整型intval($userid)。对于字符型必须使用引号包裹并转义。一个更隐蔽的变种$search $_POST[‘keyword’]; $sql “SELECT * FROM oa_document WHERE title LIKE ‘%$search%”;这里$search被包裹在单引号内但攻击者可以提前闭合引号。例如传入‘%’ UNION SELECT 1,2,3,database() —注释符–注意后面有个空格可以注释掉后面的单引号和%’从而执行联合查询。3.2 漏洞模式二误用转义函数——自以为安全的陷阱开发人员知道要过滤但用了错误的方法或者理解有偏差。案例1错误使用addslashes()与宽字节注入// 系统使用GBK等宽字符集 mysql_query(“SET NAMES ‘GBK”); $name addslashes($_GET[‘name’]); // 假设传入 %bf%27 $sql “SELECT * FROM oa_admin WHERE name‘$name”;addslashes()会在单引号’前加反斜杠\变成\。但在GBK编码下%bf%5c%5c是反斜杠构成了一个合法的宽字符“縗”。那么%bf%27经过addslashes()变成%bf%5c%27数据库在GBK编码下会认为%bf%5c是一个字符从而使得后面的%27单引号逃逸出来引发注入。实操心得审计时一定要检查数据库连接字符集设置。如果看到SET NAMES ‘gbk’、mysql_set_charset(‘gbk’)等同时又有addslashes()就要高度警惕宽字节注入的可能性。根本的解决方式是使用mysql_real_escape_string()考虑字符集或更好的使用预处理语句。案例2过滤函数被绕过function filter($input) { $input str_replace(“‘“, “”, $input); $input str_replace(‘”‘, “”, $input); return $input; } $id filter($_GET[‘id’]); $sql “SELECT * FROM oa_news WHERE id$id”;这个过滤函数天真地认为删除单双引号就安全了。但对于数字型注入根本不需要引号。传入1 AND 11即可轻松绕过。审计时看到自定义的过滤函数一定要仔细分析其逻辑是否完备能否被大小写、双写、编码等方式绕过。3.3 漏洞模式三框架与ORM的误用——高级功能下的低级错误现代OA系统可能会使用ThinkPHP、Laravel等框架。框架提供了安全的数据库操作方式但“刀”在不会用的人手里反而更危险。ThinkPHP 3.x 表达式注入 ThinkPHP 3.x的where()方法支持数组条件和字符串条件。字符串条件如果不当使用会导致注入。// 错误示例 $map[‘id’] $_GET[‘id’]; // 用户传入 1) AND (11 $User-where($map)-find(); // 生成的SQL可能是WHERE (id 1) AND (11)这里框架会将数组键值直接拼接到WHERE子句中。正确的做法是使用参数绑定或者确保传入的$map[‘id’]是安全的数字。Laravel 原生查询不绑定参数// 错误示例 $orderId $_GET[‘order_id’]; $orders DB::select(“SELECT * FROM oa_orders WHERE id “ . $orderId); // 正确做法 $orders DB::select(“SELECT * FROM oa_orders WHERE id ?”, [$orderId]);审计Laravel项目时全局搜索DB::select(、DB::statement(等检查其参数是否使用了问号?占位符和参数绑定数组。3.4 漏洞模式四二次注入——潜伏的“内鬼”这是最容易被忽略的一种注入类型。数据在存入数据库时进行了正确的转义但在从数据库取出后再次被使用且被认为“安全”而未加过滤导致了注入。漏洞场景模拟用户注册时用户名为admin’#。代码使用addslashes()处理存入数据库的值为admin\’#反斜杠被存储。后台有一个“重置用户密码”的功能根据用户名查找用户。// reset_password.php $username $_POST[‘username’]; // 这里直接从表单获取假设是 admin’# $user mysql_query(“SELECT * FROM oa_user WHERE username‘” . addslashes($username) . “‘”); // 这里再次转义查询正常 // ... 假设这里执行了重置操作然后记录日志 $log_sql “INSERT INTO oa_log (action) VALUES (‘密码重置用户” . $user[‘username’] . “‘)”; mysql_query($log_sql); // 灾难发生关键在于第3步$user[‘username’]是从数据库取出的原始值admin\’#。当它被直接拼接到$log_sql时SQL语句变成INSERT INTO oa_log (action) VALUES (‘密码重置用户admin\’#’)。在SQL中反斜杠是转义字符它使得后面的单引号被转义而#注释掉了后面的内容。这可能导致日志记录错误甚至在某些情况下如果$log_sql本身结构更复杂可能引发进一步的注入。审计难点二次注入的审计需要跟踪数据在整个应用生命周期中的流动。你需要找到数据“存入”和“取出后再使用”的两个点。全局搜索所有INSERT/UPDATE语句存入点和SELECT语句取出点分析它们之间是否存在关联字段被不安全地使用。4. 系统性审计流程实战演练理论说了这么多现在我们模拟对一个虚构的“某OA办公系统”后台进行一场系统的审计。假设我们已获得其PHP源代码。4.1 第一步信息收集与入口梳理首先浏览代码目录结构。一个典型的OA后台可能如下/admin/ ├── index.php (后台首页) ├── login.php (后台登录) ├── config.php (配置文件可能有数据库连接) ├── modules/ │ ├── user/ (用户管理) │ │ ├── list.php │ │ ├── edit.php │ │ └── delete.php │ ├── news/ (新闻公告) │ ├── workflow/ (工作流) │ └── log/ (日志管理) └── includes/ ├── db.class.php (数据库操作类) └── common.func.php (通用函数)重点关注/admin/modules/下的各个子目录这些是后台功能的集中地。同时查看/admin/includes/db.class.php了解系统用的是原生MySQLi、PDO还是自定义的数据库类这决定了我们后续搜索的关键词。4.2 第二步全局搜索与初步定位打开终端进入代码根目录开始关键搜索搜索SQL执行函数# 搜索所有执行SQL的地方 grep -r “mysql_query\|mysqli_query\|-query\|-execute\|-exec” –include“*.php” . # 搜索预处理语句可能安全但也需检查绑定方式 grep -r “-prepare\|bind_param\|bindValue” –include“*.php” .这个命令会列出所有可能执行SQL的文件和行号这是我们的“可疑点清单”。搜索用户输入源# 搜索直接使用超全局变量的地方 grep -r “\$_GET\[ \$_POST\[ \$_REQUEST\[“ –include“*.php” .这能快速找到所有接收用户输入的地方。搜索常见过滤函数grep -r “addslashes\|mysql_real_escape_string\|intval\|htmlspecialchars\|strip_tags” –include“*.php” .了解系统整体的过滤水平。4.3 第三步深度追踪与漏洞确认假设我们在/admin/modules/user/list.php中发现如下代码// list.php 片段 require_once ‘../includes/db.class.php’; $db new DB(); $department isset($_GET[‘dept’]) ? $_GET[‘dept’] : ‘’; $sql “SELECT * FROM oa_user WHERE 11”; if (!empty($department)) { $sql . ” AND department ‘“ . $department . “‘“; } $order isset($_GET[‘order’]) ? $_GET[‘order’] : ‘id DESC’; $sql . ” ORDER BY “ . $order; $users $db-fetchAll($sql);审计过程变量追踪$department来自$_GET[‘dept’]$order来自$_GET[‘order’]。过滤检查代码中没有对$department和$order进行任何过滤。汇聚点分析它们被直接拼接到$sql字符串中并传入$db-fetchAll()方法执行。漏洞确认$department是字符型包裹在单引号中。可注入depthr’ AND ‘1’‘1或depthr’ UNION SELECT … —。$order更危险它直接拼接在ORDER BY后面。ORDER BY子句后不能使用预处理且通常不适用引号。可注入order(CASE WHEN (SELECT 1 FROM dual)1 THEN id ELSE name END)通过条件语句进行盲注。这是一个典型的ORDER BY注入。查看DB类我们需要检查$db-fetchAll()的实现。在db.class.php中class DB { private $conn; public function fetchAll($sql) { $result mysqli_query($this-conn, $sql); // … 获取数据并返回 } }确认了它直接使用了mysqli_query没有做任何额外的安全处理。漏洞坐实。4.4 第四步编写验证POC为了证明漏洞存在我们需要编写一个简单的证明概念PoC脚本。这不是攻击而是在授权测试中验证漏洞的必要步骤。对于上面的order参数注入基于时间的盲注import requests import time url “http://test-oa.com/admin/modules/user/list.php” params { ‘dept’: ‘hr’, ‘order’: ‘id,(SELECT IF(SUBSTRING(database(),1,1)‘o’,SLEEP(3),0))’ } start_time time.time() try: r requests.get(url, paramsparams, timeout10) except requests.exceptions.Timeout: print(“请求超时可能触发了SLEEP数据库名首字母可能是‘o’”) else: print(f“请求未超时响应时间{time.time()-start_time:.2f}秒”)这个PoC会测试数据库名的第一个字母是否为‘o’。如果响应延迟约3秒则证明存在基于时间的SQL注入漏洞且order参数可控。5. 审计报告撰写与修复建议审计的最终产出是一份详实、可操作的报告。报告不应只是漏洞列表更要帮助开发团队理解问题根源并有效修复。5.1 漏洞报告模板对于发现的每个漏洞应包含以下要素漏洞标题清晰描述如“后台用户管理列表页ORDER BY参数SQL注入漏洞”。风险等级高、中、低可根据CVSS标准粗略评分。文件路径/admin/modules/user/list.php漏洞代码位置第XX行。漏洞详情脆弱参数$_GET[‘order’]漏洞类型SQL注入ORDER BY盲注漏洞成因用户输入的order参数未经任何过滤直接拼接到SQL语句的ORDER BY子句中。攻击影响攻击者可利用此漏洞进行布尔盲注或时间盲注逐步获取数据库名、表名、字段名及具体数据可能导致后台权限泄露、敏感数据如员工信息、内部文件被盗。漏洞证明附上PoC脚本或截图说明如何触发漏洞。修复建议白名单过滤首选ORDER BY子句应严格限制可排序的字段。预先定义一个允许排序的字段数组。$allow_order_fields [‘id’, ‘name’, ‘create_time’]; $input_order $_GET[‘order’]; $order_parts explode(‘ ‘, $input_order); $field $order_parts[0]; $direction isset($order_parts[1]) strtoupper($order_parts[1]) ‘DESC’ ? ‘DESC’ : ‘ASC’; if (in_array($field, $allow_order_fields)) { $safe_order $field . ‘ ‘ . $direction; } else { $safe_order ‘id ASC’; // 默认值 } $sql . ” ORDER BY “ . $safe_order;参数化查询对于WHERE条件对于$department这类WHERE条件参数应使用预处理语句。$stmt $this-conn-prepare(“SELECT * FROM oa_user WHERE department ?”); $stmt-bind_param(“s”, $department); // ‘s’表示字符串类型 $stmt-execute();转义不得已时如果因历史原因无法大改对于$department至少应使用mysqli_real_escape_string()进行转义。但切记这不适用于ORDER BY子句。5.2 系统性修复与加固建议在报告末尾应给出针对整个系统的加固建议推行预处理语句在所有新的数据库操作代码中强制使用PDO或MySQLi的预处理功能prepare bind。这是根治SQL注入最有效的方法。建立安全函数库在common.func.php中编写统一的输入过滤和校验函数如safe_int()、safe_string()、whitelist_check()并要求所有开发人员调用。代码规范与培训制定安全编码规范明确禁止字符串拼接SQL。对开发团队进行定期的安全编码培训。引入安全SDL流程在系统开发的需求、设计、编码、测试阶段融入安全考量特别是上线前的代码安全审计环节。部署WAF作为临时防护对于已上线且无法立即修复全部漏洞的旧系统可以考虑部署Web应用防火墙WAF来拦截常见的SQL注入攻击payload为代码修复争取时间。但这只是缓解措施不能替代代码修复。6. 进阶技巧与疑难问题排查6.1 如何审计大型、框架化的项目对于使用ThinkPHP、Laravel、Yii等框架的现代OA系统审计思路需要调整。理解框架的执行流程找到入口文件如index.php跟踪请求如何被路由、控制器如何被调用、模型如何操作数据库。理解框架的MVC分层。关注模型层和查询构造器漏洞往往出现在自定义的复杂查询、原生查询Raw Query或对查询构造器的错误使用上。全局搜索DB::raw()、whereRaw()、orderByRaw()等方法这些是“原生SQL”的入口风险极高。利用框架的调试模式开启框架的调试模式如Laravel的APP_DEBUGtrue有时可以直接在错误页面看到完整的、带有绑定参数的SQL语句这对于理解查询构造和定位未绑定的变量非常有帮助。审计ORM的“魔法方法”有些ORM支持动态属性查询如User::where(‘name’, $input)-get()。需要确保$input在传入where之前是安全的或者框架本身进行了处理。6.2 遇到混淆、加密或编码的参数怎么办有些系统会对传输的参数进行base64编码、自定义加密或者在JavaScript前端进行编码。审计时全局搜索解码函数base64_decode()、urldecode()、json_decode()以及自定义的decrypt()函数。追踪解码时机找到参数被解码的位置检查解码后是否立即进行了安全过滤。过滤必须在解码之后进行。模拟前端逻辑如果参数是在前端通过JS加密的需要找到对应的JS代码理解其加密逻辑才能在审计时构造出后端期望的“明文”格式进行测试。6.3 工具扫描结果太多如何高效人工复核静态扫描工具如Fortify可能会报出成百上千个“潜在漏洞”。人工复核策略按危险等级排序优先处理“Critical”和“High”级别的告警。按功能模块聚焦优先审计核心、高危模块如用户登录/注册、权限管理、数据导出、后台管理入口等。验证数据流是否可达工具可能报告一个在深层类方法中的漏洞但你需要向上追踪看用户输入是否能真正传递到这个点。如果数据流不可达就是一个误报。检查上下文过滤工具可能只看到“用户输入”和“危险函数”但忽略了中间的过滤逻辑。你需要仔细查看这之间的所有代码行确认过滤是否有效、是否全覆盖。6.4 一个真实的疑难案例多重过滤与逻辑绕过我曾审计过一个系统其过滤函数如下function super_filter($input) { $input trim($input); $input strip_tags($input); $input htmlspecialchars($input, ENT_QUOTES); $input addslashes($input); return $input; } // 使用 $id super_filter($_GET[‘id’]); $sql “SELECT * FROM table WHERE id‘$id”;乍一看过滤非常“全面”去空格、去标签、转义HTML、转义SQL。似乎无懈可击。但这里存在一个逻辑问题htmlspecialchars($input, ENT_QUOTES)会把单引号‘转换成HTML实体#039;。然后addslashes()又在实体化的字符串上操作。当$id被拼接到SQL中时数据库看到的是id‘#039;’这看起来是安全的。但是如果这个$id后来被用于其他不经过HTML解析的上下文呢比如它被记录到一个纯文本日志文件或者被发送到一个JSON API接口。在这些场景下#039;不会被还原成单引号但addslashes()添加的反斜杠可能依然存在这可能导致数据格式错误或其他非预期的行为。虽然不一定是SQL注入但揭示了过滤逻辑与使用场景不匹配的问题。核心教训过滤必须在正确的上下文进行。在数据库层防注入就用数据库的转义或预处理在输出层防XSS就用HTML转义。混合使用或顺序错误可能导致防护失效或引入新问题。审计时一定要思考每个参数最终被用在何处。