如果对于用户输入的内容做白名单过滤，不允许符号，是不是就没有 SQL 注入的可能性了？

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

This topic created in 1900 days ago, the information mentioned may be changed or developed.

比如只允许英文中文数字和少量符号，其他所有符号都替换成[code_xxx]。这种不管怎么拼接 SQL 语句都没法注入了吧。

SQL

符号

注入

code_xxx

21 replies • 2021-03-23 08:45:37 +08:00

oott123

Mar 21, 2021 via Android

注入往往发生在你意料不到的地方，所以正确的做法永远是 prepare 再传参数

举个例子：宽字节注入

singerll

Mar 21, 2021 via Android

sql 注入不一定发生在用户输入，任何会连接数据库查数的地方，都可能发生注入。

zhuawadao

Mar 21, 2021

曾记得有个网址，输入账户密码，密码输入 1=1 就能验证通过

340244120w

Mar 21, 2021 via iPhone

直接说结论，当然可以。
而且 order by 也都是用白名单，想用 prepare 也用不了啊

FucUrFrd

Mar 21, 2021 via Android

Prepare, 什么鬼问题，SQL 注入在 Facebook Google Amazon 早就被解决了

weirdo

Mar 21, 2021

用 prepare 不就好了么，只要用字符串拼接 sql，那就有被注入的风险

des

Mar 21, 2021

尽量不要弄这种，老老实实用 prepare 。
另外讲个笑话，icloud 不允许有人叫“true”

zhuweiyou

Mar 21, 2021

你这做法不对, 直接 prepare 就行了, 不需要去手动过滤

FucUrFrd

Mar 21, 2021 via Android

@des 90 年代的代码，没人记得去改

des

Mar 21, 2021

@FucUrFrd 那祝你好运

abcbuzhiming

Mar 21, 2021

你要是能保证过滤百分之百那当然没有注入，问题就在于你保证不了的，楼上已经有人说了，注入都来自意外的地方

clf

Mar 21, 2021

不用 SQL 就没有 SQL 注入了 /doge

prepare 是最好的做法，绑定变量使用预编译语句是预防 SQL 注入的最佳方式。

BeautifulSoap

Mar 21, 2021

https://www.v2ex.com/t/761752

我前几天的帖子正好应景

不用 prepare statement 的话，在你想象不到的地方永远都会存在 sql 注入

cest

Mar 21, 2021

prepare 防 SQL 注入
非常严的白名单防 unicode 控制字符对你的肉眼注入

CRVV

Mar 21, 2021

如果你用的是符合 SQL 标准的数据库，比如 PostgreSQL，只要字符串里没有单引号，就不会有 SQL 注入。

如果你要用 MySQL，那请认真阅读 https://dev.mysql.com/doc/refman/8.0/en/string-literals.html
注意 MySQL 的文档里面还有一句是
In certain client environments, it may also be necessary to escape NUL or Control+Z.
escape 的结果还取决于 client environment 的。

如果有自信把这些奇怪的 escape 规则都搞对，那当然就可以 “不管怎么拼接 SQL 语句都没法注入了”
如果没有这个自信，就别这么玩了。