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 语句的直接拼接，可杜绝绝大部分的注入。