今日热议主题
正如我们前面讨论的那样，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程序的时候，为了区别代码库和主程序代码，一般是为代码库文件设置一个“.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()来验证。