攻击者通过分页参数注入SQL的案例分析

处理分页查询时，开发者常犯的一个致命错误是直接将用户传入的页码或每页条数拼接到SQL语句中。表面看这只是一个数字参数，似乎与字符串输入不同，但危险程度完全一致。攻击者根本不需要输入引号或字母，仅通过构造特殊的数值就能改变整个SQL语句的语义。我见过最经典的案例发生在一个电商系统的订单列表接口，前端传递page=2&size=20，后端直接拼接成LIMIT 20 OFFSET 40，看似无害，实则暗藏杀机。

问题的根源在于开发者对参数类型的盲目信任。很多人认为只要参数是数字类型就天然安全，但HTTP请求中的所有参数本质上都是字符串。即使后端做了类型转换，转换过程中也可能存在绕过方式。更关键的是，SQL注入不一定要破坏原有的引号结构，数值型注入往往更加隐蔽。攻击者可以在分页参数中注入联合查询、子查询甚至存储过程调用，而这些操作完全不需要单引号或双引号的参与。

分页参数注入属于典型的数值型SQL注入。与字符串型注入不同，数值型注入不需要闭合引号，攻击者直接在数字后面追加SQL代码即可。假设后端代码写成这样：String sql = "SELECT * FROM orders WHERE status=1 LIMIT " + pageSize + " OFFSET " + offset;，攻击者将pageSize的值改为20 UNION SELECT username,password,email FROM users，最终执行的SQL就变成了SELECT * FROM orders WHERE status=1 LIMIT 20 UNION SELECT username,password,email FROM users OFFSET 0。这条语句会先返回20条订单记录，然后附加返回用户表的敏感数据。

分页场景的特殊之处在于，LIMIT和OFFSET子句通常位于SQL语句的末尾，攻击者可以使用的注入技巧更加灵活。他们可以使用UNION查询追加结果集，可以使用子查询窃取数据，还可以利用时间盲注逐字符猜解数据库信息。更危险的是，很多数据库允许在LIMIT子句中使用子查询和存储过程，比如MySQL中LIMIT (SELECT COUNT(*) FROM sensitive_table)这样的写法在某些版本中是合法的。

我亲自复盘过一个教育平台的注入漏洞。该平台的课程列表接口接收page和limit两个参数，后端使用PHP开发，数据库是MySQL 5.7。攻击者的第一步是探测，将limit参数改为20,1，观察返回结果是否变化。发现返回数据量确实改变后，确认参数被直接拼接。第二步测试注入点类型，将limit改为20 UNION SELECT 1，页面报错显示列数不匹配，由此推断出原始查询的列数。第三步使用ORDER BY试探列数，将limit改为20 ORDER BY 10，逐步增加数字直到不再报错，确定原始查询有9个字段。

确定列数后，攻击者构造了这样的payload：limit=20 UNION SELECT 1,2,3,4,5,6,7,8,9 FROM information_schema.tables WHERE table_schema=database()。返回结果中，原本显示课程标题的位置出现了数据库表名列表。接着攻击者定位到users表，进一步查询列名，最终通过concat_ws函数将用户名和密码哈希值拼接在课程描述字段中输出。整个过程没有触发任何WAF告警，因为所有payload都是纯数字和SQL关键字的组合，看起来就像正常的复杂查询。

最容易出现问题的代码模式是字符串拼接，这在各种编程语言中都有体现。PHP中最常见的形式是：

$page = $_GET['page'];
$offset = ($page - 1) * $limit;
$sql = "SELECT * FROM products WHERE category_id = $cat_id LIMIT $limit OFFSET $offset";

Java中使用Statement而非PreparedStatement同样危险：

String pageSize = request.getParameter("size");
String sql = "SELECT * FROM products WHERE status=1 LIMIT " + pageSize;
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

Python的字符串格式化也是重灾区：

page = request.GET.get('page')
offset = (int(page) - 1) * limit
query = f"SELECT * FROM articles WHERE published=1 LIMIT {limit} OFFSET {offset}"
cursor.execute(query)

注意第三行代码中虽然对page做了int转换，但攻击者可以传入非数字字符串导致转换异常，或者利用科学计数法、十六进制表示等技巧绕过简单的类型检查。而且limit参数本身可能没有被转换，攻击者完全可以在limit参数中注入恶意代码。

