每个人可能会想到，注入问题都是由于执行了数值数据中的SQL关键字，那样，只需检测数值数据中是不是存有SQL关键字就可以了么？确实如此，许多数据库管理系统都采用了这种看似方便快捷的过滤方法，但这并不是一个根本的解决方案，如果真的有一个美国人叫DrOpTinble，那应该怎么办？不能总是强迫别人改名字吧。

保护方法有很多种。第一，尽量避免常用数据库名和数据库结构。在上述情况下，如果表单名称不是students，则在执行期间注入代码将错误提示，并且不会发生数据丢失——SQL注入并不像大家想象的那样简单，它要求攻击者本身对数据库的结构有足够的了解，从而在构建数据库时尽量应用更复杂的结构和命名方法，从而大大降低被成功攻击的可能性。

除此之外，还能够应用正则表达式等字符串过滤手段限制数值数据的文件格式、字符数等。从理论上讲，只需数值数据中不存在引号、分号等特殊字符，就可以在很大程度上杜绝SQL注入。除此之外，还能够应用各种各样程序代码文本文档所提议的数据库操作方法对数值数据执行查询和写操作，例如，在上面的例子中，如果我们对SQL执行语句进行了一些修改，首先应用execute()方法确保每次执行只能执行一条语句，然后将数值数据与SQL执行语句相分离，那样就完全避免了SQL注入问题，如SQL数据库反注入实例。对于PHP，您还可以利用mysql_screen_escape_strover等方法转译SQL关键字，并在必要时检测数值数据是不是安全，以防止SQL注入。

当然，在对敏感内容加密的同时，做好数据库的备份一直是至关重要的。一些安全问题可能永远也不会有完美的解决办法，只有我们做好最基本的保护，当出现问题时才能不管不问，保证最小的损失。

注：但凡一个程序代码存有SQL注入漏洞，都是由于程序代码接受来自客户客户输入的变量值或URL传递的基本参数，并且该变量值或基本参数是构成SQL语句的一部分，对于客户输入的内容或传递的基本参数，我们应当时刻提高警惕，这也是安全领域「外部数据不能信任」的基本原则，纵览Web安全领域的各种各样攻击方式，大部分都是由于开发者违反此基本原则而引起的，自然，还可以从检测、过滤、验证等方面入手，确保变量值符合开发者的预期。