sql 防止注入，用 base64 对用户输入内容进行预处理，是否可行？

[mostkia]

如题，相对于 PDO 来讲，肯定是 PDO 更好，但按照题目里的说法，是否可行呢？（我使用的是 SQLite ）

[Greenm]

@mostkia #7 如果是这样的话，在将这些字符还原的场景下，会带来一些意想不到安全隐患，考虑如下情况：

比如，你有一些数据需要展示出来，如用户名，地址等消息，我注册的时候随便填的数据，比如 <script>alert(1)</script>，你 base64 放到数据库了，展示的时候解码展示，就会造成 XSS。

为了避免上述问题，你还是需要对用户输入的数据进行过滤和限制，这就让你的 Base64 编码失去了最初的意义。 另外，由于你对入库的数据做了编码转换，这会导致一些数据不直观，数据还需要多做处理，浪费性能。

所以为了达到安全的最佳实践，建议不要自己想出一些方法，这会引起其他意想不到的问题。

总的的说，如果某方法简单有效，那么肯定有人已经想到且运用上了。

[passerbytiny]

@mostkia #10 所有值都 b64 转码存储，所有输入的参数值都 b64 转码后再往 sql 上拼，你是这意思吗？
方案倒是可行，但是弊远大于利，随便一项都有一大堆弊端，譬如已经有人提到的模糊查询，譬如该字段是铁定无法用索引优化了，譬如专业的 dba 看不懂你的数据库了

[898601566]

我看到有说用 addslashes 的

[Greenm]

#18 @opengps 这样是完全错误的做法，全局替换非常容易造成一些安全问题，如果我这样写的话 \' 会变成 \''，会将第一个单引号转义，第二个单引号就逃逸出来了，造成 SQL 语句闭合引起注入。

很多问题都是因为一些程序员所谓的“小聪明”导致的，好的坏的程序员都犯过这种错误。 请严格遵守最佳实践。

[mostkia]

@opengps 好的，谢谢，我认真考虑你说的方案的。

[shuax]

不是 escape 一下就行吗？

[Vegetable]

我也不明白,怎么都看不明白呢?
人家说存数据库之前先编码,这样无论什么样的 SQL 语句都一起编码了,当然没了注入的问题

但是这么解决路子太野了吧?不推荐..

[bunnyblueair]

@est 难道对 md5 有什么误解

[mostkia]

@Vegetable 没有复杂查询条件我觉得是可以的，但碰到如果有模糊查询就不行了。我目前需求只是偶尔有一些精确匹配搜索，所以问问可行性，没想到那么多人理解错了，哈哈，没关系。实在不行就老老实实的直接做标准过滤吧，反正也就是处理一些用户名、密码、数量、型号、日期什么的，按照它们的类别做好过滤即可，一般也用不上这些特殊字符，保留英文数字，正则判断禁止所有的特殊字符就可以了。

[opengps]

@Greenm 真正进入数据库的，\'' 还是 写入原始的 \' ,多增加一个'就是为了让编译器放行写入单引号文本

[est]

@bunnyblueair 没误解。db 那边再查一下彩虹表就翻译过来原始值了。

[wellR]

类似 一表用户表，密码保存的是加密后的值，用户设置的原密码，我们不记录

[daozhihun]

可行，但是建议用参数

[murmur]

@gamexg base64 一样可以索引的 就是 like 会挂 而且也未必挂 毕竟是连续编码

[akira]

可以。 顺便在写个中间件自动编解码，嗯。。

[leo108]

@est 你可能对彩虹表有什么误解

[lihongjie0209]

@mostkia 存 base64 怎么查询

[hxt]

防注入不行，不可能所有字段都 base64。不过对长内容可以压缩再 base64 下，比如 php 的 gzcompress 后再 base64 下，存储的长度一般会比原来小。

[caola]

PDO 的预处理，已经是在帮你防注入了，也没太必要还做其他的专门处理

[yidinghe]

歪门邪道。不同的语言有不同的处理方法。