WooYun.org

先来看一个小测试

<?php


foreach($_GET as $k=>$v){


    $$k = $v;


}


if(isset($my_var)){


    echo $num."\n";


}


?>

然后用burp去跑

GET /test.php?my%§c§var=x&num=§x§ HTTP/1.1

payload是从00到ff

得到的结果是 20 2e 5b 5f 也就是 " " "." "[" "_"

除了_以外，空格 句号 方括号都能初始化my_var

再来做另外一个测试

<?php


var_dump($_GET);


?>

然后我们提交test.php?my.var=bar 或者?my[var=bar或者?my var=bar

可以看到返回都是一样的

array(1) {


  ["my_var"]=>


  string(3) "123"


}

从上面两个测试可以看到，key并不是在循环初始化的过程被换掉的。而是php在初始化接收key的时候 就把" " "." "[" 这三个含在超全局变量$_GET中的key的符号转成了"_"



事实上刚发现这个问题的时候，第一个想到的就是dede的全局变量注册机制，如果提交一个请求 x.php?.POST[xx]=xx 岂不是可以绕过dede的正则？后来做了第二个测试发现是想多了。在初始化的时候已经被替换成了"_" 所以经过正则的时候一样会被拦下来。



接下来还是说一下这个小特性是怎么造成安全影响的吧。

这个特性不光影响$_GET, $_POST和$_COOKIE也一样会转换。GET和POST不多说，在各种全局检查机制下很难找到利用的空间（也不是没有，不过不是这篇文章的重点）。

说说$_COOKIE,现在写代码的码农们，为了美观也好好记也好，一般都会用"_"去分割cookie中的单词

如乌云的wy_uid

phpwind的xxxxx_winduser

ecshop的ECS_ID

有这种方式命名重要cookie就会受到威胁

以乌云为例，如果我当前的cookie是这样的

wy_uid=x;wy_pwd=y;

wy_uid是httponly的，我不能用js去修改，但是我可以用js添加一个有效期为1年的wy.uid=z;

在请求乌云的时候 我完整的cookie就是

wy_uid=x;wy_pwd=y;wy.uid=z;

当然 这个时候还是没问题的，因为$_COOKIE['wy_uid']会取前面的那个，但是 乌云的cookie是有有效期的，等他有效期一过，重新setcookie的时候我的wy.uid=z就排到wy_uid的前面

这时候再请求乌云 乌云拿的wy_uid就是z了，z无法通过乌云的检查逻辑，就会注销当前账号的session。就算乌云会删除wy_uid这个cookie（测试看来是没有）。也不会把我们的wy.uid删掉。这个cookie会一直在最前面，账号就再也无法登录了。这就是所谓的“永久”DOS。



再如ecshop ecshop的权限检查就靠一个ECS_ID,应该叫sessionid吧，这个地方ecshop存在Session Fixation（刺总翻译：Session 完成攻击 链接：http://**.**.**.**/aullik5/item/e1a17560d073612369105bd5）的问题。登录后没有重新设置session(ECS_ID)而是在当前session(ECS_ID)设置用户信息。如果我给你提前设置（或者设置完了等你原先的session超时）一个ECS.ID。你就会一直用这个ECS_ID用到死。

setcookie ECS_ID改不了本地的ECS.ID。而ECS.ID有效期又非常长。只要你一登陆 我就能拿着这个ECS.ID访问网站获取你的所有权限。



以上两种只是简单的说明一下这个问题的危害，其实还有很多攻击方法比如去流量大的地方给所有访问的人设置一个返利网的cookie，去渗透目标常访问的网站挖个坑坐等目标上门种下rootkit（水坑攻击）等等等等。



问题的局限在于我得能设置目标域的cookie（比如一个xss），所以这个漏洞绝大多数厂商可以理直气壮的无影响忽略。这个就不在本文讨论之内了，仁者见仁吧。