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

• 資深大佬 : oott123

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

  举个例子：宽字节注入

• 資深大佬 : singerll

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

• 資深大佬 : zhuawadao

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

• 資深大佬 : 340244120w

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

• 資深大佬 : FucUrFrd

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

• 資深大佬 : weirdo

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

• 資深大佬 : des

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

• 資深大佬 : zhuweiyou

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

• 資深大佬 : FucUrFrd

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

• 資深大佬 : des

  @FucUrFrd 那祝你好运

• 資深大佬 : abcbuzhiming

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

• 資深大佬 : lychs1998

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

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

• 資深大佬 : BeautifulSoap

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

  我前几天的帖子正好应景

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

• 資深大佬 : cest

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

• 資深大佬 : CRVV

  如果你用的是符合 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 语句都没法注入了”
  如果没有这个自信，就别这么玩了。

• 主 資深大佬 : xieqiqiang00

  @oott123 搞白名单的话，这类字符直接会被抛弃吧

• 資深大佬 : DanielYao

  参数化 sql,一般都能防住

• 資深大佬 : Chenamy2017

  @zhuawadao 赶紧去检查了我们的产品，果然通过登陆界面可以注入 SQL ！

• 資深大佬 : ERRASYNCTYPE

  你这人肉穷举

• 資深大佬 : zhuawadao

  @Chenamy2017 上报公司拿奖金

• 資深大佬 : meepo3927

  可以防注入了， 但是这样更麻烦了吧