Hi Jürgen, On Wed, Aug 14, 2013 at 11:26 PM, Jürgen Pabel <[email protected]> wrote:
> An introduction/overview to my extension can be found online: > > http://programm.froscon.de/2012/system/attachments/202/original/2012-08-26%20-%20FrOsCon%20-%20php-ssds.pdf > > Key idioms while implementing this extension were simplicity for > deploying administrators and runtime compatibility: configuration is > easy and PHP applications must not be modified. All session storage > backends (save_handler's) are automatically supported. > > My current release is just a few minutes old and should meet all > requirements for PHP extensions (that I am aware of, at least). In > addition, the implementation has been source-code audited by several > experts and no weaknesses have been found. I consider it to be > production-ready. > Thanks for your work, from a quick read-through the code looks nice and clean, however I think there's at least a couple of issues: - It relies on the proxied session module behaving nicely when called in an unexpected manner which may happen given the extra logic your module imposes, e.g. close before read. Do you have tests for this kind of situation? How about user session handlers? - In your paper you say that the IV is computed as hash[iv_hash](concat(NOW,SESSION-ID)) to avoid draining the PRNG, but when for example the proxied session module is the files module, NOW is ~ the file ctime and SESSION-ID is the file basename, so unless I'm misunderstanding something, the IV is trivially known by your hypothetical attacker with access to the file system. Regards, Arpad
