旧图书管理系统SQL注入排查与参数化查询加固实战

做安全评估的时候摸到一套老旧的图书管理系统，入口是个还在服役的Web借阅平台，内部代号LibSys 3。系统本身是某图创公司早年面向公共馆和学校馆交付的产品，部署时间早、维护周期长，代码库里的历史包袱非常重。我接手的第一件事是梳理它的对外接口，结果在几个业务模块里都发现了SQL注入的影子。这篇文章就把这次排查与修复的过程原原本本写出来，重点放在成因分析、风险确认和加固整改上，给那些还在维护老系统的团队一份可以直接参考的实操记录。

先说清楚，整篇文章只讲防御性排查、漏洞定位与修复加固，不涉及任何攻击利用细节。对已经上线的系统做安全评估，核心目标永远是搞清楚"哪些地方可能被利用"，然后赶在出问题之前把口子堵上，而不是演示怎么打穿它。这套思路对任何老系统都适用，尤其是那种换了三任开发、连文档都没留全的业务系统。

1. 这个系统问题到底出在哪：一次旧图书管理系统SQL注入风险的排查记录

1.1 为什么旧系统更容易出这类问题

LibSys 3的Web端大致分为几个模块：读者检索、个人借阅查询、管理员后台、馆员编目操作。每个模块背后都连着同一套业务数据库，里头存的不只是图书书目，还有读者证件号、手机号、借阅记录、押金状态这些敏感数据。问题在于，这套系统最初设计的时候，开发框架还停留在早期PHP和Java Servlet混合的形态，很多SQL语句是直接在业务代码里拼字符串拼出来的，参数校验基本靠前端表单拦一下，后端的过滤逻辑约等于没有。

这种情况在行业内太常见了。很多2008到2015年间交付的馆配系统都有同样的毛病：业务优先，安全靠后。那时候威胁模型和现在不一样，内网部署居多，外网访问少，团队里也没人专门盯代码审计。等到系统迁移上云、开通公网访问，或者为了移动端App开放了接口，老代码里埋着的问题就全暴露出来了。

排查的时候我注意到LibSys 3有几个典型特征：第一，代码仓库里没有统一的数据库访问层，每个功能模块各自为政，有的用预处理封装，有的直接用字符串拼接；第二，系统的报错机制没有做统一处理，数据库异常信息能一路透传到页面，这是最危险的一点；第三，管理员后台居然允许使用弱口令，但那是另一个话题了，先按住不表。

1.2 应对这次排查的整体思路

我给自己定的排查路线很简单：先找入口，再找脏数据流向，最后定位具体的拼接点。入口就是所有能接受外部输入的请求，包括查询参数、表单字段、Cookie，以及HTTP头里那些会被记录到日志或者写进数据库的字段。脏数据流向是指用户输入从进入系统到被SQL语句消费的完整链路，只要链路上任何一个环节没有做过滤或转义，风险就存在。

实际操作中我是这么组织的：先把系统在跑的Web服务框架和数据库类型摸清楚，再梳理对外可访问的所有URL，然后逐个模块做代码走查，重点关注那些接收参数后直接执行查询的地方。这个过程听起来简单，真正做起来很耗时间，因为老系统的代码里经常有大量复制粘贴的历史痕迹，同一个查询逻辑可能在三个不同文件里各写了一遍，而且写法还不一样。所以排查必须配合全局搜索，把所有可疑的SQL关键字和参数获取方式集中列出来，再逐个判断。

排查工具方面，我用了数据库层的通用日志功能，把应用发来的真实SQL语句记录到独立日志文件里，这样能直观看到哪些语句是参数化的、哪些是拼接的。这一步不需要改动业务代码，只需要在开发环境或测试环境的数据库配置里打开日志开关，非常实用。

2. 漏洞根源：字符串拼接背后的常见错误

2.1 代码里最常见的三个错误写法

LibSys 3的问题不是个别现象，而是系统性差错。我整理了代码里三个反复出现的模式，这三个模式基本覆盖了老系统SQL注入风险的主要来源。

