PHP, Zend Framework and Other Crazy Stuff
Zend Framework
Mockery 0.7.0-beta Released!
Feb 28th
It’s been a long, tortuous and busy four months here, so it’s nice to be back in action on the open source front where I can write code, make bad jokes on my blog, and be a smartass on IRC once again. Before I vanished into the mists of obscurity for a few months, I was writing a set of security related articles. Those published so far have been very well received and are currently my most popular articles. They have, hopefully, offered food for thought in areas where other PHP related security related articles tend not to tread. Otherwise they have failed in their purpose miserably
. The next article in the set should land in the next week or so with another unexpected plotline (and a nascent conspiracy to delude the masses – it’s a running theme).
These past two weeks, as I eased back into PHP work, I’ve focused on one of my recently neglected babies: Mockery. For those who aren’t aware, Mockery is my take on a PHP Mock Object framework (yes, it works with PHPUnit!) that draws inspiration from outside PHP. I’d mention the R word but some PHP folk get really upset when you also spell the “uby” part
.
Mockery 0.7 follows the Mockery 0.6.x series of releases which were my initial release versions. Here’s a quick list of what Mockery 0.7 Beta includes over 0.6 in terms of fixes and new additions:
1. Fixed a bug where mocking some classes failed (e.g. SplFileObject).
2. Fixed a bug mocking classes which include methods with parameters passed by reference.
3. Fixed a bug where mocking a class containing a __wakeup() method failed.
4. Fixed an exception throw on partial mocking of objects containing __call().
5. Added support for mocking public properties (and setting property values from expectations).
6. Added support for mocking static methods.
7. Added support for having mocks implement two or more interfaces.
8. Added support for forward blocking.
9. Added support for instance mocking, i.e. where instantiating a new class of a mocked type will provide a new mock object.
10. Included integration support for Hamcrest (a library of matchers to extend/offer an alternative to Mockery’s).
While this is a short list, it rounds out Mockery’s feature list and fixes a few obvious flaws. I’d like to thank everyone who opened issues on Github or who took the time to fork the project and implement changes. I’m going to need a CREDITS file for the stable release of 0.7
.
One of the features noted is strongly recommended: Hamcrest. Hamcrest is a library of matchers ported to PHP 5.2 from Java (it’s also ported to Python, Erlang, and so on). Mockery offers a set of argument matchers used in expectation setting but their scope is necessarily limited and it’s pointless throwing more time into developing new ones when there exists a perfectly functional library for that very purpose. I’ve updated Mockery’s installation instructions to note this new optional dependency and recommend its installation.
Going forward, I’ll post a few Mockery related articles before releasing 0.7.0 Stable in about a week. If you currently use Mockery, please give the 0.7 Beta a run through to make sure nothing breaks in your tests.
Mockery’s primary documentation is currently its online README on Github. Installation instructions and usage documentation may be found there.
Nanosecond Scale Remote Timing Attacks On PHP Applications: Time To Take Them Seriously?
Oct 20th
This article concerns the concept of a Timing Attack (described below) performed remotely over the internet or a local area network. Specifically, it addresses Remote Timing Attacks based on timing differences from a few microseconds to as little as 1 nanosecond (one billionth of a second), a timescale which has been assumed to be impossible to detect over the internet due to the interference of “network jitter”. In the article, I will be summarising some of the recent developments in the area with the goal of demonstrating that a dependence on network jitter as a defence is not sustainable and that PHP applications need to come to terms with these forms of attacks while they are still in their infancy.
I’ve been following the progress of Remote Timing Attacks with a lot of interest over the years, during which time there has been an obvious trend in improving the technique. The most recent reported cases of Remote Timing Attack vulnerabilities, for example, were against the OpenID and OAuth protocols when it was reported in July 2010 that numerous open source implementations of these protocols did not prevent the disclosure of timing information that could enable a Remote Timing Attack. It is important to note that, as with many potential attacks, the protocols themselves contain no vulnerability. This is strictly a potential vulnerability contingent on the method of implementation.

