•   先盾博客开放注册
  •   先盾博客开放注册

游戏安全:服务端SQL安全方案

摘要: 数据库SQL语句的安全方案1.必须禁用字符串操作的方式来组合执行SQL语句。而使用预编译语句Preparedstatements来生成并执行SQL的请求。...
云服务器

数据库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 语句出错甚至被注入。而且还能获得更高性能。

云服务器

本文链接:http://www.1368vps.com/post/191.html

版权声明:版权申明:本站文章均来自先盾博客,如有侵权,请联系QQ:2138890079 邮箱:2138890079@qq.com 特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有 【声明】:本博客不参与任何交易,也非中介,仅记录个人感兴趣的,内容均不作直接、间接、法定、约定的保证。访问本博客请务必遵守有关互联网的相关法律、规定与规则。一旦您访问本博客,即表示您已经知晓并接受了此声明通告。

分享到:

发表评论

评论列表

还没有评论,快来说点什么吧~