数据库SQL语句的安全方案

1.必须禁用字符串操作的方式来组合执行SQL语句。而使用预编译语句 Prepared statements 来生成 并执行SQL 的请求。

2.服务端代码中使用字符串拼接的方式来生成SQL语句进行UPDATE，INSERT是很常见的。
我们通常会用 escape_string 的方式来进行转义来防止SQL注入。

这种操作方式进行操作数据库存在的风险非常高。除了SQL注入漏洞的风险之外。在实际项目中它还会出现一些更难以预防的风险，内存错误等问题。

根据谷歌官方曾经披露的数据，繁忙的业务集群中，每8GB内存每小时的错误率高达5个bit。当然服务器必须使用ECC内存。但虽然ECC内存中每 64bit 的 word 中发生1 bit 错误时可以被控制器修正。
但如果发生2个bit的错误时，就无法被修正了。那么计算一下，ECC内存发生无法修复的内存错误的概率是：每8GB每小时 1/2.2737368e-11。看上去好像很低。但是如果是一组200台x每台512G内存的服务器集群，一年内发生无法修正的内存错误的概率可以高达达到千分之2.5。

比如一段SQL代码本来是 UPDATE data=‘xxxx’, b=10003 WHERE n=8888 。因为错了一个bit, 3变成#。语句变成 UPDATE data=‘xxxx’, b=1000# WHERE n=8888 。我们知道 # 是 mysql 行内注释，所以这个语句还能正常执行，只是没有了 WHERE 条件，并把整个库的所有用户数据都 update 了……

比较好的解决方案是：使用 MySQL 的预编译语句 Prepared statements 来生成 SQL 请求。这样做的好处，不仅是防止 SQL 语句出错甚至被注入。而且还能获得更高性能。

版权申明：本站文章均来自网络，如有侵权，请联系01056159998 邮箱：itboby@foxmail.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有