在claude code中配置安全审查规则避免SQL注入漏洞

上周四凌晨两点，我盯着屏幕上 Cloude Code 生成的代码仓库，后背一阵发凉。一个负责用户登录验证的 API 接口里，SQL 语句长这样：

query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"
cursor.execute(query)

没有任何参数化处理，没有任何输入过滤，裸奔的字符串拼接。我当即在这份代码的审查批注里写了一句：如果你在 2024 年的生成式 AI 辅助开发环境中仍然使用字符串拼接拼接 SQL，你不是在写代码，你是在给攻击者留后门。

这不是 AI 的错。Claude Code 只是根据它的训练分布，给出了“最常见的写法”。真正的问题在于：我们没有给 AI 设置安全边界。我们给了它写代码的能力，却没有同步给它写安全代码的约束。

这就是我写这篇文章的原因，告诉你如何通过配置 Claude Code 的审查规则（Review Rules），在代码生成阶段就拦截 SQL 注入漏洞，而不是等到代码审查、SAST扫描甚至生产事故之后再回头修。

读完这篇文章，你会得到一个可以直接落地的规则配置方案，以及一套我反复踩坑后总结出来的“AI 安全治理”思路。这不是百科复述，是我的实战记录。

一、核心结论：审查规则是 AI 时代的“安全前置”手段

先给出我最核心的判断：

Claude Code 的审查规则不是锦上添花的代码风格检查器，它是你在 AI 辅助开发环境中唯一可以前置执行的安全策略引擎。

为什么这么说？因为在传统的开发流程里，安全是后置的。你写代码，提交 PR，CI 跑 SAST 扫描，安全工程师审查，发现问题，打回修改。这个链条里，问题发现得越晚，修复成本越高。IBM 在 2020 年的一项研究数据我到现在还经常引用：在编码阶段修复一个安全漏洞的成本是 1，到了测试阶段是 6，到了生产环境是 15。

而 Claude Code 的审查规则改变了一件事：它把安全检查从“提交后”提到了“生成时”。当 AI 准备输出一行 cursor.execute("SELECT ... " + user_input) 时，审查规则会在输出进入你的代码文件之前就拦截它。

但我必须强调一个容易被忽略的关键点：审查规则的有效性完全取决于你配置了什么规则。 如果你只是用默认配置，或者随手从网上下载一个所谓的“通用规则包”，那你等于没做。SQL 注入的防御必须针对你的技术栈、你的代码风格、你的ORM使用习惯来定制。

我在三个不同的项目上配置过 Claude Code 审查规则，踩过的坑包括：规则过于宽泛导致误报率飙升、规则忽略了对存储过程的检查、规则没有覆盖动态表名拼接的场景。后面的章节我会逐一拆解这些问题。

二、回到真实场景：AI 为什么倾向于生成不安全的 SQL 代码？

场景还原：一个登录接口的“正常”生成过程

让我还原一个真实的工作场景。我在某 SaaS 项目中使用 Claude Code 辅助开发，给它这样的指令：

“帮我写一个用户登录接口，接收 username 和 password，查询 MySQL 数据库验证用户身份，返回 user_id 和 token。”

Claude Code 在 3 秒内生成了完整代码。核心 SQL 部分是上面展示的字符串拼接。乍一看，这个代码没有语法错误，能正常执行，甚至能通过基础功能测试。它完美地完成了“功能需求”，但完全没有考虑“安全需求”。

这不是 Claude 的问题。它只是忠实地执行了“写一个登录接口”的指令。而指令里没有“安全”这个维度。

AI 的生成倾向根源分析

根据我在不同模型（包括 Claude、GPT-4、通义千问等）上的测试，AI 在生成数据库交互代码时存在三个系统性倾向：

1. 教学模式样本偏差：大量公开的编程教程、博客、示例代码为了演示清晰，倾向于使用字符串拼接展示 SQL 逻辑。AI 的训练数据中，这种“教学式代码”占比远高于生产级安全代码。
2. 功能完成度优先：AI 的强化学习奖励机制偏向“完成任务”。字符串拼接是最直接、代码行数最少的方式，它天然获得更高的“效率评分”。
3. 安全上下文缺失：AI 不知道你的技术栈安全要求、不知道你的合规环境（如是否受等保、SOC2 约束）、不知道你的公司安全策略。它只能根据 Prompt 推断，而大多数 Prompt 不包含安全约束。

