《php代码审计》.pdf

一 前言 问题的存在 从代码级别上，也就是应用层次上考虑代码安全的话（也就是不考虑底层的语言本身等 问题的漏洞），脚本安全问题就是函数和变量的问题。变量直接或者间接的接收用户不安全 的的输入，由于php 本身的特性，在php 中更容易发现这种变量的混乱（很多php 程序都用 来定义以及初始化以及接收变量，可以直接在程序中使用$id 这样的变量，初始化完全由php 的设置来完成，如果稍不注意，就可能导致变量的混乱从而导致攻击）。 变量接收不安全的输入之后，没有做恰当的过滤又用在不同的地方，就可能造成不同的 危害。如果直接进入数据库然后显示给用户就会导致跨站脚本攻击，如果用在 sql语句中就 可能导致Sql 注射攻击，这几种攻击都是是与具体的脚本语言无关的，在各种脚本语言里都 可能存在。由于php 的变量很灵活，这些有害的变量如果用在一些逻辑语句中，就会导致关 键代码的跳过如身份验证失败和跳过一些变量的初始化从而导致程序逻辑混乱而产生其他 漏洞。如果这个变量用在了危险的函数如include 等等当中，当然就会出现文件包含漏洞， 出现在fopen函数里就会可能产生写文件的漏洞，出现在mysql_query 函数中就是 Sql注射 漏洞，eval 以及preg_replace 中可能导致代码的执行，出现在htmlspecia 函数中可能导致出 错而绝对路径泄露 变量出现的环境决定了它可能的危害。 思考了问题的存在，那么如何从代码级别上检查这种漏洞呢？当然熟悉熟悉php 语言是 最基本的，也应该是抓住函数和变量，危险的函数里如果有变量那么请确定这个变量的来源， 是否正确的初始化，初始化之后是否能被用户注入敏感字符，在进入函数前这些敏感的字符 是否得到了彻底的清除。对于代码审核工作的难点可能就在于对变量来源的确定，这需要对 php特性以及你所审核的代码的熟悉，但也并不是所有的变量的来源都清晰可见，可能一些 初始化的代码并没有像想象中运行，一些变量里的东西可能也来自于你并不想他来的地方， 还有一些变量可能来自于数据库或者系统的配置文件，但是很可能数据库和配置文件在之前 就已经被修改，或者在后面不安全的操作了这些变量，这些变量也是不可相信的。下面我们 就按照变量与函数的思路来思考脚本代码的安全。 二 变量来自哪里？ 1 显示的输入 叫变量来自哪里其实也就是说威胁来自哪里，只是从web上考虑的话，什么样的网站 最安全？很明显，那些只提供静态Html 页面的网站是最安全的，因为这样的网站不与浏览 者进行任何交互，就好比打劫一个密不透风的银行，很难实现，但是对于一个大的论坛或者 脚本程序就不一样了，你登陆的时候需要传递用户名和密码这些变量给服务器，甚至包括你 登陆的Ip与浏览器等等都是程序抓取的对象，抓取一次与服务器交互的过程如发表帖子等 等你就发现浏览器与服务器之间进行的数据传输，你可能看得见的包括提交的表单，地址栏 参数等等，你看不见的包括Cookie，Http 头都是提交数据也就是变量的地方。这些地方也 是服务器处理数据最原始的入口。那么php 程序是如何接受变量的呢？所有提交的变量都被 php保存在了一些数组里，包括 $_GET $_POST $_COOKIE $_FILES $_SERVER 为了最初的方便与灵活，在php 的设置里有这么个选项 register_globals 当这个选项为on的时候，上面出现的那些变量都会成为$GLOBALS 中的一员，在脚本中都 不需要再取得就可以直接使用，并且以 variables_order 的顺序覆盖。很多程序考虑到了register_globals 为off的情况，于是在程序初始化的时候使 用如下的代码： @extract(daddslashes($_POST)); @extract(daddslashes($_GET)); 这些代码起到了register_globals 的作用，作用也是将POST和GET 的内容释放出去做为全 局变量，但是危险可能更大，后面会提到。 2 隐式的输入 上面这些是最原始的，没有经过程序转换的数据，程序很多地方用到的变量都来自这里， 但也不表示其他的地方没有变量传递过来，下面有一个数据传递的模式： 用户传递的数据===========数据库=========== 程序代码处理=======程序代码 这个模式的意思是用户的输入可能先进入了数据库，然后程序从数据库再取得这个输入 送入某些危险的函数执行，一般的程序员都会有一个意识认为从数