在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
[全局变量] 很显然,基于PHP的应用程序的主函数一般都是接受用户的输入(主要是表单变量,上载文件和Cookie等),然后对输入数据进行处理,然后把结果返回到客户端浏览器。为了使PHP代码访问用户的输入尽可能容易,实际上PHP是把这些输入数据看作全局变量来处理的。 例如: <FORM METHOD="GET" ACTION="test.php"> 很显然,这会显示一个文本框和提交按钮。当用户点击提交按钮时,“test.php”会处理用户的输入,当“test.php”运行时,“$hello”会包含用户在文本框输入的数据。从这里我们应该看出,攻击者可以按照自己的意愿创建任意的全局变量。如果攻击者不是通过表单输入来调用“test.php”,而是直接在浏览器地址栏输入http://server/test.php?hello=hi&set...敲矗恢故恰?/a>$hello”被创建,“$setup”也被创建了。 译者注:这两种方法也就是我们通常说的“POST”和“GET”方法。 <?php 上面的代码首先检查用户的密码是否为“hello”,如果匹配的话,设置“$auth”为“1”,即通过认证。之后如果“$suth”为“1”的话,就会显示一些重要信息。 表面看起来是正确的,而且我们中有相当一部分人是这样做的,但是这段代码犯了想当然的错误,它假定“$auth”在没有设置值的时候是空的,却没有想到攻击者可以创建任何全局变量并赋值,通过类似“http://server/test.php?auth=1”的方...且丫现す摹?/a> 因此,为了提高PHP程序的安全性,我们不能相信任何没有明确定义的变量。如果程序中的变量很多的话,这可是一项非常艰巨的任务。 一种常用的保护方式就是检查数组HTTP_GET[]或POST_VARS[]中的变量,这依赖于我们的提交方式(GET或POST)。当PHP配置为打开“track_vars”选项的话(这是缺省值),用户提交的变量就可以在全局变量和上面提到的数组中获得。 但是值得说明的是,PHP有四个不同的数组变量用来处理用户的输入。HTTP_GET_VARS数组用来处理GET方式提交的变量,HTTP_POST_VARS数组用于处理POST方式提交的变量,HTTP_COOKIE_VARS数组用于处理作为cookie头提交的变量,而对于HTTP_POST_FILES数组(比较新的PHP才提供),则完全是用户用来提交变量的一种可选方式。用户的一个请求可以很容易的把变量存在这四个数组中,因此一个安全的PHP程序应该检查这四个数组。 [远程文件] <?php 上面的脚本试图打开文件“$filename”,如果失败就显示错误信息。很明显,如果我们能够指定“$filename”的话,就能利用这个脚本浏览系统中的任何文件。但是,这个脚本还存在一个不太明显的特性,那就是它可以从任何其它WEB或FTP站点读取文件。实际上,PHP的大多数文件处理函数对远程文件的处理是透明的。 例如: 则上面的代码实际上是利用主机target上的unicode漏洞,执行了dir命令。 这使得支持远程文件的include(),require(),include_once()和require_once()在上下文环境中变得更有趣。这些函数主要功能是包含指定文件的内容,并且把它们按照PHP代码解释,主要是用在库文件上。 例如: 上例中“$libdir”一般是一个在执行代码前已经设置好的路径,如果攻击者能够使得“$libdir”没有被设置的话,那么他就可以改变这个路径。但是攻击者并不能做任何事情,因为他们只能在他们指定的路径中访问文件languages.php(perl中的“Poison null byte”攻击对PHP没有作用)。但是由于有了对远程文件的支持,攻击呔涂梢宰鋈魏问虑椤@纾セ髡呖梢栽谀程ǚ衿魃戏乓桓鑫募anguages.php,包含如下内容: <?php 然后把“$libdir”设置为“http://<;evilhost>/”,这样我们就可以在目标主机上执行上面的攻击代码,“/etc”目录的内容作为结果返回到客户的浏览器中。
[文件上载] <FORM METHOD="POST" ENCTYPE="multipart/form-data"> 上面的代码让用户从本地机器选择一个文件,当点击提交后,文件就会被上载到服务器。这显然是很有用的功能,但是PHP的响应方式使这项功能变的不安全。当PHP第一次接到这种请求,甚至在它开始解析被调用的PHP代码之前,它会先接受远程用户的文件,检查文件的长度是否超过“$MAX_FILE_SIZE variable”定义的值,如果通过这些测试的话,文件就会被存在本地的一个临时目录中。 因此,攻击者可以发送任意文件给运行PHP的主机,在PHP程序还没有决定是否接受文件上载时,文件已经被存在服务器上了。 这里我就不讨论利用文件上载来对服务器进行DOS攻击的可能性了。 让我们考虑一下处理文件上载的PHP程序,正如我们上面说的,文件被接收并且存在服务器上(位置是在配置文件中指定的,一般是/tmp),扩展名一般是随机的,类似“phpxXuoXG”的形式。PHP程序需要上载文件的信息以便处理它,这可以通过两种方式,一种方式是在PHP 3中已经使用的,另一种是在我们对以前的方法提出安全公告后引入的。 但是,我们可以肯定的说,问题还是存在的,大多数PHP程序还是使用老的方式来处理上载文件。PHP设置了四个全局变量来描述上载文件,比如说上面的例子: $hello = Filename on local machine (e.g "/tmp/phpxXuoXG") 然后PHP程序开始处理根据“$hello”指定的文件,问题在于“$hello”不一定是一个PHP设置的变量,任何远程用户都可以指定它。如果我们使用下面的方式: http://vulnhost/vuln.php?hello=/etc..._name=hello.txt 就导致了下面的PHP全局变量(当然POST方式也可以(甚至是Cookie)): $hello = "/etc/passwd" 上面的表单数据正好满足了PHP程序所期望的变量,但是这时PHP程序不再处理上载的文件,而是处理“/etc/passwd”(通常会导致内容暴露)。这种攻击可以用于暴露任何敏感文件的内容。 我在前面已经说了,新版本的PHP使用HTTP_POST_FILES[]来决定上载文件,同时也提供了很多函数来解决这个问题,例如有一个函数用来判断某个文件是不是实际上载的文件。这些函数很好的解决了这个问题,但是实际上肯定有很多PHP程序仍然使用旧的方法,很容易受到这种攻击。 作为文件上载的攻击方法的一个变种,我们看一下下面的一段代码: <?php 如果攻击者可以控制“$theme”的话,很显然它可以利用“$theme”来读取远程系统上的任何文件。攻击者的最终目标是在远程服务器上执行任意指令,但是他无法使用远程文件,因此,他必须得在远程服务器上创建一个PHP文件。这乍看起来好象是不可能的,但是文件上载帮了我们这个忙,如果攻击者先在本地机器上创建一个包含PHP代码的文件,然后创建一个包含名为“theme”的文件域的表单,最后用这个表单通过文件上载把创建的包含PHP代码的文件提交给上面的代码,PHP就会把攻击者提交的文件保存起来,并把“$theme”的值设置为攻击者提交的文件,这样file_exists()函数会检查通过,攻击者的代码也将执行。 获得执行任意指令的能力之后,攻击者显然想提升权限或者是扩大战果,而这又需要一些服务器上没有的工具集,而文件上载又一次帮了我们这个忙。攻击者可以使用文件上载功能上载工具,把她们存在服务器上,然后利用他们执行指令的能力,使用chmod()改变文件的权限,然后执行。例如:攻击者可以绕过防火墙或IDS上载一个本地root攻击程序,然后执行,这样就获得了root权限。 [库文件] 最初,人们开发和发布PHP程序的时候,为了区别代码库和主程序代码,一般是为代码库文件设置一个“.inc”的扩展名,但是他们很快发现这是一个错误,因为这样的文件无法被PHP解释器正确解析为PHP代码。如果我们直接请求服务器上的这种文件时,我们就会得到该文件的源代码,这是因为当把PHP作为Apache的模块使用时,PHP解释器是根据文件的扩展名来决定是否解析为PHP代码的。扩展名是站点管理员指定的,一般是“.php”, “.php3”和“.php4”。如果重要的配置数据被包含在没有合适的扩展名的PHP文件中,那么远程攻击者很容易得到这些信息。 最简单的解决方法就是给每个文件都指定一个PHP文件的扩展名,这样可以很好的防止泄露源代码的问题,但是又产生了新的问题,通过请求这个文件,攻击者可能使本该在上下文环境中运行的代码独立运行,这可能导致前面讨论的全部攻击。 下面是一个很明显的例子: In main.php: ... include("$libdir/loadlanguage.php": In libdir/loadlanguage.php: include("$langDir/$userLang"); 当“libdir/loadlanguage.php”被“main.php”调用时是相当安全的,但是因为“libdir/loadlanguage”具有“.php”的扩展名,因此远程攻击者可以直接请求这个文件,并且可以任意指定“$langDir”和“$userLang”的值。 [Session文件]
<?php 新版本的PHP都会自动把“$session_auth”的值设置为“shaun”,如果它们被修改的话,以后的脚本都会自动接受修改后的值,这对无状态的Web来说的确是种很不错的工具,但是我们也应该小心。 一个很明显的问题就是确保变量的确来自session,例如,给定上面的代码,如果后续的脚本是下面这样的话: <?php 上面的代码假定如果“$session_auth”被置位的话,就是从session,而不是从用户输入来置位的,如果攻击者通过表单输入来置位的话,他就可以获得对站点的访问权。注意攻击者必须在session注册该变量之前使用这种攻击方法,一旦变量被放进了session,就会覆盖任何表单输入。
Session机制也为攻击者把自己的输入保存在远程系统的文件中提供了另一个方便的地方,对于上面的例子来说,攻击者需要在远程系统放置一个包含PHP代码的文件,如果不能利用文件上载做到的话,他通常会利用session为一个变量按照自己的意愿赋一个值,然后猜测session文件的位置,而他知道文件名是“php<session id>”,所以只需猜测目录,而目录一般就是“/tmp”。 另外,攻击者可以任意指定“session id”(例如“hello”),然后用这个“session id”创建一个session文件(例如“/tmp/sess_hello”),但是“session id”只能是字母和数字组合。 [数据类型] PHP中的数组是关联数组,也就是说,数组的索引是字符串型的。这意味着“$hello["000"]”和“$hello[0]”也是不同的。 开发程序的时候应该仔细地考虑上面的问题,例如,我们不应该在一个地方测试某个变量是否为“0”,而在另外的地方使用empty()来验证。 [容易出错的函数] <PHP代码执行> <命令执行> <文件泄露> 译者注:其实这份列表还不是很全,比如“mail()”等命令也可能执行命令,所以需要自己补充一下。 *低难度 上面的分类只是个人的看法,但是我可以保证,如果你使用了PHP提供的所有选项的话,那么你的PHP将是很安全的,即使是第三方的代码也是如此,因为其中很多功能已经不能使用。 **** 设置“register_globals”为“off” 这个选项会禁止PHP为用户输入创建全局变量,也就是说,如果用户提交表单变量“hello”,PHP不会创建“$ hello”,而只会创建“HTTP_GET/POST_VARS[hello]”。这是PHP中一个极其重要的选项,关闭这个选项,会给编程带来很大的不便。 *** 设置“safe_mode”为“on” ** 设置“open_basedir” ** 设置“display_errors”为“off”,设置“log_errors”为“on” 这个选项禁止把错误信息显示在网页中,而是记录到日志文件中,这可以有效的抵制攻击者对目标脚本中函数的探测。 * 设置“allow_url_fopen”为“off” 这个选项可以禁止远程文件功能,极力推荐! 好了,文章到此为止了,如果你想了解一些其它的相关信息,请参考原文http://www.securereality.com.au/studyinscarlet.txt。 原作者: Shaun Clowes |
2022-07-29
2022-08-30
2022-08-17
2022-11-06
2022-08-18
请发表评论