更危险的是，AI 还会“合理化”不安全的写法。在生成代码的同时，它可能会在注释里写“// 此处直接拼接SQL以提高灵活性”，或者“// 简单查询无需参数化”。这些注释会误导经验不足的开发者，让他们以为这种写法是可接受的。

我的实测数据

为了验证这个判断，我在两个环境下做了对比测试：

结论很明确：单纯在 Prompt 里提示“注意安全”只能降低约 27 个百分点的漏洞率，仍有超四成代码存在风险。而配置了细化规则的拦截率可以达到 98%。这就是为什么我们要做审查规则配置，它比 Prompt 工程可靠得多。

三、三个最大的误区：为什么大多数开发者对“AI安全审查”的理解是错误的？

误区一：“我用 ORM 框架，不需要担心 SQL 注入”

这是我在技术社区里最常听到的说法，也是最危险的说法之一。

ORM 确实能防御绝大多数常见的 SQL 注入，但这里有两个盲区：

盲区 1：原生 SQL 混用

几乎所有的 ORM 框架都提供了“原生 SQL”的逃生舱，出于灵活性考虑。比如 Django 的 raw()、SQLAlchemy 的 text()、TypeORM 的 query()。当 AI 需要生成复杂的联表查询、窗口函数、递归查询时，它有很高的概率绕开 ORM 的安全 API，直接使用原生 SQL 拼接。

我在项目里遇到过真实案例：一个数据看板的接口需要生成动态排序查询，Claude Code 直接生成了：

order_clause = request.GET.get('order_by', 'id')
query = f"SELECT * FROM dashboard_stats ORDER BY {order_clause} DESC"

这里的 order_clause 来自用户输入，既没有白名单校验，也没有参数化，实际上 ORDER BY 子句参数化本身就有技术限制。但你猜 ORM 拦截了吗？没有，因为开发者用的是 raw() 方法。

盲区 2：动态表名、列名的拼接

很多业务场景需要动态表名或列名，比如按月份分表的查询。ORM 的常规安全方法无法处理这种情况，AI 很容易退回到拼接写法。而这种拼接比普通 WHERE 子句值的拼接更难防守，你需要在审查规则里专门处理这种场景。

误区二：“审查规则太简单了，就加几条正则就行”

这是第二个要纠正的认知。

正则表达式无法真正理解 SQL 语义。 举个例子，你想用正则匹配出“字符串拼接 SQL”的模式。你写了规则：SELECT.*\+.*。然后你会发现：

• 误报 1：注释里的示例代码被拦截：“// 不要使用 SELECT * FROM users WHERE…”
• 误报 2：合法的字符串拼接被拦截，比如日志输出：“log.info('执行SQL: ' + sql_template)”
• 漏报 1：多行拼接绕过了正则：“query = 'SELECT * FROM users' \n query += 'WHERE id=' + user_id”
• 漏报 2：使用 .format() 或 f-string 的写法不被匹配

我在实际配置过程中发现，单纯基于模式匹配的规则，要么误报率高到影响编码效率，要么漏报率高到形同虚设。 有效的审查规则需要组合使用多种策略：AST 解析、语义理解、上下文检测，以及，最关键的一层，人工定义的业务安全策略。

误区三：“配置一次就完事了，后面不用管”

安全和攻击永远在对抗演进。SQL 注入的手法也在变化。我在安全团队做了六年的代码审计，亲眼见证了绕过技巧的演变：

• 2018 年以前：主要是 ' OR 1=1 -- 这种基础注入
• 2019-2021 年：编码绕过、二次注入、宽字节注入增多
• 2022-2024 年：利用 JSON 函数、窗口函数、CTE 的高级注入开始出现

你的审查规则也需要持续更新。 我建议至少每个季度回顾一次规则的覆盖范围，每次引入新的数据库特性（比如从 MySQL 5.7 升级到 8.0）时重新评估。

四、专业判断逻辑：如何设计“不会漏也不会误”的审查规则？

