使用safemysql类来防止SQL注入是个好主意吗


Is it a good idea to use safemysql class to prevent SQL injections?

我想知道是否有人对这个脚本/class safemysql有经验?(除了这个脚本的开发者(

据宣布,这是mysql查询和防止网站进行sql注入的最安全方式。。我真的很喜欢你使用它的方式。

但它真的"安全"吗?这是好的代码吗…关闭mysql连接,这在这个脚本中没有发生。。难道没有必要吗?

很乐意与您讨论!

尽管有这个名字,但我不认为安全性是这个类的关键。不要误解我的意思,我并不是说它不安全。它实际上具有其他库通常没有的安全功能,例如标识符的占位符。

我的意思是,如果使用得当,内置扩展就足够安全,典型的创造性用户可以像使用任何其他库一样轻松地跳过占位符:

$foo = $db->getAll("select * from foo where foo_id={$_POST[foo_id]}");

这个类别与其他替代品的不同之处在于:

  1. 它提供了一种方便的语法来从非标量数据类型(例如数组(组成SQL查询
  2. 它提供了一个内置功能来编写INSERT查询
  3. 它提供了一个内置的值过滤器("白名单"(

而且它不会像大多数fraweworks那样强迫你使用糟糕的SQL语言克隆(毕竟它是一个助手,而不是一个框架,并为此感到自豪(。

数据类型占位符很奇怪(为什么我需要为单个值设置?i/?s,而不为数组设置?(并且作者以讨厌命名参数而闻名(所以你在这里找不到它们(。但这个项目并没有宣称已经完成。

总之:如果你喜欢sugar语法,就使用它,而不仅仅是为了安全。如果有什么东西坏了,那就是一个637行的文件——你可能可以自己修复:(

这个想法当然很棒
事实上,该类比其他广为宣传的解决方案(如原始PDO(更安全,不仅为极其有限的文字集提供占位符,还为可以放入查询的所有内容提供占位符

这样一来,它使应用程序代码大大缩短,使开发人员不再需要手动格式化数据。

唯一可能的缺点是

  • ?p占位符,必须谨慎使用
  • ?在NOT IN(?a)语句中放入空数组的占位符
  • 在处理时必须始终牢记白名单功能?u和?n个占位符。不过,所有内容都包含在示例中

当然,你可以很容易地扩展它,添加你个人需要的功能,比如关闭连接之类的。这就是OOP的确切用途。