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

SQL注入发生在将用户输入拼接到SQL语句中的任何位置尤其是用format()、%或拼接时必须使用参数化查询并对表名、字段名等结构化部分做白名单校验。SQL注入到底在哪儿发生不是所有拼接字符串的地方都危险但所有用 format()、% 或 拼接用户输入进 SQL 语句的位置都是高危点。比如 SELECT * FROM users WHERE name {}.format(request.args.get(name)) —— 这种写法只要用户传入 OR 11就直接绕过验证。本质问题不是“用了原生 SQL”而是“把不可信数据当代码执行”。ORM 也不是银弹手写 filter(name {}.format(...)) 同样会中招。原生 SQL 必须用 execute() 的参数化接口Python DB-API如 sqlite3、psycopg2、pymysql都支持占位符但语法不统一混用就会出错sqlite3 只认 ? 或 :name不支持 %spsycopg2 只认 %s且必须用元组或字典传参不能用列表pymysql 支持 %s但不支持命名参数 %(...)s除非开启 namedTrue错误示例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数据分析工具可以快速分析和可视化复杂数据。