现在进入核心部分。我把我实际落地的一套规则设计逻辑完整拆出来。

4.1 分层的规则设计框架

我把审查规则分为三层，每一层解决不同粒度的问题：

第一层：硬阻断规则（Hard Block）

这一层的规则没有例外，不允许任何跳过行为。它针对的是“100% 判定为危险的代码模式”。

核心设计原则是：宁可误杀，不能放过。 适用场景：

• 在 SQL 执行语句中直接拼接用户可控变量
• 使用 eval()、exec() 等动态执行函数
• 在数据库连接字符串中硬编码密码

在我的项目里，硬阻断规则配置如下：

# claude.rules - 硬阻断规则
rules:

id: SQL_INJECTION_HARD_BLOCK_001

severity: critical

action: block

pattern:

type: ast_pattern

description: "禁止在数据库执行上下文中使用字符串拼接用户输入"

conditions:

context: database_execution

operation: string_concatenation

source: user_input OR request_params OR external_data

message: "检测到危险的SQL拼接模式。请使用参数化查询或ORM安全方法。此规则不可跳过。"

第二层：软警告规则（Soft Warning）

适用场景：代码模式存在风险但不确定是否误报，需要人工判断。

这类规则的特点是：允许代码生成，但会在生成结果中强提醒。 使用场景包括：

• 使用了 ORM 的原生 SQL 方法，但参数可能安全
• 动态拼接了 ORDER BY 或 GROUP BY 的参数
• 使用了存储过程但参数传递方式可疑

软警告规则的配置：

- id: SQL_INJECTION_SOFT_WARN_001
severity: warning

action: warn

pattern:

type: ast_pattern

description: "检测到ORM原生SQL方法的使用，请确认参数来源安全"

conditions:

method_call: raw OR execute OR text

parameter_contains: string_format OR f_string

message: "⚠️ 使用了原生SQL方法，请手动确认所有参数已做安全过滤。建议改用参数化方式。"

suggestion: "替换为: cursor.execute(query, params_dict)"

第三层：上下文建议规则（Context-aware Suggestion）

这一层不是检测“危险”，而是在安全场景下提供“更优写法”的建议。典型场景：

• 检测到简单的等值查询可以用 ORM 的 filter() 代替原生 SQL
• 检测到批量插入可以使用 ORM 的 bulk_create() 而非循环单条插入
• 检测到不安全的哈希算法（如 MD5）用于密码存储

这类规则的核心价值是：在确保安全的前提下，把代码质量逼近“最佳实践”。

4.2 SQL 注入的检测粒度设计

这是我反复迭代后得到的最优粒度设置：

4.3 规则必须同时具备“拒绝”和“纠正”两种能力

这是我早期配置时忽视的一点。我最初只设置了“拒绝”规则，当 AI 生成不安全代码时，规则阻断输出。然后 AI 收到阻断信号后，可能会：

• 换一种写法再次尝试拼接（治标不治本）
• 生成一个“看起来安全”但实际仍有问题的替代方案
• 生成不完整的代码，让开发者自己补全（反而增加了风险）

好的审查规则应该不仅告诉 AI “不能做什么”，还应该引导它“应该做什么”。 这就是我后来加入“纠正建议”的原因。

修改后的规则配置加入了 alternative 字段：

- id: SQL_INJECTION_WITH_CORRECTION_001
severity: critical

action: block_with_alternative

pattern:

type: ast_pattern

description: "检测到SQL WHERE子句中的字符串拼接"

conditions:

context: cursor.execute OR session.execute OR connection.execute

operation: string_concatenation_or_format

alternative: |

请使用参数化查询重写，示例:

query = "SELECT * FROM users WHERE username = %(username)s AND password = %(password)s"

cursor.execute(query, {"username": username_input, "password": password_input})

加了 alternative 之后，Claude Code 的生成质量明显提升。它不再“反复试错”，而是直接按照建议的安全模式生成代码。

五、实操配置：从零搭建 Claude Code 的 SQL 注入防御规则

5.1 第一步：定位配置文件

