报表系统筛选参数极易引发sql注入，因动态拼接where条件时若未严格校验和强制类型转换，攻击者可通过region_id=1 or 1=1等恶意输入绕过防护，导致数据泄露；必须结合白名单校验、不可绕过的强类型转换及统一参数化逻辑（如mybatis用#{}、sqlalchemy用filter）才能有效防御。
报表系统里多维度筛选参数（比如 start_date、region_id、status）一旦被拼进 SQL，就是 SQL 注入的高发入口。强制类型转换不是万能解药，但它是参数化查询失效时最关键的补救手段——前提是转换必须严格、不可绕过。
为什么报表系统的筛选参数特别危险
报表常需动态生成 WHERE 条件，比如用户勾选“华东地区”“2024年Q1”“状态=已审核”，后端可能用字典拼出："region_id = " + user_input["region_id"] + " AND create_time >= '" + user_input["start_date"] + "'"。这种写法哪怕只放行一个非数字字段（如 region_id 本该是整数却收到 "1 OR 1=1"），整条查询就崩了。
常见错误现象：
- 前端传
region_id=1%20OR%201=1，后端没校验直接拼接，查出全量数据 -
status字段允许传字符串，但代码只检查是否在预设列表里，却没拒绝"active' -- "这类带单引号的值 - 日期参数用
strftime或to_date包裹，但输入是"2024-01-01' OR '1'='1"，函数调用前已被截断
强制类型转换必须满足三个条件才有效
只写 int(user_input["region_id"]) 不够，攻击者可能传 "1,2,3" 或 "1; DROP TABLE reports"，Python 会抛异常，但若异常处理不当（比如吞掉错误并返回空结果），反而暴露逻辑漏洞。
实操建议：
-
转换前先做白名单校验：对
region_id，先检查是否匹配正则r'^\d+$'，再转int；对status，只允许["active", "pending", "closed"]中的值，不接受任何额外字符 - 转换失败必须中断执行：不能 fallback 到默认值或空字符串，更不能继续拼 SQL；应直接返回 HTTP 400 并记录告警
-
日期/时间字段禁用字符串拼接：用数据库原生函数（如 PostgreSQL 的
to_timestamp(?, 'YYYY-MM-DD')）或 ORM 的类型安全方法，而不是"'" + user_date + "'"
MyBatis 和 SQLAlchemy 中的类型强制陷阱
很多人以为用了框架就安全，但 ${} 在 MyBatis 里仍会拼接字符串，status 若写成 WHERE status = ${status}，传入 "active' OR '1'='1" 照样中招。SQLAlchemy 的 text() 也同理。
正确做法：
- MyBatis 中所有用户参数一律用
#{}，连ORDER BY字段都得走白名单映射（如sort_field = #{sortFieldEnum.value}） - SQLAlchemy 查询用
filter(User.status == status)，而非filter(text("status = '" + status + "'")) - 如果必须动态表名或字段名（极少见），用硬编码枚举或配置表查出合法值，再拼接——绝不来自用户请求
报表导出接口最容易被忽略的注入点
导出 Excel/PDF 常走同一个查询逻辑，但开发者容易放松警惕：认为“只是导出，不涉及修改”，于是绕过参数化，直接拼接 SELECT ... FROM ... WHERE ...。而攻击者专挑这类接口用 UNION SELECT 拖库。
关键提醒：
- 导出接口的 SQL 构建流程，必须和 Web 页面查询完全一致——共用同一套参数化逻辑
- 如果用了缓存（如 Redis 存 SQL 模板），确保模板里不含任何用户输入，只含占位符
- 所有导出字段名、排序字段、分组字段，都必须来自白名单，不能由
request.args.get("group_by")直接代入
最麻烦的不是写对转换逻辑，而是确保每个新增筛选条件都经过同样的校验流水线——漏掉一个 category_id，整个报表系统就等于敞开大门。
