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

[mostkia]

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

[Greenm]

没搞懂 base64 怎么防注入的，我的理解是你传入后端的时候编码一下，你后端收到数据的时候再解码，然后拼接这个 SQL 语句进行查询，这样除了一些乱码外其他好像没啥作用啊，比如我写这样的语句，1' and 1=1，base64 编码解码后不还是一样的吗，怎么防止注入的？

噢应该可以防止宽字符注入，其他的好像不行。 要不就是我理解错你的意思了。

[CloudMx]

有毛用。

[misaka19000]

额，不管你怎么编码，最终在转为 SQL 的时候难道不都需要解码回原来的字符？

[est]

还不如 md5 一下。保证不可能出现引号。

[ThirdFlame]

编码 、解码 不还是原来的输入，所以没有任何防注入能力。

[pimin]

当然不可行

[mostkia]

@Greenm 前台拿到的数据是明文字符串，到后台存入数据库前，进行编码后再存入数据库。需要时再取出来，然后直接解码还原。

[ryweer]

--tamper base64encode.py 了解一下

[mostkia]

想不通为什么大家都理解为传输阶段进行编码呢。。我的意思其实是存入数据库前由后台进行编码，存入数据库的就是 base64 内容。

[misaka19000]

@mostkia #7 这是可以的，不过这种思路不是和关键词替换是一样的道理吗？前端中用的很多啊。。。

[funcman]

没用。
sql 注入利用的核心点在于字符串缺乏反映类型的手段。防注入要从类型校验一直做到逻辑校验才靠谱。
base64 只是种编码，没有任何加密。没有加密的传输很容易随意伪造。
公开的网络交互是很不安全的，所以既要让伪造难以做到，也要能够识破伪造。

[gamexg]

你如果对所有内容都 base64 后就应该不会有 sql 注入问题。
但是但是，这么搞搜索等功能全挂了。

防注入难道不是应该用参数化查询？

[mostkia]

@funcman =_=神奇。。好吧，看来我说的不清楚，大家都有些理解错误。我的意思在明确一下：字符串处理完全在后台存数据时进行，存入到数据库的就是 b64，SQL 增删改查的关键词都是预设的字符串，固定的，前台来的变量则通通都会被编码成 b64 再存储，网络传输阶段都是明文传输的，和传输阶段没有什么关系。

[passerbytiny]

@mostkia #7 你还是先说下你对 sql 注入的理解把，你现在这需求，跟 sql 注入扯不上一点关系，貌似跟 sql 都没关系。

[yagao0o]

有个问题，如果某个字段需要模糊查询怎么办……把也把查询条件 base64 之后查询吗……

[mostkia]

@gamexg 恩，你说的很对，我也考虑过。不过目前我数据库需求，都是完整精确匹配的，可以将输入内容也进行 b64 预处理后再搜索，类似于 MD5 的密码校验吧。复杂的多条件估计是不行的。所以也是处于考虑中是否要这样做。

[mostkia]

@yagao0o 是啊，我也这样考虑了，这个问题比较困难，虽然目前数据库虽然没有模糊匹配的需求，但以后就不确定了，所以也只是探讨一下是否可行。

[opengps]

其实全文替换就行了，把一个单引号全文替换为两个单引号（在 sql 两个单引号属于注释输入一个单引号）

[funcman]

@mostkia 我后来才看到你说的方式。怎么说呢，更不靠谱。防注入主要防止数据泄漏。数据泄漏之后，除非由强密码加密过，不然就漏光了啊。
一般来讲，为了逻辑操作，使用数据库尽量把序列化的数据拆开成字段。少数无需操作的是直接存序列化的数据。这些是教科书里都会提到各种数据库设计范式，学会拿来用即可。

[gam2046]

需要的参数化查询替代字符串拼接 SQL 语句。

只要不使用 SQL 语句的直接拼接，可杜绝绝大部分的注入。

[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]

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

[iyaozhen]

666
仔细一想，别说还真行。索引也有，like 查询其实也行
除了存储大小会变大点

[msg7086]

可以，但是意义不大。

[madNeal]

使用现有的 sql 参数化方法比自己想办法造轮子有效得多

[reself]

你怕是对 SQL 注入的理解有误。

[reself]

抱歉，貌似确实能起到类似转义的作用。

[whoami9894]

如果是数据库所有字段都是 b64 编码内容，那么是可以的
比如拼接 sql 查询时 select * from users where uname = '{param}'，b64 可以保证不会闭合掉前面的单引号，但这么麻烦为什么不直接参数化 sql 语句呢

[claysec]

楼主是想防止二次 SQL 注入吗。。

[yuikns]

其实是可以的。只要没有 like 查询。其实就是利用 b64 字符集没有比较危险的那几个特殊字符。怎么这么多人死活不理解别人的中文呢