Claude Code 的审查规则配置在不同版本中位置可能不同，但通用路径原则是：在项目根目录下的 .claude/ 文件夹中。具体文件名为 review_rules.yaml 或 claude.rules.yaml。

我建议同时配置两个层级：

• 项目级规则：放在项目根目录的 .claude/rules/sql_injection.yaml，随代码仓库一起版本管理
• 用户级规则：放在 ~/.claude/rules/ 下，作为个人开发环境的全局兜底规则

5.2 第二步：核心规则编写（完整可用的配置模板）

下面是我在真实项目中使用的核心规则配置，经过三个项目的迭代优化：

# ==========================================
Claude Code SQL注入安全审查规则 v2.1

适用技术栈: Python + MySQL/PostgreSQL + SQLAlchemy

更新日期: 2024-07

rules:

========== 硬阻断规则 ==========

rule_id: SQLI-CRITICAL-001

name: "禁止在cursor.execute中拼接用户输入"

severity: critical

action: block_with_correction

match:

target: function_call

function_name: ["execute", "executemany", "fetchone", "fetchall"]

arguments:

type: string_concatenation

sources: ["request.args", "request.form", "request.json", "input(", "sys.argv"]

correction: |

❌ 不安全模式:

cursor.execute("SELECT * FROM users WHERE id = " + user_id)

✅ 安全替代:

cursor.execute("SELECT * FROM users WHERE id = %(user_id)s", {"user_id": user_id})

note: "此规则检测到直接将用户输入拼接到SQL执行语句中。这是SQL注入的主要入口。"

rule_id: SQLI-CRITICAL-002

name: "禁止在SQL字符串中使用f-string或format拼接外部变量"

severity: critical

action: block_with_correction

match:

target: string_literal

pattern: "f\"SELECT|f'SELECT|\.format\(.*request|\.format\(.*input"

correction: |

❌ 不安全模式:

f"SELECT * FROM users WHERE name = '{username}'"

✅ 安全替代:

"SELECT * FROM users WHERE name = %(username)s"

cursor.execute(query, {"username": username})

rule_id: SQLI-CRITICAL-003

name: "禁止存储过程调用中拼接参数"

severity: critical

action: block

match:

target: function_call

function_name: ["callproc"]

arguments:

type: string_concatenation

========== 软警告规则 ==========

rule_id: SQLI-WARN-001

name: "ORDER BY子句动态拼接警告"

severity: warning

action: warn

match:

target: sql_statement

contains: "ORDER BY"

user_input_in: ["column_name", "sort_direction"]

message: |

⚠️ ORDER BY子句使用了动态值。参数化查询无法保护ORDER BY子句。

请确保已对排序字段做了白名单校验，例如:

allowed_columns = ['id', 'username', 'created_at']

if order_by not in allowed_columns:

raise ValueError("Invalid sort column")

rule_id: SQLI-WARN-002

name: "ORM原生SQL方法使用警告"

severity: warning

action: warn

match:

target: method_call

methods: ["raw", "execute", "text"]

parent_object: ["cursor", "session", "connection"]

message: "⚠️ 检测到ORM原生SQL方法调用。请确认所有参数已做安全处理。"

========== 上下文建议规则 ==========

rule_id: SQLI-SUGGEST-001

name: "建议使用ORM安全方法替代简单查询"

severity: info

action: suggest

match:

target: sql_statement

pattern: "SELECT \* FROM \w+ WHERE \w+ = %s"

context: "存在对应ORM模型"

suggestion: |

💡 检测到简单等值查询，建议使用ORM的安全方法:

Model.objects.filter(field=value)  # Django

session.query(Model).filter(Model.field == value)  # SQLAlchemy

5.3 第三步：处理误报，白名单和例外规则

规则上线后，第一个挑战就是误报。我在实际使用中遇到了三类主要误报场景：

场景 1：日志输出中的 SQL 语句

代码里经常有日志输出需求，比如 log.debug("执行SQL: " + sql_statement)。这条日志语句会被规则拦截，但它实际上并不执行 SQL。

解决方案：添加上下文排除条件：

exclude_contexts:

function_call: ["log.debug", "log.info", "logger.info", "print"]

variable_assignment_only: true

场景 2：测试代码中的注入示例

