网站分页查询功能防SQL注入防护技巧

网站分页查询功能是SQL注入攻击的重灾区。开发人员习惯性地把页码参数直接拼接到SQL语句里，等于给攻击者留了一扇没上锁的后门。分页查询通常涉及LIMIT、OFFSET或者ROW_NUMBER这类子句，很多人误以为这些位置不会被执行恶意代码，实际上攻击者可以通过闭合引号、堆叠查询、联合查询等手段，在看似无害的页码参数里注入致命指令。更隐蔽的是，ORDER BY子句在分页场景中几乎必然出现，而排序字段往往来自前端传参，这个位置极难参数化，成为防御链条上最薄弱的一环。

第一道防线是把参数类型锁死。页码page参数必须是正整数，页大小pageSize必须限制在合理范围，比如1到100之间。很多程序员只在前端做了限制，后端直接接收字符串就拼进SQL，这是典型的自欺欺人。后端必须做强制类型转换，Java里用Integer.parseInt包裹异常捕获，PHP里用intval强制转换，Python里用int()配合try-except。但类型转换只是基础，排序字段order和排序方向sort才是真正的难点。这两个参数是字符串类型，无法简单转成数字，必须上白名单。定义一个允许排序的字段名数组，比如['id','username','create_time','update_time']，前端传过来的order值必须在这个数组里完全匹配才放行，否则直接使用默认排序字段。排序方向同理，只允许'ASC'和'DESC'两个值，大小写统一转换后再比对。白名单要写在配置文件或常量类里，不要散落在业务代码中，方便统一维护和审计。

绝大多数SQL注入可以通过参数化查询彻底杜绝。以MySQL为例，使用PDO或者MySQLi的预编译语句，页码和页大小作为参数绑定，数据库驱动会自动处理转义。关键代码大致如下：

// PHP PDO示例
$page = intval($_GET['page']) ?: 1;
$pageSize = min(intval($_GET['pageSize']) ?: 20, 100);
$offset = ($page - 1) * $pageSize;
$stmt = $pdo->prepare("SELECT * FROM articles ORDER BY id DESC LIMIT :limit OFFSET :offset");
$stmt->bindValue(':limit', $pageSize, PDO::PARAM_INT);
$stmt->bindValue(':offset', $offset, PDO::PARAM_INT);
$stmt->execute();

注意LIMIT和OFFSET子句在MySQL的预编译中需要绑定整型参数，PDO::PARAM_INT必须明确指定，否则可能被当作字符串处理导致语法错误。不同数据库对LIMIT子句的参数化支持程度不同，PostgreSQL的LIMIT和OFFSET完全支持参数化，SQL Server的OFFSET FETCH子句同样支持。但ORDER BY子句的情况就复杂了，因为排序字段名和排序方向是SQL关键字或标识符，不是数据值，绝大多数数据库驱动不允许在预编译语句中参数化标识符。这就是为什么ORDER BY必须依赖白名单校验，而不是参数化。有些框架提供了排序字段的转义方法，比如给字段名加上反引号，但这只能防止关键字冲突，不能防止注入，攻击者依然可以构造包含子查询的恶意字段名。白名单是唯一可靠的方案。

很多人以为用了成熟的ORM框架就高枕无忧了，实际情况并非如此。MyBatis的PageHelper插件在早期版本中存在ORDER BY注入漏洞，因为它允许前端传入排序字符串并直接拼接。即使使用MyBatis的#{}占位符，也只能保护WHERE子句里的值，ORDER BY后面的${}如果直接接收前端参数，照样会中招。正确的做法是在Mapper XML里对排序字段使用${}时，必须确保传入的变量已经过白名单校验，而不是把原始的用户输入直接丢进去。Hibernate的Criteria查询和JPQL同样存在类似风险，当使用字符串拼接构建动态排序时，注入点就出现了。Laravel的Eloquent ORM中，orderBy方法接收的两个参数如果直接来自用户输入，同样需要先做白名单过滤。框架只是工具，安全意识不到位，再好的框架也能写出漏洞百出的代码。