第一个是登录模块里的直拼查询。读者登录的时候，系统根据输入的读者证号和密码去读者表里比对，正常逻辑应该是先把SQL模板写好，再通过参数绑定传入具体值。但这套代码里写的是直接拿用户提交的内容拼进语句，用户的输入被当作SQL代码的一部分来解析。类似写法还出现在图书检索的标题、作者和ISBN条件里，以及馆员处理借还操作的读者证号参数上。

第二个模式是把存储过程或动态SQL的片段直接拼接。系统中有一部分复杂统计报表功能用的是动态SQL，比如按不同条件组合查询借阅量，开发时为了让条件组合灵活，就把整个WHERE子句用字符串拼出来。动态SQL本身不是原罪，问题在于拼进去的每个片段都是直接来自前端的参数，没有任何白名单和类型判断。这种情况比简单的拼接更隐蔽，因为它分散在多个分支条件里，连代码审计工具都容易漏报。

第三个模式是二次编码绕过。系统某些地方做了输入过滤，但它只过滤了第一次提交的原始内容，参数的URL解码、JSON解析、或者是经过多层转义之后的值，过滤逻辑就管不到了。曾经有个接口先接收一个JSON对象，再取出其中的多个字段分别拼接查询，过滤只加在最外层请求体上，结果内层字段完全裸露。

这三个写法的共同点，是都没有执行"输入数据与SQL指令分离"这个基本原则。SQL注入能成立的根源从来不是数据库太弱，而是应用层把两类不同性质的东西混在一起处理了。

2.2 一个"看不见"的危险：表单校验的错觉

LibSys 3的前端确实做了不少校验，比如检索页面的输入框限制了长度，管理员登录页有验证码，借阅查询要求读者证号是纯数字。这些措施给人造成一种"系统还是有安全设计"的错觉，但实际上前端校验只对普通用户有效，任何懂点技术的人都可以直接构造绕过前端的请求。

我举一个真实见到的例子。读者借阅查询页面里，前端JavaScript限制了查询参数只能包含数字和字母，看起来没什么问题。但后端接收参数之后，把它直接塞进了查询语句的WHERE条件里，既没有重新做正则校验，也没有使用参数绑定。前端限制成了摆设，绕过方式甚至不需要任何工具，直接改一下请求参数就能做到。这就是典型的"前端安全=后端安全"的错误认知。

还有一层的误区是验证码。验证码解决的是自动化脚本批量提交的问题，跟注入没关系。管理员后台有验证码，不代表后台所有接口都是安全的，很多后台的操作接口压根没走到验证码校验那一层。这类接口一旦被识别出来，反而比没有验证码的可疑参数更容易成为目标，因为攻击者知道这种老系统里的后台功能一般都没做过加固。

2.3 数据库报错为什么会暴露内部信息

排查过程中我特意观察了系统的异常处理机制。正常情况下，数据库执行出错时系统应该返回一个通用提示页，比如"系统繁忙，请稍后重试"，同时把详细错误写到服务端日志。但LibSys 3在多个接口里直接让底层异常冒泡到页面，我在测试环境输入了一个格式异常的参数，页面立刻返回了包含SQL语句片段和数据库字段名的错误信息。

这本身不算是注入漏洞，但它是最关键的辅助信息。原因有两个：第一，报错信息会直接告诉请求者数据库的类型、版本特征、表名字段名，这些信息让构造后续请求变得非常轻松；第二，报错信息说明系统没有统一异常处理，那代码里其他地方大概率也缺乏安全规范。实际加固时，这两点都要一起解决，否则即使堵住了注入点，信息泄露问题依旧让系统处于不利地位。

3. 排查与验证：怎样在不破坏业务的前提下确认风险

3.1 通过访问日志定位可疑请求

我不会一上来就在生产环境做测试，那样风险太大。排查的第一步是在测试环境搭一套与生产版本一致的LibSys 3副本，导入脱敏后的样例数据，再接入数据库层的日志开关，把所有查询记录下来。

有了测试环境之后，我先看正常业务流程会产生哪些SQL，比如读者登录、图书检索、借阅历史查询，分别会触发什么语句。这一步的意义在于建立基线，把正常请求的样式搞清楚，后面再检查异常就有一个对照。

然后我去翻测试环境的Web访问日志，重点关注两类请求：一类是所有带参数的GET和POST请求，另一类是来自非常规客户端的请求，比如User-Agent缺失或不常见的访问。老系统日志格式一般比较乱，但只要有参数透传记录，就能通过关键字筛选出涉及关键词的访问路径。

