PythonFlask防SQL注入：参数化与ORM防护指南

本文深入剖析了Flask应用中SQL注入风险的本质成因与系统性防护方案，明确指出字符串拼接（如f-string、+连接、format()）执行SQL是高危操作，根本原因在于攻击者可借此篡改SQL语法结构，而参数化查询通过数据库驱动层严格分离语句与数据，从执行机制上杜绝注入；文章详述sqlite3、psycopg2、MySQL驱动在占位符使用上的关键差异与陷阱，强调表名、排序字段等动态部分必须依赖白名单校验而非转义，同时厘清SQLAlchemy ORM中filter()的安全边界与text()的危险用法，指出模糊搜索应统一使用like()方法、动态SQL必须配合bindparam()注入，并警示Flask-SQLAlchemy中db.session.execute()若出现任何字符串拼接即意味着漏洞裸奔——安全不是加一层过滤，而是重构整个查询逻辑，将参数化思维贯穿于每一行数据库交互代码。

Flask中用sqlite3或psycopg2执行SQL时，为什么拼接字符串必出问题

直接用f"SELECT * FROM users WHERE id = {user_id}"或"SELECT * FROM users WHERE name = '" + name + "'"，等于把数据库的钥匙塞给前端。哪怕user_id看着是数字，攻击者也能传1 OR 1=1 --进来，绕过条件、拖库、删表。

根本原因不是“没过滤”，而是SQL解析器会把拼进去的字符串当语句一部分执行——参数化查询强制让数据和语句分离，数据库只把占位符当值处理，不重新编译语法。

• sqlite3必须用?或:name占位，不能用%s（那是Python字符串格式化，早于SQL解析）
• psycopg2支持%s和%(key)s，但%s不是字符串插值，是驱动层转义后送进PostgreSQL的二进制协议参数
• 连ORDER BY或table_name这种无法参数化的字段，得白名单校验，不能靠escape_string()糊弄

SQLAlchemy ORM里filter()和text()的安全边界在哪

filter(User.name == name)是安全的，ORM自动转成参数化查询；但一旦写filter(text("name = '{}'".format(name)))，就退化回拼接陷阱。

常见误操作：用text()动态拼接排序字段、模糊搜索关键词、或带函数的条件（比如LOWER(name) = LOWER('{name}')）。这些看似灵活，实则绕过了ORM的防护层。

• 模糊搜索统一走like()方法：User.name.like(f"%{keyword}%")，它生成的是WHERE name LIKE ? + 参数
• 需要text()时，只用于固定结构SQL（如窗口函数），且所有变量必须用bindparam()注入，例如text("SELECT * FROM users ORDER BY :sort_field").bindparams(sort_field=bindparam("sort_field"))
• execute()原生查询必须配session.execute(text(sql), {"param": value})，不能裸调session.execute(sql.format(...))

Flask-SQLAlchemy里db.session.execute()的两种写法风险差异

新手常以为用了Flask-SQLAlchemy就万事大吉，结果在db.session.execute("UPDATE users SET status = 'active' WHERE id = {}".format(user_id))里翻车——这行代码完全没走ORM参数机制，纯字符串拼接。

真正安全的写法只有两种：一是用ORM对象操作（user.status = "active"; db.session.commit()），二是用带参数的text()。

• 安全写法1：db.session.execute(text("UPDATE users SET status = :status WHERE id = :id"), {"status": "active", "id": user_id})
• 安全写法2：db.session.query(User).filter(User.id == user_id).update({"status": "active"})
• 危险信号：execute()里出现.format()、%、f-string、+拼接，基本可以判定有漏洞

为什么用mysql-connector-python时%s写法反而可能出错

MySQL官方驱动对参数占位符极其严格：%s只能用于值，不能用于表名、列名、LIMIT偏移量。有人试过"SELECT * FROM %s LIMIT %s"，第二个%s能参数化，第一个会直接报ProgrammingError: Wrong number of arguments。

更隐蔽的问题是，某些旧版驱动把%开头的字符串（如"%admin%"）误判为格式化指令，导致execute("SELECT * FROM users WHERE name LIKE %s", ["%admin%"])实际发出去的是LIKE '%admin%'还是LIKE '%%admin%%'，取决于驱动版本。

• 解决方案：表/列名用白名单映射，比如{"users": "users", "orders": "orders"}.get(table_arg, "users")
• LIMIT参数必须转成int再拼，但仅限于你完全控制输入来源（如分页页码从request.args.get("page", 1, type=int)来）
• 模糊匹配统一用CONCAT('%', %s, '%')替代手动加%，让数据库处理通配符

参数化不是贴膏药，是重构查询逻辑的前提。漏掉一个format()，整个API就等于裸奔。别信“我这个字段只管理员能改”——权限控制和SQL安全是两层事，谁也替不了谁。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。