附录B:函数-php安全基础

在我写作本书的时候,http://php.net/quickref.php列出了共3917个函数,其中包括一些类似函数的语法结构,在此我不准备把它们从函数中区分开来,而是把它作为函数看待。
  由于函数数量很大,一一说明它们的正确及安全用法是不太可能的。在此我选出了我认为最需要注意的函数。选择的标准包括使用的频繁度、使用时的危险(安全)度及我本人的经验。
  对于每一个列出的函数,我都会提供推荐的使用方法。在提出这些方法时,我会把安全作为重点考虑。请在实际使用时根据你的需求进行相应调整。
  当一个函数与另一个有相同的风险时,我会给出参见另一个函数的信息,而不是多余地再次描述一遍。
B.1. eval( )
  eval( )函数用于对一个字符串以PHP语句方式解析运行。如:

  上例中会把$string作为PHP语句来运行,因此等价于:

  虽然eval( )非常有用,但是当使用了被污染数据时会非常危险。例如,在下例中,如果$name是被污染的,攻击者可以任意运行PHP代码:

  当你无法确信以PHP方式解释的字符串是否使用被污染数据时,以及在可能的情况下,我推荐你避免使用eval( )。在安全审查和同行评审中,应重点检查该函数。
B.2. exec( )
  第6章中已提到,执行shell命令是非常危险的操作,在构造shell命令时使用被污染数据会导致命令注入漏洞。
  尽量避免使用shell命令函数,但当你需要用它们时,请确信构造shell命令时只使用过滤及转义过的数据。

B.3. file( )
  file( )函数是我喜欢使用的读文件方法之一。它会读取文件的每一行作为返回数组的元素。特别方便的一点是,你不需要提供一个文件句柄——你提供文件名,它会为你做好一切:

  如果上面的文件有两行,则会产生类似如下的输出:

  使用file( )函数不是特别危险,但当你在allow_url_fopen选项打开的情况下使用时,它就能读取许多不同类型的资源如一个远程网站的内容:

  输出如下 (有删节):

  如果file()函数调用的文件名是由被污染数据构造的,则其内容也应被看成是被污染的。这是因为使用被污染数据构造文件名可能会导致你打开一个有恶意数据的远程网站。一旦你把数据保存在一个变量中,危险就大幅增加了:

  $tainted数组中的每个元素与$_POST[‘filename’]有相同的危险性——它是输入并必须要进行过滤。
  在这里,其行为有可能是意想不到的——$_POST[‘filename’]的误用可以改变file()函数的行为,因此它可以指向一个远程资源而不是本地文件。
B.4. file_get_contents( )
  参见 “file( ).”
B.5. fopen( )
  参见 “file( ).”
B.6. include
  如第5章所述,include在组织化与模块化的软件设计中被普遍使用,是非常有必要的。但是,不正确的使用include会造成一个重大的代码注入安全漏洞。
  在include语句中只使用已过滤数据是非常有必要的。在安全审查和同行评审中,应重点检查该函数。
B.7. passthru( )
  见”exec( ).”
B.8. phpinfo( )
  phpinfo( )会输出有关PHP信息的页面——运行的版本号,配置信息等等。由于phpinfo( )的输出提供了非常多的信息,我建议限制对任何使用该函数的资源的访问。
  如果你使用的第八章中的技巧来保护数据库验证信息,则需要确认访问者不能看到由phpinfo( )形成的输出信息,这是由于它会暴露超级全局数组$_SERVER的内容。
B.9. popen( )
  参见”exec( ).”
B.10. preg_replace( )
  preg_replace( )用于对符合正则表达式的字符串进行替换。在某些情况下,使用被污染数据构造正则表达式部分会非常危险,因为它的e修饰符会导致在替换时把用于替换的参数作为PHP代码来对待。例如(本例为译者所加):

会输出如下字串:
3def
  当使用了e修饰符,不管是否有意为之,它会带来与eval()相同的风险。在安全审查和同行评审中,应重点检查该函数。
B.11. proc_open( )
  参见 “exec( ).”
B.12. readfile( )
  参见 “file( ).”
B.13. require
  参见 “include.”
B.14. shell_exec( )
  参见 “exec( ).”
B.15. system( )
  参见 “exec( ).”

评论关闭

return top