顺带说明一下，这个方法在排查已上线系统时更常用。很多系统被反复试探之后，访问日志里会留下成批的典型请求记录，比如某个接口短时间内收到大量带异常内容的参数提交，这种情况基本可以认定有人在扫描。把日志里的可疑请求摘出来，再回溯到代码层面确认是否存在拼接，是效率非常高的定位方式。

3.2 用最小代价做注入探测

确认一个接口是否真的存在问题，我会在测试环境做最小代价的探测。核心做法是先输入一个正常的参数值，确认返回结果与预期一致；再输入一个包含特殊字符的参数，比如在字符串型参数里加入一个英文单引号，观察系统行为是否有明显变化。如果系统直接报数据库语法错误，或者返回结果和正常情况完全不一致，基本可以断定这个参数参与了SQL语句拼接。

要特别强调的是，这种探测停留在"判断是否存在问题"的层面就够了。真正的漏洞确认靠的是代码走查和语句日志，不需要也不应该把完整利用语句跑一遍。我排查的原则是：能证明存在风险，给出修复建议，就完成任务，绝不把测试环境当靶场去尝试各种花式绕过。

在确认某个接口确实存在拼接问题后，我会把影响范围记录下来，包括涉及的URL、请求方法、参数名、触发的SQL语句样式、可能访问到的数据范围，这些信息在后续写报告和排修复优先级的时候都用得上。

3.3 影响范围评估要分清主次

排查完所有可疑点之后，我把风险按严重程度分成三档。第一档是未授权可访问的接口，比如前台检索和读者自助查询，这类接口不需要登录就能提交参数，一旦存在拼接问题，风险面最大。第二档是需要普通读者账号才能访问的接口，比如个人中心里的借阅详情和续借操作。第三档是管理员后台接口，虽然权限要求高，但一旦被组合利用，造成的危害反而最大。

分级之后再决定修复顺序。我从来不会建议一次性把所有点全改完，老系统改造最忌讳的是一股脑重构，容易把原本能跑的业务改崩。合理的做法是先堵最危险的点，再逐步推进。我这次的顺序是第一档接口优先整改，因为它们暴露面最大；第二档接口其次；第三档在管理员账号权限整改的时候一并处理。

另外，系统里还有一类隐藏问题：部分管理接口通过参数直接指定页面名称或模板文件，那个位置也可能存在其他风险，但由于不在本次SQL注入排查范围内，我没有深入，只是在报告中作为遗留风险登记并建议后续专项评估。

4. 修复与加固：从代码到运维的完整方案

4.1 参数化查询改造是首选方案

修复SQL注入问题的方案里，优先选择参数化查询，没有之一。原因很简单：参数化查询把SQL语句结构和用户输入彻底分离，数据库那边在执行前就已经把语句模板准备好，输入的值只会被当作字面量处理，永远不会变成可执行代码的一部分。

拿PHP版的代码举例，改造前的写法类似这样：

// 改造前：存在拼接风险 $username = $_POST['username']; $sql = "SELECT * FROM readers WHERE login_id = '" . $username . "'"; $result = mysqli_query($conn, $sql);

改造后使用预处理语句：

// 改造后：参数化查询 $username = $_POST['username']; $stmt = $conn->prepare("SELECT * FROM readers WHERE login_id = ?"); $stmt->bind_param("s", $username); $stmt->execute(); $result = $stmt->get_result();

Java版本同理，用PreparedStatement：

// 改造后：PreparedStatement String sql = "SELECT * FROM readers WHERE login_id = ? AND status = ?"; try (PreparedStatement pstmt = conn.prepareStatement(sql)) { pstmt.setString(1, inputUsername); pstmt.setInt(2, 1); ResultSet rs = pstmt.executeQuery(); }

这里有个执行层面的要点：确保代码用的是预处理接口真正执行参数绑定，而不是自己手动转换一下再拼回去。我看过有些改造是拿字符串替换函数把单引号替换成两个单引号，这属于"无效修复"，既繁琐又不可靠。真正正确的做法是让数据库驱动来处理值的绑定，而不是在应用层做转义。

4.2 服务端输入校验要重新梳理

