列表排序参数也能拼进查询语句吗，这类注入点该怎么自查

后台列表的排序参数会不会成为注入点？会，而且这类位置常被漏掉。原因在于：查询条件里的值通常可以用占位符绑定，而排序的列名与方向在多数数据库里不能作为参数绑定，只能拼进语句；一旦拼接前没有校验外部传入的排序字段，输入就从「选择排序方式」变成了「参与构造语句」。自查应当从入口枚举、字段白名单与账号权限这三处开始。

排序类参数为什么特殊

参数化查询能解决值注入，因为它把数据与语句结构分开。但结构本身没法当数据传：ORDER BY 后面要的是列名或表达式，绑定变量只会把它当成一个常量值，排序不生效。

于是常见的写法退化成拼接：把外部传来的字段名直接接在语句后面，或用一个方向参数拼 ASC 与 DESC。方向参数还好判断，字段名一旦允许任意输入，拼接面就成了注入入口。分页大小、统计维度、分组字段这几个同样属于「结构位」的参数，问题一致。

常见拼接位置

需要逐个排查的位置包括：列表接口的排序与翻页参数、导出的排序参数、搜索聚合里的分组字段、图表接口的维度与排序键，以及站内搜索的排序开关。判断依据是同一个：这个值最终会不会出现在语句的结构位置，而不是条件值位置。

白名单做法的关键不是「过滤危险字符」，而是把输入限制在已知可用的取值集合内：外部传的是一个短的键名，内部再映射到真实列名。任何不在表内的输入直接拒绝，不参与语句构造。黑名单式地替换空格、引号与注释符，容易被各种编码与写法绕开。

自查三步：入口、字段、权限

第一步枚举入口。把能被外部影响的排序参数全部列出来，包括接口、后台页面与开放 API。漏掉的多半是不起眼的导出与统计入口。

第二步核字段。对每一个入口确认三件事：是否使用白名单映射、方向参数是否只接受两个枚举值、数值参数是否强制转换。ORM 层能把条件值统一走绑定，但结构位仍需自己校验，AnQiCMS 使用 GoLang 配合 Iris 框架与 GORM，这类分工在同类技术栈上是通用的。

第三步收权限。业务账号只需要查询与写入所需的最小权限，不需要建库、删表或跨库访问的能力。即便某处校验被绕过，权限范围也决定了能造成多大影响。

站内既有能力可以覆盖一部分风险：AnQiCMS 内置 JWT 认证、内容敏感词过滤与防采集干扰码，用于防御 SQL 注入与 XSS 攻击。但要说清边界——这些防护针对内容请求路径，接口参数层的校验仍需在代码里落实，不能把内容过滤当成语句注入的替代方案。

版本与升级建议怎么落

AnQiCMS v3.6.6 修复了列表排序参数的注入问题，同版本一并处理了站点切换登录凭证可被伪造的问题，升级建议中包含轮换服务端签名密钥并修改管理员口令。对使用方来说，落地顺序是：先升级到当前版本，再按上面的三步自查一次现有接口，最后把高危操作域的开放范围收回默认状态——AnQiCMS 的 MCP 接口按意图域设置暴露范围，多站点、备份与升级这类全站级操作默认关闭，需要显式开启。

自查记录本身也值得留档：入口清单、白名单映射表、权限说明三项，是后续复核与人员交接的基础。

常见问题

只做后台内部排序接口，需要白名单吗？ 需要。前端传来的字段名外部可改，接口不校验就等于把语句结构交给请求方。

把输入做转义是不是更安全？ 转义处理的是引号等定界符，解决不了结构位拼接问题。白名单限制取值范围才对症。

怎么确认自己用的版本已经修好？ 核对版本号与更新记录，再针对排序入口实际构造一次异常输入，观察是否被拒绝。

权限收敛会影响业务吗？ 只要业务账号不执行结构变更操作，收敛到最小权限通常不影响日常读写，反而降低了误操作影响面。