在本系列文章中我们将全面探讨如何在PHP开发环境中全面阻止SQL注入式攻击并给出一个具体的开发示例
一 引言
PHP是一种力量强大但相当容易学习的服务器端脚本语言即使是经验不多的程序员也能够使用它来创建复杂的动态的web站点然而它在实现因特网服务的秘密和安全方面却常常存在许多困难在本系列文章中我们将向读者介绍进行web开发所必需的安全背景以及PHP特定的知识和代码你可以借以保护你自己的web应用程序的安全性和一致性首先我们简单地回顾一下服务器安全问题展示你如何存取一个共享宿主环境下的私人信息使开发者脱离开生产服务器维持最新的软件提供加密的频道并且控制对你的系统的存取
然后我们讨论PHP脚本实现中的普遍存在的脆弱性我们将解释如何保护你的脚本免于SQL注入防止跨站点脚本化和远程执行并且阻止对临时文件及会话的劫持
在最后一篇中我们将实现一个安全的Web应用程序你将学习如何验证用户身份授权并跟蹤应用程序使用避免数据损失安全地执行高风险性的系统命令并能够安全地使用web服务无论你是否有足够的PHP安全开发经验本系列文章都会提供丰富的信息来帮助你构建更为安全的在线应用程序
二 什么是SQL注入
如果你打算永远不使用某些数据的话那么把它们存储于一个数据库是毫无意义的因为数据库的设计目的是为了方便地存取和操作数据库中的数据但是如果只是简单地这样做则有可能会导致潜在的灾难这种情况并不主要是因为你自己可能偶然删除数据库中的一切而是因为当你试图完成某项无辜的任务时你有可能被某些人所劫持使用他自己的破坏性数据来取代你自己的数据我们称这种取代为注入
其实每当你要求用户输入构造一个数据库查询你是在允许该用户参与构建一个存取数据库服务器的命令一位友好的用户可能对实现这样的操作感觉很满意然而一位恶意的用户将会试图发现一种方法来扭曲该命令从而导致该被的扭曲命令删除数据甚至做出更为危险的事情作为一个程序员你的任务是寻找一种方法来避免这样的恶意攻击
三 SQL注入工作原理
构造一个数据库查询是一个非常直接的过程典型地它会遵循如下思路来实现仅为说明问题我们将假定你有一个葡萄酒数据库表格wines其中有一个字段为variety（即葡萄酒类型）
提供一个表单允许用户提交某些要搜索的内容让我们假定用户选择搜索类型为lagrein的葡萄酒
检索该用户的搜索术语并且保存它通过把它赋给一个如下所示的变量来实现
$variety = $_POST[variety];
因此变量$variety的值现在为
lagrein
然后使用该变量在WHERE子句中构造一个数据库查询
$query = SELECT * FROM wines WHERE variety=$variety;
所以变量$query的值现在如下所示
SELECT * FROM wines WHERE variety=lagrein
把该查询提交给MySQL服务器
MySQL返回wines表格中的所有记录其中字段variety的值为lagrein
到目前为止这应该是一个你所熟悉的而且是非常轻松的过程遗憾的是有时我们所熟悉并感到舒适的过程却容易导致我们产生自满情绪现在让我们再重新分析一下刚才构建的查询
你创建的这个查询的固定部分以一个单引号结束你将使用它来描述变量值的开始
$query = SELECT * FROM wines WHERE variety = ;
使用原有的固定不变的部分与包含用户提交的变量的值
$query = $variety;
然后你使用另一个单引号来连接此结果描述该变量值的结束
$ query = ;
于是$query的值如下所示
SELECT * FROM wines WHERE variety = lagrein
这个构造的成功依赖用户的输入在本文示例中你正在使用单个单词(也可能是一组单词)来指明一种葡萄酒类型因此该查询的构建是无任何问题的并且结果也会是你所期望的一个葡萄酒类型为lagrein的葡萄酒列表现在让我们想象既然你的用户不是输入一个简单的类型为lagrein的葡萄酒类型而是输入了下列内容(注意包括其中的两个标点符号)
lagrein or =;
现在你继续使用前面固定的部分来构造你的查询(在此我们仅显示$query变量的结果值)
SELECT * FROM wines WHERE variety =
然后你使用包含用户输入内容的变量的值与之进行连接(在此以粗体显示)
SELECT * FROM wines WHERE variety = lagrein or =;
最后添加上下面的下引号
SELECT * FROM wines WHERE variety = lagrein or =;
于是这个查询结果与你的期望会相当不同事实上现在你的查询包含的不是一条而是两条指令因为用户输入的最后的分号已经结束了第一条指令(进行记录选择)从而开始了一条新的指令在本例中第二条指令除了一个简单的单引号之外别无意义但是第一条指令也不是你所想实现的当用户把一个单引号放到他的输入内容的中间时他结束了期望的变量的值并且引入了另一个条件因此不再是检索那些variety为lagrein的记录而是在检索那些满足两个标准中任何一个（第一个是你的而第二个是他的variety为lagrein或等于）的记录既然总是因此你会检索到所有的记录！
你可能反对我不会使用双引号来代替单引号来描述用户提交的变量吗？不错这至少可以减慢恶意用户的攻击(在以前的文章中我们提醒过你应该禁止所有对用户的错误通知信息如果在此生成一条错误消息那么它有可能恰恰帮助了攻击者提供一个关于他的攻击为什么失败的具体的解释)
在实践中使你的用户能够看到所有的记录而不只是其中的一部分乍看起来似乎不太费事但实际上这的确费事不少看到所有的记录能够很容易地向他提供有关于该表格的内部结构从而也就向他提供了使其以后实现更为恶毒目的的一个重要参考如果你的数据库中不是包含显然无害的酒之类信息而是包含例如一个含有雇员年收入的列表那么刚才描述情形会是特别真实的
而从理论角度分析这种攻击也的确是一件很可怕的事情由于把意外的内容注入到你的查询中所以此用户能够实现把你的数据库存取转化为用于实现他自己的目的因此现在你的数据库已经对他打开正如对你敞开一样
四 PHP和MySQL注入
如我们前面所描述的PHP从本身设计来说并没有做什么特别的事情除了按照你的指示操作之外因此如果为恶意用户所用它也只是按照要求允许特别设计的攻击例如我们前面所描述的那样
我们将假定你不会故意地或甚至是偶然地构造一个具有破坏性效果的数据库查询于是我们假定问题出在来自你的用户的输入方面现在让我们来更为细致地分析一下用户可能向你的脚本提供信息的各种途径
五 用户输入的类型
如今用户能够影响你的脚本的行为已变得越来越复杂
用户输入最明显的来源当然是表单上的一个文本输入域使用这样的一个域你简直是在故意教唆一个用户输入任意数据而且你向用户提供了一个很大的输入范围没有什么办法能够使你提前限制一个用户能够输入的数据类型(尽管你能够选择限制它的长度)这正是绝大多数的注入式攻击源主要来自于无防备的表单域的原因
但是还存在其它的攻击源并且稍加思考你就会想到的一种潜于表单后台的技术POST方法！通过简单地分析显示在浏览器的导航工具栏中的URI一个善于观察的用户能够很容易地看出是什么信息传递到了一个脚本尽管典型情况下这样的URI是以编程方式生成的但是没有什么办法能够阻止一个恶意的用户简单地把一个带有一个不适当的变量值的URI输入到一个浏览器中而这样潜在地打开一个可能会被其滥用的数据库
限制用户输入内容的一个常用策略是在一个表单中提供一个选择框而不是一个输入框这种控件能够强制用户从一组预定义的值中进行选择并且能够在一定程度上阻止用户输入期望不到的内容但是正如一个攻击者可能哄骗一个URI(也即是创建一个能够模仿一个可信任的却无效的URI)一样他也可能模仿创建你的表单及其自己的版本并因此在选项框中使用非法的而不是预定义的安全选择要实现这点是极其简单的他仅需要观察源码然后剪切并且粘贴该表单的源代码然后一切为他敞开大门
在修改该选择之后他就能够提交表单并且他的无效的指令就会被接受就象它们是原始的指令一样因此该用户可以使用许多不同的方法试图把恶意的代码注入到一个脚本中
