比如只允许英文中文数字和少量符号,其他所有符号都替换成[code_xxx]。这种不管怎么拼接 SQL 语句都没法注入了吧。
1
oott123 2021-03-21 11:19:14 +08:00 via Android 2
注入往往发生在你意料不到的地方,所以正确的做法永远是 prepare 再传参数
举个例子:宽字节注入 |
2
singerll 2021-03-21 11:36:42 +08:00 via Android
sql 注入不一定发生在用户输入,任何会连接数据库查数的地方,都可能发生注入。
|
3
zhuawadao 2021-03-21 12:07:34 +08:00
曾记得有个网址,输入账户密码,密码输入 1=1 就能验证通过
|
4
340244120w 2021-03-21 13:31:06 +08:00 via iPhone
直接说结论,当然可以。
而且 order by 也都是用白名单,想用 prepare 也用不了啊 |
5
FucUrFrd 2021-03-21 15:49:33 +08:00 via Android
Prepare, 什么鬼问题,SQL 注入在 Facebook Google Amazon 早就被解决了
|
6
weirdo 2021-03-21 16:00:51 +08:00
用 prepare 不就好了么,只要用字符串拼接 sql,那就有被注入的风险
|
7
des 2021-03-21 16:03:47 +08:00
尽量不要弄这种,老老实实用 prepare 。
另外讲个笑话,icloud 不允许有人叫“true” |
8
zhuweiyou 2021-03-21 18:09:01 +08:00
你这做法不对, 直接 prepare 就行了, 不需要去手动过滤
|
11
abcbuzhiming 2021-03-21 19:09:42 +08:00
你要是能保证过滤百分之百那当然没有注入,问题就在于你保证不了的,楼上已经有人说了,注入都来自意外的地方
|
12
clf 2021-03-21 19:24:48 +08:00
不用 SQL 就没有 SQL 注入了 /doge
prepare 是最好的做法,绑定变量使用预编译语句是预防 SQL 注入的最佳方式。 |
13
BeautifulSoap 2021-03-21 19:32:28 +08:00
|
14
cest 2021-03-21 19:39:28 +08:00
prepare 防 SQL 注入
非常严的白名单防 unicode 控制字符对你的肉眼注入 |
15
CRVV 2021-03-21 22:41:52 +08:00 2
如果你用的是符合 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 语句都没法注入了” 如果没有这个自信,就别这么玩了。 |
16
xieqiqiang00 OP @oott123 搞白名单的话,这类字符直接会被抛弃吧
|
17
DanielYao 2021-03-22 10:42:17 +08:00
参数化 sql,一般都能防住
|
18
Chenamy2017 2021-03-22 13:04:23 +08:00
@zhuawadao 赶紧去检查了我们的产品,果然通过登陆界面可以注入 SQL !
|
19
ERRASYNCTYPE 2021-03-22 17:46:47 +08:00
你这人肉穷举
|
20
zhuawadao 2021-03-22 18:42:21 +08:00
@Chenamy2017 上报公司拿奖金
|
21
meepo3927 2021-03-23 08:45:37 +08:00
可以防注入了, 但是这样更麻烦了吧
|