LIMIT 动态分页导致的 SQL 注入与修复

在 Web 应用开发中，分页功能几乎是每个列表页面的标配。无论是电商商品列表、博客文章归档，还是后台管理系统的数据表格，开发者都需要通过 LIMIT 子句来控制每页返回的数据条数。然而，正是这个看似简单的分页逻辑，却常常成为 SQL 注入的隐蔽入口。很多开发者知道要对 WHERE 条件中的用户输入进行参数化处理，却忽略了 LIMIT 后面的数字同样可能被攻击者操控。

为什么 LIMIT 会成为注入点

在 MySQL 中，LIMIT 子句用于限制查询返回的行数，语法通常为 LIMIT offset, count 或 LIMIT count OFFSET offset。问题在于，MySQL 的预处理语句（Prepared Statement）在早期版本中并不支持对 LIMIT 参数进行占位符绑定。也就是说，下面这种写法在很长一段时间内是无法正常工作的：

SELECT * FROM articles LIMIT ?, ?

即便在较新的 MySQL 版本中，预处理协议对 LIMIT 的支持也有所限制，导致不少开发者选择直接将分页参数拼接进 SQL 语句。例如：

$page = $_GET['page'];
$limit = $_GET['limit'];
$offset = ($page - 1) * $limit;
$sql = "SELECT * FROM articles LIMIT $offset, $limit";

这段代码看起来逻辑清晰，但只要攻击者将 page 或 limit 参数替换为恶意 payload，就可以轻松突破查询边界。例如传入 limit=10 PROCEDURE ANALYSE(EXTRACTVALUE(1,CONCAT(0x5c,VERSION())),1)，在某些配置下就能通过报错信息泄露数据库版本。更严重的情况下，攻击者可以利用 UNION 或子查询读取其他表的数据。

常见的攻击手法

1. 联合查询注入

攻击者可以构造类似 page=1&limit=10 UNION SELECT username,password FROM users-- - 的参数。如果代码没有对 limit 做任何过滤，拼接后的 SQL 就会变成：

SELECT id,title,content FROM articles LIMIT 0, 10 UNION SELECT username,password FROM users-- -

此时攻击者就能直接获取用户表中的敏感数据。

2. 报错注入

利用 EXTRACTVALUE、UPDATEXML 等函数，攻击者可以在 LIMIT 参数中触发数据库报错，从而在错误信息中回显数据库名、表名甚至字段内容。这种手法在无法使用联合查询时尤为常见。

3. 布尔盲注与时间盲注

如果页面不直接回显数据，攻击者还可以通过 LIMIT 参数构造布尔条件或 SLEEP() 函数，根据页面响应时间或内容差异逐位推断数据。例如 limit=10 AND SLEEP(5)，如果页面延迟 5 秒返回，就说明注入条件成立。

4. 堆叠查询

在某些数据库驱动支持多语句执行的情况下，攻击者甚至可以通过 limit=10; DROP TABLE articles-- - 这样的 payload 直接破坏数据库。

修复方案

方案一：强制类型转换

最简单有效的办法是对分页参数进行严格的整数转换。在 PHP 中可以使用 intval()，在 Java 中可以使用 Integer.parseInt()，在 Python 中可以使用 int()。例如：

$page = max(1, intval($_GET['page'] ?? 1));
$limit = min(100, max(1, intval($_GET['limit'] ?? 10)));
$offset = ($page - 1) * $limit;
$sql = "SELECT * FROM articles LIMIT $offset, $limit";

由于 intval() 会将任何非数字字符串转换为 0，攻击者传入的 payload 会直接失效。同时，对 limit 设置上限（如最大 100）可以防止攻击者通过超大分页拖垮数据库。

方案二：白名单校验

如果分页大小是固定的几个选项（如 10、20、50、100），可以使用白名单机制：

$allowed = [10, 20, 50, 100];
$limit = in_array($_GET['limit'], $allowed) ? $_GET['limit'] : 10;

这种方式从根本上杜绝了任意数值的注入可能，适合对性能要求较高的场景。

方案三：使用预处理语句（MySQL 8.0+）

在 MySQL 8.0 及以上版本中，预处理语句已经支持 LIMIT 占位符。以 PDO 为例：

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

需要注意的是，必须显式指定 PDO::PARAM_INT，否则 PDO 会默认按字符串处理，导致语法错误。

方案四：ORM 与查询构建器

如果项目使用了 Laravel、Django、MyBatis 等框架，应优先使用其提供的分页方法。例如 Laravel 的 paginate()、Django 的 Paginator，这些内置方法已经对参数做了安全处理，开发者无需手动拼接 SQL。

关联安全建议

分页注入只是 SQL 注入的一个缩影。要构建完整的防御体系，还需要关注以下方面：

• XSS 的常见方式和前端如何防御：分页参数同样可能被反射到页面中，如果未做 HTML 转义，攻击者可以构造 page=<script>alert(1)</script> 触发 XSS。前端应对所有动态内容使用 textContent 而非 innerHTML，后端则应对输出进行实体编码。
• MySQL 防止 SQL 注入的几种写法：除了预处理语句，还可以使用存储过程、白名单校验、最小权限原则等。核心思想是永远不要相信用户输入，让数据与指令彻底分离。
• Linux 服务器安全加固清单：即使应用层做了防护，服务器层面也不能掉以轻心。应定期更新系统补丁、关闭不必要的端口、配置防火墙规则、启用 SELinux 或 AppArmor，并对数据库账户实行最小权限管理。

总结

LIMIT 动态分页导致的 SQL 注入之所以容易被忽视，是因为很多开发者误以为“数字参数天然安全”。事实上，只要参数参与了 SQL 语句的拼接，就存在注入风险。修复的核心原则只有一条：永远不要将用户输入直接拼接到 SQL 中。无论是强制类型转换、白名单校验，还是使用预处理语句，目的都是确保分页参数在进入数据库之前已经被严格约束。在安全开发中，多一层校验，就少一个漏洞。

未经允许不得转载：任鹏个人博客 » LIMIT 动态分页导致的 SQL 注入与修复