最近几天忙里偷闲, 一直在完善taint, 今天我觉得终于算做到了80%的满意了, 根据80:20原则, 我觉得可以做为一个里程碑的版本了 .

经过我实际测试, Taint-0.3.0能检测出实际的一些开源产品的(别问是什么)隐藏的XSS code漏洞, 并且这些漏洞如果要用静态分析工具去排查, 将会非常困难, 比如对于如下的例子:

<?php
   $name = $_GET["name"];
   $value = strval($_GET["tainted"]);

   echo $$name;

对于请求:

http://****.com/?name=value&tainted=xxx

静态分析工具, 往往无能为力, 而Taint却可以准确无误的爆出这类型问题.

之前, 小顿和我提过一个想法, 就是从PHP语言层面去分析,找出一些可能的XSS漏洞代码. 当时我一来没时间, 而来也确实不知道从何处下手..

直到上周的时候, 我看到了这个RFC: RFC:Taint.

但是这个RFC的问题在于, 它需要为PHP打Patch, 修改了PHP本身的数据结构, 这对于以后维护, 升级PHP来说, 很不方便, 也会有一些隐患.

虽然这样, 但这个RFC却给了我一个启发, 于是我就完成了这样的一个扩展:Taint Extension

还记得我之前说的PHP Hash Collisions Ddos漏洞吧? 最初的时候, 开发组给出的修复方案, 采用的是如果超过max_input_vars, 就报错(E_ERROR), 继而导致PHP出错结束. 而后来, 为了更加轻量级的解决这个问题, 我们又改善了一下, 变成了如果超过max_input_vars, 就发出警告(E_WARNING), 并且不再往目的数组添加, 但是流程继续. 然后我们发布了5.3.9.

这个新的修复方法初衷是好的, 但是却带来一个严重的问题(5.3.10中已经修复), 这个问题最初是由Stefan Esser发现的. 请看之前(5.3.9)最终的修复方案(php_register_variable_ex):

由我前面的俩篇文章介绍(通过构造Hash冲突实现各种语言的拒绝服务攻击, PHP数组的Hash冲突实例 ), 这个攻击方法危害很高, 攻击成本也很小. 一个台式机可以轻松搞垮数十台, 上百台服务器.

而和Pierre沟通后, 官方开发组不会为此发布PHP 5.2.18, 但是目前还是由不少公司还在使用5.2, 所以我特将dmitry为5.4写的patch, 分别apply到5.2上.

大家如果有用5.2的, 如果被此类攻击威胁, 可以打上下面的patch, PHP5.3的, 可以考虑升级到5.3.9, 已经包含了此patch(因为5.3.9目前是RC状态, 所以如果不愿意升级, 也可以参照这个patch自己为5.3写一个):

https://github.com/laruence/laruence.github.com/tree/master/php-5.2-max-input-vars

另外, 其他语言java, ruby等, 请各位也预先想好对策, 限制post_size是治标不治本的方法, 不过可以用来做临时解决方案.

thanks

在之前, 我曾经介绍过, 在PHP5.4中, PHP5.4中一个需要注意的变化(Chained string offsets) , 后续因为大多数人都表示这个变化很敏感, 容易成为坑.. 于是, 我们现在对此做了一些改进.

具体的改变是, 对于一个变量$a, 如果$a是一个字符串, 那么, 对于非数字型索引, 比如$a["foo"], 在isset的时候将返回false, empty返回true, 但是为了兼容已有的代码, 当你获取这个值的时候, 还是会返回$a[0], 不过会额外抛出一个警告信息. 比如:

<?php
$a = "laruence";
var_dump($a["foo"]) ; //PHP Warning:  Illegal string offset 'foo'
//output string(1) "l"

var_dump(isset($a["foo"]));
//false

var_dump(empty($a["foo"]));
//true

PHP是一种弱类型语言, 这样的特性, 必然要求有无缝透明的隐式类型转换, PHP内部使用zval来保存任意类型的数值, zval的结构如下(5.2为例):

…….

今天的话题, 我们只关注其中的俩个成员, lval和dval, 我们要意识到, long lval是随着编译器, OS的字长不同而不定长的, 它有可能是32bits或者64bits, 而double dval由IEEE 754规定, 是定长的, 一定是64bits.

请记住这一点, 造就了PHP的一些代码的”非平台无关性”. 我们接下来的讨论, 除了特别指明, 都是假设long为64bits

PHP的内存管理, 分为俩大部分, 第一部分是PHP自身的内存管理, 这部分主要的内容就是引用计数, 写时复制, 等等面向应用的层面的管理. 而第二部分就是今天我要介绍的, zend_alloc中描写的关于PHP自身的内存管理, 包括它是如何管理可用内存, 如何分配内存等.

另外, 为什么要写这个呢, 因为之前并没有任何资料来介绍PHP内存管理中使用的策略, 数据结构, 或者算法. 而在我们平时开发扩展, 修复PHP的bug的时候, 却对这一部分的知识需要有一个良好的理解. PHP开发组内的很多朋友也对这块不是很清楚, 所以我觉得有必要专门写一下.

一些基本的概念, 我就不赘述了, 因为看代码很容易能看懂, 我这里就主要介绍几个看代码没那么容易看懂的点, 为什么这么说呢, 呵呵, 我在写文章之前, 查找了下已有的资料, 已避免重复功, 其中看到了TIPI项目对这部分的描述, 发现其中错误很多. 所以, 我想这部分就是看代码也没那么容易看懂的点

在PHP5.4中, 根据由Rasmus提交的RFC, 引入了一套新的信号处理机制, 目的是为了使得信号屏蔽机制可以应用到任何SAPI中, 并且提高在这个过程中的PHP性能.

新的机制, 叫做zend signal, 它的理念, 来自Yahoo的”延迟信号处理”(Yahoo signal deferring mechanism), 而后, facebook把这套理念加入了PHP中, 为了提升PHP+Apache 1.X下PHP调用ap_block/ap_unblock的性能.

在详细介绍之前, 我想还是先介绍下引入这个新机制的背景

插播个消息, 今天, 我终于获得了Zend的编辑权限, Zend是PHP源代码中最为核心的部分, 也是最为敏感的地方, 对于这部分的权限控制的一直很严格. 但也是我加入PHP开发组以后, 一直想得到的权限.

好了, 言归正传, 今天对PHP5.4的Zend引擎做了一个改进, 改进了参数不兼容的报警信息. 具体的来说:

今天在bugs.php.net上, 有一个用QQ邮箱的用户发了一个问题(#55731).

他问, 为什么, 如下的代码, 会调用俩遍getter:

一开始, 我只是简单的回答了下, 和他在__get中再次获取$this->elmname有关系. 后来这个同学又要追问原因, 我只好用我那糟糕的英语给他解释.

可能用英语没太讲明白, 我现在用中文解释下吧.