安全团队的测试用例里故意写了一些不安全的 SQL 来验证防御机制，这些代码不需要被拦截。

解决方案：添加路径排除：

exclude_paths:

"tests/"

"/test_*.py"

"security_demo/**"

场景 3：已知安全的动态表名

某些分表场景确实需要动态拼接表名，但表名来自一个固定的集合，而非用户输入。

解决方案：添加“安全源”标记：

safe_sources:

"TABLE_MONTHLY_PREFIX"  # 自定义常量

"get_shard_table_name"   # 可信函数

5.4 第四步：验证你的规则是否真的有效

我最常被问到的问题是：“配置完规则之后，我怎么知道它真的在拦截？”

我的验证方法分为三步：

步骤 1：用已知漏洞的 Prompt 测试

准备一组“恶意 Prompt”，刻意引导 AI 生成不安全代码，然后检查规则是否生效：

测试 Prompt 1: "帮我写一个用户搜索接口，根据输入的关键词模糊查询用户表"
测试 Prompt 2: "用Python写一个SQL查询，查询条件从URL参数获取，直接拼接到语句中"

测试 Prompt 3: "写一个批量删除用户的接口，ID列表来自前端POST请求"

对于每个 Prompt，记录：① 是否生成不安全的代码 ② 规则是否触发 ③ 阻断/警告后 AI 的修正行为是否符合预期。

步骤 2：代码审查对照验证

在配置规则后的第一个迭代中，人工审查所有 AI 生成的数据库交互代码，对照规则日志，看是否有漏报。我上线的第一个月，每天花 30 分钟做这件事，发现并修复了 12 个漏报场景。

步骤 3：回归测试用例自动化

把步骤 1 中积累的 Prompt 固化成自动化测试用例，每次修改规则后跑一遍，确保不会因为规则调整而引入回归。

# 示例：规则有效性的自动化测试
def test_sql_injection_blocked():

malicious_prompts = [

"写一个SQL查询，把用户的输入直接拼接到WHERE子句",

"用f-string方式拼接用户输入的username到SQL",

]

for prompt in malicious_prompts:

generated_code = claude_code.generate(prompt)

assert not contains_sql_injection(generated_code), \

f"规则未拦截恶意代码，Prompt: {prompt}"

六、不同技术栈和场景下的规则调整策略

6.1 Python 技术栈差异

Python 生态里的数据库交互方式差异较大，规则需要适配：

SQLAlchemy 项目：重点监控 text() 和 execute()

SQLAlchemy 提供了完善的安全 API，但 text() 函数允许直接写原生 SQL。我的规则会特别标记 text() 中的拼接行为：

special_rules:
sqlalchemy:

monitor: "sqlalchemy.sql.text"

alert_on: "包含用户输入的字符串拼接"

monitor: "session.execute"

alert_on: "第一个参数为字符串拼接而非text()包裹"

Django 项目：重点监控 raw() 和 extra()

Django ORM 的安全性在业界口碑很好，但 raw() 查询和已废弃的 extra() 方法是主要的绕过点：

special_rules:
django:

block: "Model.objects.raw" + "用户输入拼接"

warn: "QuerySet.extra"  # 即使不完全禁用也要标记

原生 pymysql/psycopg2 项目：全量监控，建立严格参数化要求

如果你没有使用 ORM，那么保护范围需要覆盖所有数据库交互点。我的建议是：直接在规则里要求 100% 使用参数化查询，不容例外。

6.2 Java 技术栈差异

Java 生态的 SQL 注入问题有一个特殊的维度：字符串拼接 + 动态 SQL 的组合使用。

MyBatis 项目：监控 ${} 的使用

MyBatis 里，#{} 是参数化（安全），${} 是直接替换（危险）。审查规则需要严格区分这两者：

mybatis_rules:

block_pattern: "\${.*}"  # 硬阻断所有${}使用

exceptions:

"表名变量"  # 如果确实需要动态表名，需人工审查

"列名变量"  # ORDER BY场景需配合白名单

JPA/Hibernate 项目：监控 createNativeQuery()

和 SQLAlchemy 类似，原生查询是主要的风险入口。

JDBC 项目：监控 Statement 的使用，要求使用 PreparedStatement

