发现Codex生成的代码里藏了高危SQL漏洞，别慌——但也不能慢。第一件事：立刻定位漏洞类型、确认触发路径、把不安全写法替换掉，最后验证修复是否真的生效。为什么这么赶？因为这类代码一旦上线，攻击者可以直接利用，连门槛都省了。

在Codex生成的代码审计中发现高危漏洞时，必须立即定位漏洞类型、确认触发路径、替换不安全模式并验证修复效果，否则该代码一旦上线就可能被直接利用。

识别Codex输出的三类高危SQL模式

打开Codex生成的源文件，逐行扫描数据库操作逻辑，重点排查以下写法：

方法一：含 f"SELECT * FROM users WHERE name = '{username}'" 或 "WHERE id = " + user_id 这类字符串拼接语句——【只要出现单引号包裹+变量名，立刻标记为高危】；

方法二：SQL语句中调用 request.args.get、input()、get_parameter() 等用户输入源，且未经过 setString()、execute(query, params) 等参数绑定调用；

方法三：函数名含 get_user、login_check、search_data 等业务关键词，但函数体内没有 ?、%s、:name 等占位符——这种“看起来能跑通”的代码最危险。

Ja va项目：用PreparedStatement替换拼接SQL

第一步：把原始SQL中的变量部分全部替换成?占位符，例如将 "SELECT * FROM users WHERE username = '" + username + "'" 改为 "SELECT * FROM users WHERE username = ?"；

第二步：获取PreparedStatement对象，不要用Connection.createStatement()；

第三步：对每个?按顺序调用setString()、setInt()等方法传入对应变量，如ps.setString(1, username)；

第四步：执行ps.executeQuery()或ps.executeUpdate()，绝不可再调用execute(sql)。这一步若仍用字符串执行，前面所有修改全部失效。

Python项目：强制启用参数化execute

找到使用 cursor.execute("SELECT * FROM table WHERE id = " + str(user_id)) 的代码行；

将拼接式调用改为带参数元组的execute，例如 cursor.execute("SELECT * FROM users WHERE username = %s", (username,))；

注意：MySQL驱动用 %s，PostgreSQL驱动用 %s 或 %(name)s，SQLite用 ?——【不同DB驱动占位符不互通，换库时必须同步改占位符】；

删除所有含 .format()、f-string、+ 拼接SQL的语句，一个都不能留。

Node.js项目：统一采用问号或命名参数

方法一（问号占位）：把 `SELECT * FROM users WHERE name = '${name}'` 替换为 `SELECT * FROM users WHERE name = ?`，然后执行 db.query(sql, [name])；

方法二（命名参数）：改用 SELECT * FROM users WHERE name = $1 → db.query(sql, [name])，或 SELECT * FROM users WHERE name = :name → db.query(sql, { name })；

检查所有调用链，确保从HTTP路由参数→业务函数→数据库查询全程未发生字符串拼接——【中间任意一层拼接都会导致前序参数化失效】。

补漏：增加输入校验作为兜底防线

第一步：对username、id、email等关键字段添加白名单校验，例如用正则 ^[a-zA-Z0-9_]{3,20}$ 限制用户名；

第二步：在DAO层入口处拦截含 ' OR 1=1、UNION SELECT、../ 的输入，直接返回400；

第三步：日志中记录所有被拦截的异常输入，用于反推攻击意图和更新规则。