防止SQL注入的核心技术_使用查询参数化处理变量

拼接SQL字符串必然导致SQL注入风险，因数据库无法区分代码与数据；必须使用参数化查询（如?占位符）并严格避免字符串拼接，字段名等结构元素需白名单校验。为什么拼接 SQL 字符串一定会出事因为数据库不会区分“代码”和“数据”——你用 + 或 f-string 把用户输入塞进 SQL 里，等于亲手把刀递过去。' OR '1'='1 这种输入能直接绕过登录验证，不是理论风险，是每天都在发生的事实。常见错误现象：sqlite3.OperationalError: near "admin": syntax error（其实是注入失败的副产品）；更危险的是悄无声息地删库、拖走用户表。关键判断：只要 SQL 字符串里出现 user_input、request.args.get('id')、name 这类变量名，且没经过参数化处理，就已处于高危状态。Python 中用 execute() 传参才是正路所有主流 DB API（sqlite3、psycopg2、pymysql）都支持占位符传参，这是唯一被设计用来隔离数据与语句的机制。实操建议：用 ? 占位符（SQLite）或 %s（MySQL/PostgreSQL），绝不用 f"SELECT * FROM users WHERE name = '{name}'"参数必须以元组或字典形式传给 execute() 第二个参数，不能 unpack 成位置参数字段名、表名、排序方向（ASC/DESC）不能参数化——它们属于 SQL 结构，需白名单校验或硬编码示例（安全）：cursor.execute("SELECT * FROM users WHERE age > ? AND status = ?", (18, 'active'))ORM 框架里别手痒写原生 SQLDjango 的 filter()、SQLAlchemy 的 query.filter() 默认就是参数化的。但一旦你调用 extra()、text() 或 raw()，就立刻退出安全区。 知网AI智能写作 知网AI智能写作，写文档、写报告如此简单