不同数据库在LIMIT子句中的注入利用方式存在差异。MySQL 5.x版本支持在LIMIT后面使用子查询和UNION，攻击者可以构造LIMIT 1 UNION SELECT ...这样的payload。MySQL还支持LIMIT 1 PROCEDURE ANALYSE()这种写法，可以调用存储过程获取表结构信息。PostgreSQL的LIMIT子句同样支持子查询，但语法要求更严格，通常需要配合OFFSET使用。SQL Server使用TOP关键字而非LIMIT，但在OFFSET FETCH子句中同样存在注入风险。

一个高级利用技巧是利用LIMIT子句进行盲注。当页面没有直接回显注入结果时，攻击者可以通过控制返回的记录数来判断条件真假。比如构造LIMIT (SELECT CASE WHEN (SELECT SUBSTRING(password,1,1) FROM users WHERE id=1)='a' THEN 10 ELSE 0 END)，如果页面返回了10条记录，说明密码第一位是a，否则不是。这种方法逐字符猜解数据，虽然速度较慢但非常隐蔽，很难被日志分析发现。

第一层防御是参数化查询，这是解决SQL注入最根本的方法。使用PreparedStatement时，LIMIT和OFFSET的参数同样应该用占位符传递，而不是拼接到SQL字符串中。Java的正确写法是：

String sql = "SELECT * FROM products WHERE status=1 LIMIT ? OFFSET ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setInt(1, pageSize);
pstmt.setInt(2, offset);
ResultSet rs = pstmt.executeQuery();

PHP使用PDO的写法：

$stmt = $pdo->prepare("SELECT * FROM products WHERE status=1 LIMIT :limit OFFSET :offset");
$stmt->bindValue(':limit', $limit, PDO::PARAM_INT);
$stmt->bindValue(':offset', $offset, PDO::PARAM_INT);
$stmt->execute();

第二层防御是严格的类型校验。在参数进入SQL查询之前，必须验证参数是否为合法的正整数。使用正则表达式检查参数值是否只包含数字字符，同时检查数值范围是否合理，比如页码不应超过10000，每页条数不应超过100。这种白名单校验可以有效拦截包含SQL关键字的恶意输入。

第三层防御是使用ORM框架的安全分页方法。现代ORM如MyBatis、Hibernate、Entity Framework都提供了安全的分页API，这些API内部使用参数化查询，开发者不需要手动拼接SQL。但要注意，使用ORM的原生SQL功能时仍需保持警惕，不能因为用了ORM就放松对参数的校验。

第四层防御是数据库权限最小化。应用程序连接数据库的账号只应拥有执行SELECT、INSERT、UPDATE、DELETE等必要操作的权限，不应拥有DROP、ALTER等DDL权限，更不应拥有访问系统表的权限。即使发生注入，攻击者也无法通过information_schema获取数据库结构，无法读取敏感系统表，攻击面被大幅压缩。

分页参数注入经常能绕过WAF的检测规则。原因在于大多数WAF对数字类型参数的检查较为宽松，主要关注字符串参数中的单引号、双引号和SQL关键字。当攻击者将payload放在数字参数中时，WAF可能根本不会对该参数进行SQL注入检测。即使检测，攻击者也可以使用MySQL的注释符、换行符、括号等技巧对payload进行混淆，比如将UNION写成UN//ION，或者使用等效的数学表达式替代关键字。

有效的检测策略应该对所有参数一视同仁，无论参数看起来是什么类型。日志分析系统需要关注LIMIT和OFFSET参数中出现SQL关键字的情况，建立针对分页参数的异常检测模型。同时，在代码审计中应将所有拼接SQL的操作标记为高危点，特别是涉及LIMIT、OFFSET、ORDER BY等看似安全的子句时更要仔细审查。

分页参数注入SQL是一个被严重低估的安全风险。开发者习惯性地认为数字参数不需要防注入处理，这种认知偏差导致了大量漏洞的产生。修复这类问题的成本其实很低，使用参数化查询即可从根本上解决，但前提是开发者必须意识到问题的存在。建议开发团队将分页参数的安全处理纳入代码规范，在代码审查时重点关注所有SQL拼接操作，无论拼接的是字符串还是数字。安全测试人员也应该将分页接口列为必测项，使用自动化工具结合手工测试覆盖各种注入场景。