AI 写的登录接口能跑，上线前我却查出 SQL 注入写法

功能测试通过不等于能上线。这篇不聊"AI 该不该写代码"，只拆一个可复现场景：AI 写出来的登录接口看着能登录，我上线前是怎么查出 SQL 拼接写法、怎么人工确认，以及改成什么才敢继续走发布流程。

先看这段代码：能跑，但我不会直接上线

下面这段来自本地演示项目，功能等价于一个登录接口，不是真实线上代码，也不是客户项目：

python 复制代码

username = request.form.get("username", "")
password = request.form.get("password", "")

sql = f"SELECT id FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(sql)
row = cursor.fetchone()

if row:
    return {"ok": True}
return {"ok": False}, 401

只看功能，它确实能登录：传正确的用户名和密码，能查到用户，返回成功。

但如果它就这样上线，我心里真正的问题不是"今天能不能登录"，而是：

username 和 password 来自 HTTP 请求，却直接被拼进了 SQL 字符串。

我上线前先跑了一轮扫描

我没有逐行翻代码，先让扫描器把可疑位置筛出来：

bash 复制代码

code-audit app --format html --output report.html

其中一条结果：

级别	规则	风险原因	位置
High	`sql-concat`	SQL 由字符串拼接生成，用户输入可能进入 SQL	`app/login.py:12`

看到 High，我不会立刻无脑改，也不会直接说"这是误报"。

我会按下面 4 步人工确认一遍。

第一步：先问输入从哪里来

username 和 password 来自 request.form。

这代表它们不是代码里写死的测试值，而是客户端可以任意提交的内容。

如果输入来自配置文件或固定环境变量，风险等级会不一样；但来自 HTTP 请求，就要默认不可信。

第二步：再追它去了哪里

变量没有经过长度限制、类型校验、转义或参数化处理，直接进入了字符串模板：

python 复制代码

sql = f"SELECT id FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(sql)

输入来源是"请求参数"，落点是"SQL 执行"，中间没有任何边界。

这一步确认完，我可以判定：这不是纯粹的写法风格问题，而是一条从用户输入到数据库执行的可达路径。

第三步：判断它能不能被利用

我不用真的攻击自己项目，只要按 SQL 语法推演。

如果用户把 username 提交成：

text 复制代码

' OR '1'='1

拼出来的 SQL 会变成：

sql 复制代码

SELECT id FROM users WHERE username = '' OR '1'='1' AND password = '{password}'

1=1 恒真，条件可能绕过正常校验。

更准确地说：我不能证明"一定有人能绕过"，但我能确认"这里存在一条不依赖复杂攻击技巧的可疑路径"。对登录接口来说，上线前处理它的成本远低于上线后排查的成本。

第四步：改成参数化查询

修复不是"过滤单引号"，而是让用户输入不再进入 SQL 字符串：

python 复制代码

cursor.execute(
    "SELECT id, password_hash FROM users WHERE username = %s",
    (username,),
)
row = cursor.fetchone()

if row and verify_password(password, row["password_hash"]):
    return {"ok": True}
return {"ok": False}, 401

这里我顺手做了两件事：

SQL 只把 username 作为参数传入，不再拼接；
登录校验改为先按用户名取哈希，再单独验证密码，避免把明文密码写进 SQL。

改完后再跑一次扫描，原来的 sql-concat High 不再出现。

我不会把"扫描没了"当成"绝对安全"

扫描结果干净，只说明这轮检查里没再发现这条规则对应的写法。

它不等于：

项目没有其他漏洞；
登录逻辑已经达到生产安全标准；
不需要限流、防爆破、日志审计和权限检查。

所以"上线前检查"对我来说不是一个结论，而是一段流程：先筛可疑位置，再人工确认，能修的修掉，不能确认的单独列出来。

如果你也卡在类似代码上

如果你最近也在处理 AI 生成代码、外包接手代码或客户交付代码，并且已经发现"功能能跑，但心里没底"，可以在评论区或私信按这 5 项告诉我：

语言和框架；
代码来源：自己写、AI 生成、外包接手，还是客户代码；
大概代码量和准备上线/交付的范围；
你手头已有的扫描结果或具体报错；
你需要的结论类型：先确认哪里最危险、给出修复建议，还是要一份能交付的确认记录。

不要在公开评论区贴完整代码、密钥或客户项目，只发脱敏片段和扫描结果即可。

我先帮你判断这个问题适合自己按流程查、请人做人工确认，还是需要更专业的审计路径。