参数化查询解决了核心的注入问题，但输入校验仍然是不可替代的第二道防线。我对这次涉及的所有对外接口都重新梳理了输入规则，按照参数类型分别处理。

数值型参数，比如读者证号、图书ID、页码，必须在服务端做整型或长整型强校验，非数字直接拒绝。字符串型参数，要设置明确的长度上限和字符集白名单，比如检索关键词只允许中文字符、英文字母、数字和少量标点。这类校验不能只在前端做，必须在后端接口入口处再做一遍。

写后端校验的时候我注意避开了一个常见的坑：不要只依赖过滤黑名单或者替换危险关键字。黑名单思路本身就是落后的，因为绕过编码方式太多了。我更倾向于白名单加类型强校验的组合，白名单外的字符一律拒绝。至于是否需要引入统一参数校验框架，取决于系统本身的架构，LibSys 3这种老系统我建议手工维护一个通用的校验工具类，在入口处集中调用，比零散地在每个接口里写校验代码好维护得多。

4.3 数据库账号权限要收敛到最小

应用层修复完之后，我顺手把数据库权限也整理了一遍。LibSys 3原来用的数据库账号权限过大，居然对整库有DDL权限，也就是说应用一旦被攻破，攻击者可以直接改表结构。这是老系统常见通病，DBA图省事，一个账号管到底。

我按模块拆分了权限：前台检索模块使用只读账号，只能对书目表、馆藏表执行SELECT；读者自助服务模块使用独立账号，除了查询，只能对自己相关的表做INSERT和UPDATE；管理员后台使用单独的高权限账号，但也不允许所有表都开放DDL权限。这一步做完，就算某个模块的注入问题没改干净，造成的破坏也被限制在可控范围内。

另外，数据库层面上我还做了几件辅助工作：关闭了数据库的堆叠查询支持和部分危险函数，删除了不再使用的存储过程，设置了连接超时和查询超时。这些措施不是必需项，但能有效缩小被攻击后的影响半径。

4.4 WAF和日志监控作为兜底手段

代码层面的修复到位后，我建议再叠加一层WAF作为兜底。尤其是老系统，业务模块多、接口杂，一时半会不可能把所有历史问题全部整改完，WAF可以在流量层先拦掉一批典型的恶意请求。配置WAF的时候需要注意，规则不要太激进，否则容易误伤正常的检索请求，因为图书检索里的书名、作者、出版社这些字段本身就是五花八门的文本。

WAF只是缓解措施，不是根治方案，我在报告里特别强调了这个定位。真正管用的还是应用层修复。

日志监控也要加强。我把数据库的错误日志、应用访问日志、WAF拦截日志三者的时间字段统一对齐，设置每周自动检查的告警规则。一旦发现某个接口在短时间内出现大量异常参数，就自动通知相关负责人。对于已经暴露过的接口，我建议在WAF里单独加高敏感规则，收到告警后优先排查。

5. 常见问题与排查技巧实录

5.1 老系统改造中的踩坑记录

这次整改里我踩了好几个坑，第一个就是"改一处崩三处"。LibSys 3的代码里有大量的隐性依赖，一个查询函数在多个地方被调用，参数顺序和返回字段稍有变化，下游接口就跟着报错。所以改造时不能只盯着单个方法改，必须把调用链全部捋一遍。我采用的办法是先给查询方法加日志，观察一段时间内的真实调用情况，再动手改代码。

第二个坑是编码问题。老系统很多地方用的还是GBK或GB2312编码，在数据库连接串里配置的字符集和页面声明的字符集经常不一致。这看似和注入无关，但会直接影响到参数化查询绑定的字符串值，出现乱码甚至数据处理错误。我这次统一把数据库连接、页面编码和过滤器编码都改成了UTF-8，表面的工作量不大，背后的关联改动却不少。

第三个坑是缓存。系统里有一部分热门书目数据使用了本地缓存，改造查询逻辑后，缓存里的旧数据一段时间内还在被读取，造成修复效果没有立竿见影。这种情况需要在发布说明里写清楚缓存刷新机制，让运维配合一起操作。

5.2 问题排查速查表

我在这次项目过程中整理了一份简单的排查速查表，用来帮助团队后续自查其他模块。这里公开给大家参考。

