脚本安全的本质_PHP+MYSQL第2/3页
更新时间:2008年10月03日 20:21:00 作者:
从代码级别上,也就是应用层次上考虑代码安全的话(也就是不考虑底层的语言本身等问题的漏洞),脚本安全问题就是函数和变量的问题。
2 隐式的输入
上面这些是最原始的,没有经过程序转换的数据,程序很多地方用到的变量都来自这里,但也不表示其他的地方没有变量传递过来,下面有一个数据传递的模式:
用户传递的数据===========>数据库===========>程序代码处理=======>程序代码
这个模式的意思是用户的输入可能先进入了数据库,然后程序从数据库再取得这个输入送入某些危险的函数执行,一般的程序员都会有一个意识认为从数据库中取得的变量是安全的,但是事实并不如此,只要某些敏感字符最终送入到程序代码中,不管他中间停留在什么地方,都是危险的。与存储在数据库中类似的情况是,一些程序把用户的输入放到文件中,如缓存文件,然后在必要的时候从里面取得,如果太过相信这些地方来的变量,这样还是会导致问题的。
3 变量覆盖
还有很多的时候,程序收到的变量很可能来自他不应该来的地方,譬如Dz的代码:
$magic_quotes_gpc = get_magic_quotes_gpc();
@extract(daddslashes($_POST));
@extract(daddslashes($_GET));
if(!$magic_quotes_gpc) {
$_FILES = daddslashes($_FILES);
}
这样之后,你还觉得$_FILES是原来的$_FILES了么?如果我们建立一个_FILES的表单或者干脆在url里加上 php?_FILES[]=ddddd,这样之后$_FILES已经完全被覆盖了,然后你代码里引用的$_FILES就不是原来的了,在Dz以前的版本中曾经出现过这个问题。这应该属于变量覆盖的问题,把初始化的那个文件放大来看看吧:
复制代码 代码如下:
$magic_quotes_gpc = get_magic_quotes_gpc();
@extract(daddslashes($_POST));
@extract(daddslashes($_GET));
if(!$magic_quotes_gpc) {
$_FILES = daddslashes($_FILES);
}
$charset = $dbcharset = '';
$plugins = $hooks = array();
require_once DISCUZ_ROOT.'./config.inc.php';
require_once DISCUZ_ROOT.'./include/db_'.$database.'.class.php';
if($attackevasive) {
require_once DISCUZ_ROOT.'./include/security.inc.php';
}
这样貌似是没有问题的,但是满足一定的条件的话还是可能出问题,假设register_globals为on的话,我们进入全局的变量不只是$_GET 和$_POST吧!包括$_COOKIE和$_FILES以及$_SERVER都是会在全局数组中产生变量的,通过上面的语句,我们提交一个 php?_SERVER[PHP_SELF]就可以覆盖掉_SERVER数组,那么整个程序中的$_SERVER数组都是不可以相信的了。我也见过这样写的代码:
复制代码 代码如下:
require_once ROOT_PATH.'inc/database_config.php';
require_once
ROOT_PATH.'inc/dv_spacemain.php';
if(PHP_VERSION < '4.1.0') {
$_GET = &$HTTP_GET_VARS;
$_POST = &$HTTP_POST_VARS;
$_COOKIE = &$HTTP_COOKIE_VARS;
$_SERVER = &$HTTP_SERVER_VARS;
$_ENV = &$HTTP_ENV_VARS;
$_FILES = &$HTTP_POST_FILES;
$_SESSION =& $HTTP_SESSION_VARS;
}
$magic_quotes_gpc = get_magic_quotes_gpc();
$register_globals = @ini_get('register_globals');
if(!$register_globals || !$magic_quotes_gpc) {
@extract(i_addslashes($_POST));
@extract(i_addslashes($_GET));
@extract(i_addslashes($_COOKIE));
if(!$magic_quotes_gpc) {
$_FILES = i_addslashes($_FILES);
}
}
同样是在系统初始化的地方,但是变量的释放是在
require_once ROOT_PATH.'inc/general_funcs.php';
require_once ROOT_PATH.'inc/dv_spacemain.php';
这些关键变量初始化之后,那么我们完全可以提交一个?$host=xxx.xxx.xxx.xxx这样的东西覆盖掉系统自己的数据库初始化文件里的数据库地址变量,然后就可以
4 变量感染
这个很容易理解,当一个变量不安全的时候,与之有关的赋值等操作都是不安全的,譬如:
$id = $_GET[id];
..
$articleid = $id;
实际过程中可能没有这么明显,但是结果是一样的,只要某个变量把敏感字符带入不该带的地方,那么就会产生威胁,不只是变量,不安全的函数会让使用这个函数的所有代码都变的不安全。
相关文章
phpMyAdmin出现无法载入 mcrypt 扩展,请检查PHP配置的解决方法
出现以下几种情况后可能会造成运行phpmyadmin程序提示 无法载入 mcrypt 扩展,请检查 PHP 配置 的 错误提示2012-03-03
最新评论