时间:2021-07-01 10:21:17 帮助过:28人阅读
1. 供给一个表单-答利用户提交某些要搜索的内容。让我们假定用户选择搜索类型为'lagrein'的葡萄酒。
2. 检索该用户的搜索术语,并且保留它-通过把它赋给一个如下所示的变量来实现:
$variety = $_POST['variety'];
因此,变量$variety的值现在为:
lagrein
3. 然后,应用该变量在WHERE子句中结构一个数据库查询:
$query = 'SELECT * FROM wines WHERE variety='$variety'';
所以,变量$query的值现在如下所示:
SELECT * FROM wines WHERE variety='lagrein'
4. 把该查询提交给MySQL服务器。
5. MySQL返回wines表格中的所有记录-其中,字段variety的值为'lagrein'。
到目前为止,这应当是一个你所熟悉的而且是非常轻松的过程。遗憾的是,有时我们所熟悉并感到舒适的过程却轻易导致我们产生骄傲情感。现在,让我们再重新分析一下刚才构建的查询。
1. 你创立的这个查询的固定部分以一个单引号结束,你将应用它来描写变量值的开端:
$query = ' SELECT * FROM wines WHERE variety = '';
2. 应用原有的固定不变的部分与包含用户提交的变量的值:
$query .= $variety;
3. 然后,你应用另一个单引号来连接此成果-描写该变量值的结束:
$ query .= ''';
于是,$query的值如下所示:
SELECT * FROM wines WHERE variety = 'lagrein'
这个结构的成功依附用户的输进。在本文示例中,你正在应用单个单词(也可能是一组单词)来指明一种葡萄酒类型。因此,该查询的构建是无任何标题的,并且成果也会是你所期看的-一个葡萄酒类型为'lagrein'的葡萄酒列表。现在,让我们想象,既然你的用户不是输进一个简略的类型为'lagrein'的葡萄酒类型,而是输进了下列内容(留心包含其中的两个标点符号):
lagrein' or 1=1;
现在,你持续应用前面固定的部分来结构你的查询(在此,我们仅显示$query变量的成果值):
SELECT * FROM wines WHERE variety = '
然后,你应用包含用户输进内容的变量的值与之进行连接(在此,以粗体显示):
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)一样,他也可能模仿创立你的表单及其自己的版本,并因此在选项框中应用非法的而不是预定义的安全选择。要实现这点是极其简略的;他仅需要观察源码,然后剪切并且粘贴该表单的源代码-然后一切为他敞开大门。
在修正该选择之后,他就能够提交表单,并且他的无效的指令就会被接收,就象它们是原始的指令一样。因此,该用户可以应用很多不同的方法试图把恶意的代码注进到一个脚本中。
以上就是在PHP中全面禁止SQL注进式攻击之一的内容,更多相关内容请关注PHP中文网(www.gxlcms.com)!