从代码级别上，也就是应用层次上考虑代码安全的话（也就是不考虑底层的语言本身等问题的漏洞），脚本安全问题就是函数和变量的问题。

一 前言 问题的存在
从代码级别上，也就是应用层次上考虑代码安全的话（也就是不考虑底层的语言本身等问题的漏洞），脚本安全问题就是函数和变量的问题。变量直接或者间接的接收用户不安全的的输入，由于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的内容释放出去做为全局变量，但是危险可能更大，后面会提到。