Django Admin 自定义 search_fields、list_filter、get_search_results()、get_queryset() 或拼接原始 SQL 会引入 SQL 注入风险；必须避免字符串拼接，所有用户输入须经白名单校验或参数化绑定，Trunc/Extract 的 kind/lookup_name 参数需严格限制范围。
直接使用 Django Admin 默认行为基本不会触发 SQL 注入，但一旦你自定义了 search_fields、list_filter、get_search_results()、get_queryset()，或在 ModelAdmin 中拼接原始 SQL，风险就立刻出现。
哪些 Admin 配置项会引入 SQL 注入？
Django Admin 本身对用户输入做了参数化处理，但以下几处是常见“破口”：
-
search_fields若配合__regex或__iregex，且未限制字段类型或长度，攻击者可注入正则元字符干扰查询逻辑（虽不直接执行任意 SQL，但可能绕过过滤或引发 DB 异常暴露结构） -
list_filter中使用自定义SimpleListFilter时，若在queryset()方法里用字符串格式化拼接WHERE条件（如f"status = '{value}'"），立即高危 - 重写
get_search_results()并手动构造extra(where=[...])或raw()查询，且未对request.GET参数做校验或参数绑定 - 在
get_queryset()中调用connection.cursor().execute()且传入未经处理的request.GET值作为 SQL 字符串插值
如何安全地扩展 Admin 的搜索与过滤逻辑？
核心原则：绝不字符串拼接 SQL；所有用户可控输入必须走 ORM 查询链或参数化游标。
- 用
Q对象组合复杂条件，例如：Q(title__icontains=value) | Q(content__icontains=value)，Django 自动转义 - 若必须模糊匹配特殊字段（如 JSONField 内容），改用
__contains或__icontains，避免extra(where=...) - 自定义
SimpleListFilter时，在queryset()中只使用.filter(status=value)这类标准 ORM 调用，value 必须来自预设选项（self.used_parameters.get('status')后再白名单校验） - 真要跑原生 SQL，必须用
cursor.execute("SELECT ... WHERE col = %s", [user_input])，不能用%格式化或f-string
Trunc() 和 Extract() 函数的坑怎么避？
CVE-2022-34265 明确指出：Trunc() 的 kind 参数和 Extract() 的 lookup_name 若直接受控于用户输入（比如 URL 传 ?trunc=year 然后直接喂给 Trunc('date', kind=request.GET['trunc'])），就会触发 SQL 注入。
- 禁止将 request 参数直接传入
kind或lookup_name—— 即使看起来只是字符串 - 必须白名单校验，例如：
allowed_kinds = {'year', 'month', 'day'}，然后if kind not in allowed_kinds: raise ValueError - 注意：Django 4.0.6+ 和 3.2.14+ 已修复该漏洞，但老版本项目若未升级，仅靠白名单也能彻底规避
最容易被忽略的是：Admin 的 search_fields 默认支持 __exact、__iexact、__contains 等，但开发者常误以为加个 __regex 也一样安全——其实不然，regex 模式本身由数据库引擎解析，恶意模式（如 .*|.*）可能拖垮查询或泄露信息。真需要正则，应先在 Python 层校验 pattern 是否符合白名单规则，再传入 ORM。
