Python防SQL注入：参数化查询详解

本文深入剖析了Python项目中防范SQL注入的核心原则与实践细节，强调必须严格依赖数据库驱动原生支持的参数化查询机制（如sqlite3用?、psycopg2用%s），彻底摒弃任何形式的字符串拼接（包括str.format()和%格式化），因为后者在Python层完成、数据库无法区分代码与数据，极易被' OR 1=1 --等恶意payload攻破；同时指出字段名、表名、ORDER BY和LIMIT等结构化元素无法参数化，必须通过白名单校验或专用安全构造函数（如psycopg2.sql）处理，辅以严格的类型转换与范围检查，从而构建真正健壮、不可绕过的SQL安全防线。

SQL注入风险不能靠“注意拼接”来规避，必须用数据库驱动原生支持的参数化查询机制，否则任何字符串处理逻辑都可能被绕过。

为什么 str.format() 或 % 拼接永远不安全

这类操作发生在 Python 层，数据库驱动完全无法识别哪些是值、哪些是 SQL 结构。攻击者只要在用户输入中插入 ' OR 1=1 -- 这类 payload，就能让拼接后的语句变成完整可执行的恶意 SQL。

• 即使对单引号做 .replace("'", "''")，也防不住基于布尔盲注或时间盲注的绕过
• sqlite3 的 execute("SELECT * FROM users WHERE name = '" + name + "'") 是典型高危写法
• ORM 如 SQLAlchemy 如果用了 text() + 字符串插值，同样失效

sqlite3 和 psycopg2 的参数占位符语法差异

不同驱动对参数化查询的占位符要求严格，混用会导致 ProgrammingError 或静默失败（如把参数当字面量）。

• sqlite3 只认 ?（问号）位置占位：cursor.execute("SELECT * FROM t WHERE id = ?", (user_id,))
• psycopg2 只认 %s（注意不是 Python 的字符串格式化）：cursor.execute("SELECT * FROM t WHERE id = %s", (user_id,))
• 绝不能在 psycopg2 中写 %d 或 {id}，会触发类型错误或 SQL 解析失败

哪些场景容易漏掉参数化，尤其在动态条件构造时

WHERE 子句字段名、表名、ORDER BY 字段、LIMIT 数值——这些都不能用参数化，但开发者常误以为能塞进 %s 里。

• 字段名/表名必须白名单校验后硬编码，或用 sql.SQL() + sql.Identifier()（psycopg2.sql）
• LIMIT 后的数字需转为 int 后直接拼入 SQL（因驱动不支持该位置参数化），但必须先做范围检查：if not (0
• 多个可选 WHERE 条件建议用列表累积参数，避免空条件导致 SQL 语法错误：where_parts = []; params = []，再 " AND ".join(where_parts)

真正难的不是写对一个 execute()，而是让整个项目里所有数据库交互路径都走同一套受控的参数化封装——比如统一用 DAO 类方法接收 dict 参数，内部校验键名、构建 WHERE 子句、调用带 ? 或 %s 的 execute。漏掉任意一个分支，风险就还在。

终于介绍完啦！小伙伴们，这篇关于《Python防SQL注入：参数化查询详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！