Dmitry Stogov has published the patch on PHP-internals implementing the simple namespace model for PHP that I co-authored. I urge everybody to please take a look and discuss it - best on the internals list since the audience is bigger, but comments here are welcome too.

The main idea of the proposal is to attack one target and this target only - the Super_Long_Really_Annoying_Enormous_Class_Names that lately became the bane of big project developer. All other things are considered secondary to this goal - no attempt to make some different include model, packaging model, etc. This approach, in my opinion, allows to greatly simplify the concept and the mechanics involved. It allows to reduce most of the work to simple text transformation, without any need to create complex hierarchies with obscure rules.

Of course, there are some edge cases still, b

---

Linux World
at 2007-08-12 15:10:21

---

Misunderstanding JavaScript Hijacking
at 2007-08-12 15:10:20

Very recently there has been a new paper about what the authors call JavaScript Hijacking. It is about an analysis of several JavaScript frameworks for a cross domain data retrieval vulnerability through the usage of the <script> tag. The paper comes to the conclusion that in nearly all JavaScript frameworks that work with JSON encoded data, the data can be retrieved cross domain via the <script> tag.

While some might consider this news and others do not, the authors very clearly write in their paper that this kind of vulnerability is already discussed in several places. However some malicious bloggers (previous link was wrong) claim that Fortify claims to have found a new class of web-based attacks. Other bloggers, like Chris Shiflett Ed Finkler discusses Month Of PHP Bugs
at 2007-08-12 15:10:20

Today I learned about a podcast interview of Ed Finkler one of the members of the PHP Security Consortium. I heard through the first 30 minutes and was kinda bored because it was not really about PHP Security but about educating PHP developers, which is a subtopic of PHP Application Security which itself is a subtopic of PHP Security. I already wanted to switch it off when at around 34:32 they started talking about the Month of PHP Bugs.

Well knowing that Ed Finkler is one of the PHP Security Consortium it was absolutely no suprise that his response was lacking any substance and was only colored by anti Esser propaganda. I liked his comment that I am not worth being talked about. As usual for members of the PHP Security Consortium he wants to convince the audience that I am a bad person, with the argument that I throw the principles of responsible disclo

---

The PHP 5 challenge
at 2007-08-12 15:10:20

During the month of PHP bugs several people changed their credo from: "there are no vulnerabilities in PHP" to "vulnerabilities in PHP are not important, just tighten your OS". Other claimed that you can not rely on safe_mode and that you can always use shell_exec() to execute everything on the system.

It is quite amusing how the "safe_mode is flawed by design" green card is nowadays used to deny the seriousness of local PHP vulnerabilities. Just because safe_mode was a bad idea this does not automatically made disable_function a bad idea. And yes disable_function is nearly always used. Admins forbid the usage of all kind of functions like ini_get(), phpinfo(), shell_exec(), popen(), ...

So here comes the challenge. Imagine a PHP 5.2.2 server with ALL builtin functions being disabled. The challenge is to write PHP code that executes any binary inside the /bin directory. According

---