然后，你使用包含用户输入内容的变量的值与之进行连接(在此，以粗体显示)：

　　SELECT * FROM wines WHERE variety = 'lagrein' or 1=1;

　　最后，添加上下面的下引号：

　　SELECT * FROM wines WHERE variety = 'lagrein' or 1=1;'

　　于是，这个查询结果与你的期望会相当不同。事实上，现在你的查询包含的不是一条而是两条指令，因为用户输入的最后的分号已经结束了第一条指令(进行记录选择)从而开始了一条新的指令。在本例中，第二条指令，除了一个简单的单引号之外别无意义;但是，第一条指令也不是你所想实现的。当用户把一个单引号放到他的输入内容的中间时，他结束了期望的变量的值，并且引入了另一个条件。因此，不再是检索那些variety为"lagrein"的记录，而是在检索那些满足两个标准中任何一个(第一个是你的，而第二个是他的-variety为"lagrein"或1等于1)的记录。既然1总是1，因此，你会检索到所有的记录!

　　你可能反对：我不会使用双引号来代替单引号来描述用户提交的变量吗?不错，这至少可以减慢恶意用户的攻击。(在以前的文章中，我们提醒过你：应该禁止所有对用户的错误通知信息。如果在此生成一条错误消息，那么，它有可能恰恰帮助了攻击者-提供一个关于他的攻击为什么失败的具体的解释。)

　　在实践中，使你的用户能够看到所有的记录而不只是其中的一部分乍看起来似乎不太费事，但实际上，这的确费事不少;看到所有的记录能够很容易地向他提供有关于该表格的内部结构，从而也就向他提供了使其以后实现更为恶毒目的的一个重要参考。如果你的数据库中不是包含显然无害的酒之类信息而是包含例如一个含有雇员年收入的列表，那么，刚才描述情形会是特别真实的。

　　而从理论角度分析，这种攻击也的确是一件很可怕的事情。由于把意外的内容注入到你的查询中，所以，此用户能够实现把你的数据库存取转化为用于实现他自己的目的。因此现在，你的数据库已经对他打开-正如对你敞开一样。

　　四、 PHP和MySQL注入

　　如我们前面所描述的，PHP，从本身设计来说，并没有做什么特别的事情-除了按照你的指示操作之外。因此，如果为恶意用户所用，它也只是按照要求"允许"特别设计的攻击-例如我们前面所描述的那样。

　　我们将假定，你不会故意地或甚至是偶然地构造一个具有破坏性效果的数据库查询-于是，我们假定问题出在来自你的用户的输入方面。现在，让我们来更为细致地分析一下用户可能向你的脚本提供信息的各种途径。

　　五、 用户输入的类型

　　如今，用户能够影响你的脚本的行为已变得越来越复杂。

　　用户输入最明显的来源当然是表单上的一个文本输入域。使用这样的一个域，你简直是在故意教唆一个用户输入任意数据。而且，你向用户提供了一个很大的输入范围;没有什么办法能够使你提前限制一个用户能够输入的数据类型(尽管你能够选择限制它的长度)。这正是绝大多数的注入式攻击源主要来自于无防备的表单域的原因。

　　但是，还存在其它的攻击源，并且稍加思考你就会想到的一种潜于表单后台的技术-POST方法!通过简单地分析显示在浏览器的导航工具栏中的URI，一个善于观察的用户能够很容易地看出是什么信息传递到了一个脚本。尽管典型情况下这样的URI是以编程方式生成的，但是，没有什么办法能够阻止一个恶意的用户简单地把一个带有一个不适当的变量值的URI输入到一个浏览器中-而这样潜在地打开一个可能会被其滥用的数据库。

　　限制用户输入内容的一个常用策略是在一个表单中提供一个选择框，而不是一个输入框。这种控件能够强制用户从一组预定义的值中进行选择，并且能够在一定程度上阻止用户输入期望不到的内容。但是正如一个攻击者可能"哄骗"一个URI(也即是，创建一个能够模仿一个可信任的却无效的URI)一样，他也可能模仿创建你的表单及其自己的版本，并因此在选项框中使用非法的而不是预定义的安全选择。要实现这点是极其简单的;他仅需要观察源码，然后剪切并且粘贴该表单的源代码-然后一切为他敞开大门。

　　在修改该选择之后，他就能够提交表单，并且他的无效的指令就会被接受，就象它们是原始的指令一样。因此，该用户可以使用许多不同的方法试图把恶意的代码注入到一个脚本中。