6.1.7 Client 端编程安全准则

访问 MySQL 的应用程序不应信任用户 Importing 的任何数据，用户可以尝试通过在 Webtable 单，URL 或您构建的任何应用程序中 Importing 特殊或转义的字符序列来欺骗您的代码。如果用户 Importing; DROP DATABASE mysql;之类的内容，请确保您的应用程序保持安全。这是一个极端的例子，但是如果您不准备使用黑客的技术，则可能由于黑客使用类似的技术而导致大量的安全漏洞和数据丢失。

一个常见的错误是仅保护字符串数据值。切记还要检查数字数据。如果当用户 Importing 值234时应用程序生成了诸如SELECT * FROM table WHERE ID=234之类的查询，则用户可以 Importing 值234 OR 1=1来使应用程序生成查询SELECT * FROM table WHERE ID=234 OR 1=1。结果，服务器检索 table 中的每一行。这会暴露每一行并导致过多的服务器负载。防止此类攻击的最简单方法是在数字常量SELECT * FROM table WHERE ID='234'周围使用单引号。如果用户 Importing 其他信息，则所有信息都将成为字符串的一部分。在数字上下文中，MySQL 自动将此字符串转换为数字，并从中去除所有尾随的非数字字符。

有时人们认为，如果数据库仅包含公开可用的数据，则无需对其进行保护。这是不正确的。即使允许在数据库中显示任何行，您仍应防止拒绝服务攻击(例如，基于上段技术的那些导致服务器浪费资源的攻击)。否则，您的服务器将无法响应合法用户。

Checklist:

• 启用严格的 SQL 模式，以告诉服务器对其接收的数据值有更多的限制。参见第 5.1.10 节“服务器 SQL 模式”。

• 尝试在所有 Webtable 单中 Importing 单引号和双引号('和")。如果您遇到任何 MySQL 错误，请立即调查问题。

• 尝试通过向它们添加%22(")，%23(#)和%27(')来修改动态 URL。

• 尝试使用前面示例中显示的字符，将动态 URL 中的数据类型从数字类型修改为字符类型。您的应用程序应该对这些和类似的攻击是安全的。

• 尝试在数字字段中 Importing 字符，空格和特殊符号，而不要 Importing 数字。您的应用程序应在将它们传递给 MySQL 之前将其删除，否则会产生错误。将未经检查的值传递给 MySQL 非常危险！

• 在将数据传递给 MySQL 之前，请检查其大小。

• 让您的应用程序使用与用于 Management 目的的用户名不同的用户名连接到数据库。不要给您的应用程序不需要的访问权限。

许多应用程序编程接口提供了一种在数据值中转义特殊字符的方法。如果使用得当，这可以防止应用程序用户 Importing 导致应用程序生成效果与您预期不同的语句的值：

• MySQL C API：使用mysql_real_escape_string_quote() API 调用。

• MySQL：对查询流使用escape和quote修饰符。

• PHP：使用mysqli或pdo_mysqlextensions，而不使用较旧的ext/mysqlextensions。首选的 API 支持改进的 MySQL 身份验证协议和密码，以及带占位符的预备语句。另请参见选择一个 API。

如果必须使用较旧的ext/mysqlextensions，则为了转义，请使用mysql_real_escape_string_quote()函数，而不要使用mysql_escape_string()或addslashes()，因为只有mysql_real_escape_string_quote()可以识别字符集；使用(无效)多字节字符集时，可以“绕过”其他功能。

• Perl DBI：使用占位符或quote()方法。

• Ruby DBI：使用占位符或quote()方法。

• Java JDBC：使用PreparedStatement对象和占位符。

其他编程接口可能具有类似的功能。