关于 Web 应用程序安全性,必须认识到的第一件事是不应该信任外部数据。外部数据(outside data) 包括不是由程序员在 PHP 代码中直接输入的任何数据。在采取措施确保安全之前,来自任何其他来源(比如 GET
变量、表单 POST
、数据库、配置文件、会话变量或 cookie)的任何数据都是不可信任的。
例如,下面的数据元素可以被认为是安全的,因为它们是在 PHP 中设置的。
$arrayUsers = array ( ' tmyer ' , ' tom ' , ' tommy ' );
define ( " GREETING " , ' hello there ' . $myUsername );
但是,下面的数据元素都是有瑕疵的。
$arrayUsers = array ( $myUsername , ' tom ' , ' tommy ' ); // tainted!
define ( " GREETING " , ' hello there ' . $myUsername ); // tainted!
为什么第一个变量 $myUsername
是有瑕疵的?因为它直接来自表单 POST
。用户可以在这个输入域中输入任何字符串,包括用来清除文件或运行以前上传的文件的恶意命令。您可能会问,“难道不能使用只接受字母 A-Z 的客户端(JavaScript)表单检验脚本来避免这种危险吗?”是的,这总是一个有好处的步骤,但是正如在后面会看到的,任何人都可以将任何表单下载到自己的机器上,修改它,然后重新提交他们需要的任何内容。
解决方案很简单:必须对 $_POST['username']
运行清理代码。如果不这么做,那么在使用 $myUsername
的任何其他时候(比如在数组或常量中),就可能污染这些对象。
对用户输入进行清理的一个简单方法是,使用正则表达式来处理它。在这个示例中,只希望接受字母。将字符串限制为特定数量的字符,或者要求所有字母都是
小写的,这可能也是个好主意。
$arrayUsers = array ( $myUsername , ' tom ' , ' tommy ' ); // clean!
define ( " GREETING " , ' hello there ' . $myUsername ); // clean!
function cleanInput( $input ){
$clean = strtolower ( $input );
$clean = preg_replace ( " /[^a-z]/ " , "" , $clean );
$clean = substr ( $clean , 0 , 12 );
return $clean ;
}
已经知道了不能信任用户输入,还应该知道不应该信任机器上配置 PHP 的方式。例如,要确保禁用 register_globals
。如果启用了 register_globals
,就可能做一些粗心的事情,比如使用 $variable
替换同名的 GET
或 POST
字符串。通过禁用这个设置,PHP 强迫您在正确的名称空间中引用正确的变量。要使用来自表单 POST
的变量,应该引用 $_POST['variable']
。这样就不会将这个特定变量误会成 cookie、会话或 GET
变量。
要检查的第二个设置是错误报告级别。在开发期间,希望获得尽可能多的错误报告,但是在交付项目时,希望将错误记录到日志文件中,而不是显示在屏幕上。为什么呢?因为恶意的黑客会使用错误报告信息(比如 SQL 错误)来猜测应用程序正在做什么。这种侦察可以帮助黑客突破应用程序。为了堵住这个漏洞,需要编辑 php.ini 文件,为 error_log
条目提供合适的目的地,并将 display_errors
设置为 Off。
一些开发人员使用奇怪的语法,或者将语句组织得很紧凑,形成简短但是含义模糊的代码。这种方式可能效率高,但是如果您不理解代码正在做什么,那么就无法决定如何保护它。
例如,您喜欢下面两段代码中的哪一段?
$input = ( isset ( $_POST [ ' username ' ]) ? $_POST [ ' username ' ] : '' );
// unobfuscated code
$input = '' ;
if ( isset ( $_POST [ ' username ' ])){
$input = $_POST [ ' username ' ];
} else {
$input = '' ;
}
在第二个比较清晰的代码段中,很容易看出 $input
是有瑕疵的,需要进行清理,然后才能安全地处理。
本教程将用示例来说明如何保护在线表单,同时在处理表单的 PHP 代码中采用必要的措施。同样,即使使用 PHP regex
来确保 GET
变量完全是数字的,仍然可以采取措施确保 SQL 查询使用转义的用户输入。
纵深防御不只是一种好思想,它可以确保您不会陷入严重的麻烦。
既然已经讨论了基本规则,现在就来研究第一种威胁:SQL 注入攻击。