Python Web开发如何防范SQL注入_使用参数化查询与ORM实践

SQL注入发生在将用户输入拼接到SQL语句中的任何位置，尤其是用format()、%或+拼接时；必须使用参数化查询，并对表名、字段名等结构化部分做白名单校验。SQL注入到底在哪儿发生不是所有拼接字符串的地方都危险，但所有用 format()、% 或 + 拼接用户输入进 SQL 语句的位置，都是高危点。比如 SELECT * FROM users WHERE name = '{}'".format(request.args.get('name')) ------ 这种写法只要用户传入 ' OR '1'='1，就直接绕过验证。本质问题不是"用了原生 SQL"，而是"把不可信数据当代码执行"。ORM 也不是银弹：手写 filter("name = '{}'".format(...)) 同样会中招。原生 SQL 必须用 execute() 的参数化接口Python DB-API（如 sqlite3、psycopg2、pymysql）都支持占位符，但语法不统一，混用就会出错：sqlite3 只认 ? 或 :name，不支持 %spsycopg2 只认 %s，且必须用元组或字典传参，不能用列表pymysql 支持 %s，但不支持命名参数 %(...)s（除非开启 named=True）错误示例：cursor.execute("SELECT * FROM user WHERE id = %s", user_id) ------ 在 psycopg2 中会报 TypeError: not all arguments converted，因为期望元组，给了列表。立即学习"Python免费学习笔记（深入）"；正确写法（以 psycopg2 为例）：cursor.execute("SELECT * FROM user WHERE id = %s", (user_id,))Django ORM 不等于自动免疫Django 查询集默认安全，但三个地方容易翻车：extra() 和 raw()：直接执行原始 SQL，参数必须手动用 params=... 传入，不能拼接filter(**{field_name: value})：如果 field_name 来自用户输入（比如搜索字段名），会触发动态字段注入Q 对象组合时用了 eval() 或字符串格式化构造表达式典型错误：User.objects.filter(**{request.GET.get('sort_by', 'id'): 'asc'}) ------ 用户传 sort_by=dict 就能读取内部对象结构。 Julius AI Julius AI是一款功能强大的AI数据分析工具，可以快速分析和可视化复杂数据。