这张表不限于LibSys 3使用，任何类似结构的Web系统都可以套用。排查的时候建议按这个顺序走一遍，能省下不少时间。

5.3 代码审计阶段的几个实操技巧

做这类老系统的SQL注入排查，我有几个实操技巧想再单独说一下。

第一，用全局搜索效率极高。在代码目录里搜索所有包含SELECT、INSERT、UPDATE、DELETE的代码行，然后人工过一遍变量来源，比逐个接口找快得多。搜索的时候别只看原生SQL写法，还要注意搜索那些关键字被拼接的情况，比如字符串里拆开写了SQL关键字。这个技巧只看代码检索结果可能发现不了，需要对项目有一定熟悉度。

第二，优先看登录和查询功能。这两类是SQL注入优先级最高的排查对象，因为登录功能直接关联身份认证，查询功能关联敏感数据读取。LibSys 3里这两个模块也是最脆弱的，基本可以确认是历史开发时最先写的部分，写完之后就再没动过。

第三，遇到拿不准的接口，宁可保守处理。有些接口可能只有内部运维才能访问，表面看风险不大。但只要它存在于对外可达的Web服务上，就按对外标准处理。我在这次项目里处理了一个只有活动推广页才使用的读者信息登记接口，原以为没什么人知道，结果上线日志里确实存在外部访问记录。

5.4 修复验证与回归测试

整改完成后的验证环节同样重要。我在修复完第一档接口后，没有直接发布到生产环境，而是在测试环境完整跑了一遍回归测试。回归测试的用例分成两类：一类是原有的正常业务流程，比如读者登录、检索图书、查看借阅历史，确保功能没有因为参数化改造出现错误；另一类是异常输入类用例，比如在参数里输入超长字符串、特殊符号、空值，确保系统能够正确拒绝。

旧系统自动化测试覆盖率一般不高，这次回归主要靠手工加脚本批量验证。我用一个简单的Python脚本向测试环境发送构造好的请求集，把返回状态码和响应内容记录下来，再对比改造前后的差异。脚本本身不复杂，但能避免人工漏测，大家可以参考下面这个简化版思路：

# 简化版回归测试脚本示例，仅用于验证接口状态 import requests test_cases = [ {"url": "https://test.example/libsys/search", "params": {"keyword": "图书馆"}, "desc": "正常检索"}, {"url": "https://test.example/libsys/search", "params": {"keyword": "'"}, "desc": "特殊字符输入"}, {"url": "https://test.example/libsys/login", "params": {"username": "123456", "password": "123"}, "desc": "正常登录"}, {"url": "https://test.example/libsys/login", "params": {"username": "1 OR 1=1", "password": "x"}, "desc": "非法输入"}, ] for case in test_cases: try: resp = requests.get(case["url"], params=case["params"], timeout=5) print(case["desc"], resp.status_code, len(resp.text)) except Exception as exc: print(case["desc"], "ERROR", exc)

回归测试通过后，我还会再等一下，观察新代码在测试环境连续运行几天的日志，确认没有出现新的数据库报错，再安排发布。

5.5 后续还要关注的几点

SQL注入问题本身处理完之后，这套系统还有一些同源的安全问题值得继续投入。一是管理员后台的弱口令和权限管控，这个问题这次已经登记但还没根本解决，建议尽快推动改造成强密码加双因素认证。二是旧系统里很多接口没有完善的审计日志，真正发生安全事件后很难回溯，这块需要专门立项补齐。三是系统的Session管理用的是老式服务端存储，没有设置合理的失效策略，长期挂机的会话存在被滥用的可能。

这些同类问题虽然不在SQL注入的范畴内，但它们和安全加固是一个整体。我在做完这次整改后向团队提了一个后续计划，把认证授权、日志审计、会话管理作为下一轮排查主题，避免漏洞修复只停留在一个单点上。

我个人在实际排查中总结出来的一个习惯是：但凡手上过了一遍老系统，一定在报告里附上"系统全景风险清单"，而不是只写本次发现的问题。安全排查的价值在于让团队看到全局，而不只是拿到一份漏洞修补清单。SQL注入这次堵住了，但同类的脆弱点可能还在别处等着。把每一次排查都当成一次梳理家底的机会，系统才会越来越稳。