MySQL 转义字符串 VS。参数化查询答案

【问题标题】：MySQL escaped_strings VS. Parameterised QueriesMySQL 转义字符串 VS。参数化查询
【发布时间】：2012-01-08 18:08:04
【问题描述】：

刚刚阅读参数化查询，这似乎是数据库防御中的最后一句话，并且想知道以下内容：

我有一个现有的 PHP/MySQL 自建 CMS，其中所有输入（条形复选框和单选按钮）都受 real_escape_string 的约束。有一个管理部分可通过 sha1 加密密码和匹配的用户名访问，一小群 (3) 受信任的人可以在其中更新内容 (tinyMCE)、上传照片等。非常小。我的所有查询都没有参数化，而是仅在转义后执行。

没有来自公众的意见，但我确实想稍后将其开放给用户提交的表单。

我的主人是私人的，记录非常好。

在其他条件相同的情况下，我有多安全？

【问题讨论】：

标签： mysql mysql-real-escape-string parameterized database-security

【解决方案1】：

mysql_real_escape_string不会立即保护您免受 SQL 注入攻击。我最近帮助了一个小网站的开发人员，他认为我在所有输入上都可以安全地拨打mysql_real_escape_string，但仍然得到了pwn'd。在他的例子中，他期望一个变量（通过 GET 字符串）是一个整数，但并没有这样验证它。然后，攻击者利用该 ID 字段来制作自定义查询并获得对他的整个数据库的访问权限。

故事的寓意？验证，验证，验证。您需要假设来自外部的每一条可能的数据（即使它是您填充的<input type="hidden">）都是试图绕过安全措施。这就是使用 Codeigniter 等框架很有帮助的地方，因为它们内置了验证组件。如果您想自己做所有事情，请小心并检查所有输入变量。

【讨论】：

通过验证，你的意思是转换，然后转义？或者还有什么可以做的？
在我提到的情况下，一个简单的is_numeric 可以避免这个问题。

【解决方案2】：

我宁愿使用参数化/准备好的语句。与仅转义输入相比，它们允许您指定方便的类型（例如，您没有将日期时间值转换为特定于服务器的格式），并且它还解决了不同 RDMS 在处理转换错误时的歧义。例如查询SELECT * FROM table1 WHERE int_field='aaa'（int_field为整数）在Mysql中返回int_field等于0的记录，在Oracle和SQLServer中报错，在SQlite中返回空集

【讨论】：

是的，参数化似乎是要走的路。但是，我想知道，当这些查询已经被转义时，有人为此重写这么多查询有多大必要......
@Eamonn：在我看来，这一切都取决于项目。有时，由于时间/人力资源有限，不可能实现所有最佳实践……此外，这种重构的成本与整体应用程序设计有关。将所有 sql 查询保存在单独的模块中，并且仅通过专用数据访问层访问 db 显着减少了工作量。
这对于大型应用程序来说似乎非常有效 - 作为进一步的查询，您是否知道指导我构建这样一个框架的好资源，或者它是一个非常适合当下的案例?
我可以推荐一些可能有用的书（以我的主观意见）。它们涵盖了软件工程的不同方面，并有助于构建健壮的系统。 Eric Evans 的领域驱动设计，Michael Feather 的有效处理遗留代码，Joshua Kerievsky 的模式重构，Robert C. Martin 的清洁代码：敏捷软件工艺手册。
太好了，谢谢你 - 非常有帮助！我一定会查查所有这些。我将推迟选择答案，因为我很想知道人们会在纯粹的 real_escaped 系统上指出哪些缺陷。但再次感谢！