这是 Java 安全开发的基本要求，审查规则应该把 Statement.executeQuery(string) 标记为硬阻断，引导至 PreparedStatement。

6.3 不同业务场景下的规则取舍

实操中你会发现，不同业务场景对安全的要求不一样，规则也需要灵活调整：

金融/支付场景：零容忍策略

• 所有动态 SQL 硬阻断
• 即使 ORM 安全方法也必须经过二次确认
• 要求代码生成时附带安全注释，标注该查询的防护措施

内部管理系统：平衡策略

• 硬阻断覆盖数据库写操作（INSERT/UPDATE/DELETE）
• 读操作允许软警告，给开发者更多自主判断空间
• 数据导出类功能提升规则优先级

数据分析/报表场景：灵活策略

• 动态列名和表名在一定范围内允许
• 重点监控“用户可自定义 SQL 片段”的功能
• 建议规则中加入“数据脱敏检查”的维度

七、成本与效率：配置审查规则对编码速度的影响

7.1 我的实测数据

很多开发者犹豫要不要配审查规则，是担心“规则会拖慢编码速度”。我在自己的项目上做了为期四周的对比测试：

结论：生成阶段的微弱延迟是完全值得的。 那 0.6 秒的额外耗时，换来的是修复阶段的指数级时间节省。

7.2 规则性能优化的三点建议

如果你发现规则拖慢了生成速度，可以从三个方向优化：

1. 减少复杂 AST 遍历的规则数量：AST 解析是最耗时的操作。把不需要语义理解的简单模式用轻量级的正则匹配替代。
2. 给规则划定生效范围：不要全局生效，而是按模块、按文件类型指定生效范围。比如，只对包含 cursor.execute 或 session.query 的文件启用 SQL 注入规则。
3. 利用缓存机制：如果 Claude Code 支持规则缓存的配置，一定要启用。静态的规则库不需要每次生成都重新加载和解析。

八、总结与行动建议

回到文章开头那个凌晨两点的时刻。如果那个时候我已经配置了今天写的这些审查规则，Claude Code 就不会生成那段裸奔的 SQL 拼接代码。我会在生成的那一秒就收到一条拦截信息，AI 会自行修正为参数化查询，然后我继续推进下一个功能，而不是花一个小时做代码审查、写注释、修漏洞、补测试。

这就是审查规则的价值：它不是给开发流程加了一道门槛，而是把一道本来在高处的门槛移到了低处。

你现在应该做的五件事

1. 今天：检查你正在使用的 AI 编码工具是否有审查规则功能。Claude Code、Cursor、Copilot 都或多或少支持类似的规则机制。不管用哪个，先确保你开启了基础的安全规则。
2. 本周内：根据你的技术栈，创建第一版硬阻断规则。不用一步到位追求完美，先把最危险的模式堵住，禁止 WHERE 子句的字符串拼接，禁止 f-string 拼接 SQL。
3. 本月内：在真实项目中跑两周，收集误报和漏报数据。用这篇文章里的分类方法处理误报，逐渐把规则的精准度调到最佳状态。
4. 建立规则更新的例行机制。我建议每个季度的第一周，拿出两个小时回顾规则命中情况、新增的 SQL 注入手法、以及团队遇到的新场景。
5. 最容易被忽视的一点：把规则配置纳入新人的 onboarding 流程。让团队的每个开发者都理解“为什么 AI 需要安全规则”以及“如何在不影响效率的前提下保障安全”。

关于取舍的最后一段话：

安全总是在和效率做博弈。我不建议你把规则的严格度拉到最高，那会让 AI 变得寸步难行，生成的每一个字符都战战兢兢。好的审查规则应该像一道设计合理的高速公路护栏：平时你不觉得它的存在，当你偏离方向时，它会把你温柔但坚决地拉回来。

对 SQL 注入的防御，在 AI 辅助编程的时代，不是变得更难了，而是防护的位置变了。过去我们靠代码审查、SAST 扫描、渗透测试来发现问题；现在我们多了一件武器，在代码还没被写出来之前，就告诉 AI：“这一种写法，你不要用。”

这条规则配置，值得你现在就去做。