分页查询的注入点不一定直接来自URL参数。如果网站有个搜索功能，用户输入的关键词被存入数据库，后续的分页查询在展示这些历史记录时，如果拼接方式不当，就可能触发二次注入。攻击者先提交一段包含SQL片段的数据，比如在用户名注册时填入"admin'--"，这个数据被安全地存入数据库，但在某个分页查询用户列表的功能中，开发人员把已存储的用户名直接拼接到ORDER BY或者WHERE子句里，注入就被触发了。防御二次注入的核心原则是：任何来自数据库的数据在拼入SQL语句时，同样要经过参数化处理或严格转义，不能因为数据是自己数据库里取出来的就掉以轻心。数据来源不可信，无论它来自用户输入、第三方接口还是自己的数据库。

即使参数化查询做好了，如果数据库错误信息直接暴露给前端，攻击者可以通过构造特殊输入来探测数据库结构，为后续的盲注攻击铺路。分页查询中，如果页码超出范围或者OFFSET计算出现负数，数据库可能抛出异常。生产环境必须关闭详细的数据库错误输出，统一返回通用的错误页面或JSON格式的错误信息，不包含任何SQL错误代码、表名、字段名等敏感信息。同时，对分页参数的边界值做前置校验，page小于1时直接设为1，pageSize超过上限时强制截断，避免无效请求打到数据库层。应用层的参数校验要跑在数据库查询之前，这既是性能优化，也是安全防护。

Web应用防火墙可以识别常见的SQL注入特征，比如单引号闭合、UNION SELECT、SLEEP函数等，在请求到达应用服务器之前就进行拦截。但WAF不是万能的，分页参数里的注入载荷可能非常隐蔽，比如通过URL编码、十六进制编码绕过规则库。把WAF当作最后一道防线，而不是唯一的防线。更有效的是在应用层记录分页查询的完整SQL日志，包括绑定参数的实际值，配合入侵检测系统分析异常查询模式。一旦发现某个IP频繁尝试不同的排序字段值，或者page参数出现非数字字符，立即触发告警。日志要脱敏处理，不能记录用户密码等敏感字段，但SQL语句结构和参数类型必须完整保留。

大型项目中，ORM和原生SQL经常混用。分页查询可能用ORM的链式调用构建，但某些复杂的数据统计又不得不写原生SQL。问题在于，开发人员可能在ORM的查询构建器中放松警惕，习惯性地把用户输入直接拼接。必须建立编码规范，明确禁止在原生SQL中使用字符串拼接的方式处理任何外部输入，所有动态值必须通过参数绑定。对于动态表名、字段名、排序方向这类无法参数化的部分，统一封装一个安全的分页查询工具类，内部实现白名单校验逻辑，对外暴露简洁的API，让业务开发人员不需要直接接触SQL拼接。代码审查时，重点检查所有包含LIMIT、OFFSET、ORDER BY、GROUP BY的SQL语句，确认参数来源和校验逻辑。

为了提升性能，分页查询的结果经常被缓存。缓存键通常包含查询条件和页码信息，如果缓存键直接使用未校验的用户输入拼接，虽然不会造成SQL注入，但可能导致缓存键冲突或缓存穿透攻击。攻击者可以构造大量不同的排序参数值，每个请求都生成唯一的缓存键，绕过缓存层直接打到数据库，造成性能雪崩。因此，分页查询的缓存键应该基于校验后的参数生成，非法参数被过滤后统一使用默认值，这样恶意请求的缓存键会收敛到有限的数量，缓存层能正常发挥作用。同时，对来自同一IP的频繁分页请求做速率限制，防止爬虫和恶意扫描拖垮数据库。

分页查询防SQL注入的本质，是对所有进入SQL语句的外部数据保持零信任。类型强制转换、白名单校验、参数化查询这三板斧，能解决百分之九十五以上的问题。剩下的边角情况，靠错误信息管控、日志监控和架构层面的安全设计来兜底。安全不是某个点的单点防御，而是贯穿整个请求生命周期的纵深防护体系。