但是，现在一个 prepared statement 能解决的问题没必要那么复杂

[glishijie]

@mostkia 可以的

[just1]

是可以的，楼上很多人怕是对注入有误解

[all4fun]

直接参数化比较好吧

[q397064399]

一般 orm 都做掉了，自己弄这个 真的是蛋疼

[jalja27]

以我的经验来看，sql 注入的问题有直接的解决方案，就用这个方案。用编码这种间接的，中间多了一层数据转换逻辑，扩展性和其它关联影响是很大的隐患，特别是多人开发的团队中

[reus]

我看你是不知道 SQL 可以传参数吧。

[paranoiagu]

数据库存了 base64 后的数据，你查询 like 怎么搞？
查出来的数据都要解码显示，性能行不行？

[lzxz1234]

内容编码入库是常用的，但依赖这种方式防注入也太低级了

[huahuajun9527]

你的意思是查询字符串只允许是 base64 的字符集里的，包含其他的字符就不放进去查询？？？

[master13]

其实在做软件工程的时候，我们经常会遇到一个问题就是：业内通常怎么做。你说的方法也可以，但是不利于后期业务数据分析处理。方法可行，但业内不这么做，肯定是有它的道理。

[firechat]

给我的感觉就是放着圆的轮子不用，要造一个方的轮子。
直接用现有的 sql 防注入方案就行了

[xmdbb]

可以肯定可以，但是我只想问问，ID 系列的你怎么处理，难不成整个自增 ID 你都用 BASE64 吧？

[xmdbb]

还有就是不清楚你业务是怎样，如果涉及计算的，涉及日期对比的，你 BS64 后就只能通过取出来后在计算？
另外如果计算后还要连表查询，那不就变了要跑很多次吗？这样做不就弊大于利了。
其实 PDO 没啥不好吧？如果说不习惯，那就自己封装下成习惯的就可以了。你这简直是杀鸡取卵啊.....

[qiyuey]

参数化查询，不要去拼接 SQL

[darktutu]

我挺心疼楼主的，这下面回复有多少人是题目都没看明白的。这都什么人混迹于此啊？

[AlphaTr]

可以是可以，但将 base64encode 换为 escape 工作量是一样的，效果却更好；

[rizon]

参数占位符，sql 预编译就可以解决，注入只发生在 sql 编译时。

[CRVV]

@Greenm
把单引号替换成两个单引号确实不是好方案，但是楼主说了用的是 SQLite，这个做法是对的
SQLite 和 PostgreSQL 里，字符串里只有单引号是特殊字符，反斜杠只是反斜杠

[beginor]

进行参数化查询就那么难么？

[missdeer]

数据库存 base64 后的文本，之后搜索会麻烦一点吧

[a194259440]

@darktutu 所以你拿个方案啊，站着说话不腰疼么

[unco020511]

可以肯定可以啊，但是后期很多统计搜索之类的就功能就不好处理了吧

[evilmiracle]

预编译啊

[darktutu]

@a194259440 你腰已经断了

[mostkia]

已重写控制程序，目前使用 pdo 预处理解决注入问题，今天一点开就 40 多条回复，没想到那么讨论激烈。其实这个被疯狂吐槽的需求锅不应该由我来背。。。因为之前的数据库控制程序并不是我写的，项目做到一半由我接手的，现在想想的确挺蛋疼的，之前的控制程序直接是标准的 sqlite 接口，当然也有一些基本的字符串过滤，但感觉不太好，但也因为怕出 BUG 实在不想改数据库控制程序这部分，所以才想了一些投机取巧的方法。后来一想长痛不如短痛，索性都重写了，好在业务逻辑也不复杂，已经全部搞定了，感谢大家的意见。

[iwtbauh]

@Greenm #1
@CloudMx #2
@misaka19000 #3
@pimin #6

我以 mysql/mariadb 举例

mysql/mariadb 提供了一个叫 FROM_BASE64 的函数

我在拼接 SQL 的时候，后端把用户的输入都 base64 一下，然后套到这个函数里去，就成了这样

var = base64(${var})
..... WHERE `id` = FROM_BASE64(${var}) …

所有用户的输入都不可能破坏 sql 语句，并且，存到数据库里 /查询数据库的时候，还是原来的用户输入。

这是我以前用 bash 写个家庭内网自用程序的后端时，因为 bash 没法参数化查询，所做的防注入措施。

可见，base64 防注入十分可行

[misaka19000]

@iwtbauh #72 没说不可行啊，只是这个方法太民科了，缺点也很明显

[iwtbauh]

@misaka19000 #75

除了有点 dirty 之外。有什么明显缺点吗。

[mostkia]

@iwtbauh 74#受教了，以后有需要的情况下也有可行对策了，虽然有轮子用自然最好了的，pdo 也挺方便的。但多一个办法多一条路总归也是好的。