I want you for Autoptimize 1.7.0 (and beyond)!

I started work on Autoptimize 1.7.0, working my way through this feature list:

  • update CSS & JS optimization components to most recent versions
  • add CSS exclusion
  • remove legacy CDN & YUI support, replacing CDN with something simpler
  • clear cache of w3tc, hypercache, fast cache, faster cache, … when flushing AO cache
  • better layout of the admin-page
  • update translations

The goal is to release a first test-version in October (maybe as early as next week, things are progressing pretty well) and to push the final version (which might include one extra feature which could be kind of a killer one) out in November.
So why do I need help?

  1. For testing the subsequent “beta”-releases (based on trunk)
  2. To provide translations (based on a POT-file, using a gettext-compatible tool).

If you’re interested to help on this release (or, more in general, would like to support other users or co-develop future releases) hop to this wordpress.org support forum thread and give us a shout-out.
[cross-posted from Autoptimize support forum on wordpress.org]

Dude, where’s my WordPress session?

WordPress is a favourite hackers target. Some say that is because it is inherently insecure, but in reality WordPress is mainly a target because of its popularity, because of people not keeping their installations up to date or using easy to guess usernames and passwords and because of vulnerabilities in plugins rather then WordPress itself.
There is, however, one security-related shortcoming in WordPress from a design point of view: sessions are not stored server-side. If someone logs in, a cookie is set in the browser containing username, a session expiration timestamp and a hash. With every new request to WordPress that cookie (and specifically the hash) is checked to validate the session, but there is no check to see if there indeed was such a session.
This can be considered mainly a theoretical shortcoming, not an immediately exploitable vulnerability, because;

  1. session-cookies are set with the HTTPOnly-flag so XSS should not be an issue
  2. in an ideal world all traffic, once logged in, would be over HTTPS, securing against network sniffing.

But there are other (albeit less obvious) ways to steal cookies or even create create new ones to gain unauthorized access, as demonstrated in this very detailed blogpost. As explained in that article, there is no way to block “fake” session-cookies from gaining access (your OTP plugin won’t protect you either) and there is no functionality to monitor and if needed delete sessions.
So … I wrote a small proof-of-concept plugin that gets triggered upon login, logout and upon session verification (i.e. each request) and which stores sessions server-side, automatically logging out unknown sessions. With that in place, lots of other optional features could easily be added;

  • display a list of all known current sessions
  • allow one or more sessions to be removed
  • compare IP address at session verification against the one at session creation and notify or logout if no match
  • compare User Agent (and optionally some HTTP accept-headers) at session verification against the one at session creation and notify or logout if no match
  • create an audit log

But … I don’t want to do this on my own. I have 3 plugins already, 2 of which are semi-popular and for which I try to do regular releases and provide great support (and I have a daytime-job and a wife and daughter with whom I love to spend quality time as well). Moreover I really don’t want the plugin to “just” be open source, but I want it to be developed in an open source, collaborative manner as well.
So if you’re a WordPress coder, a security consultant or just an innocent passer-by and you are willing to code, review code, translate or document, then do drop me a line. Fame (but not fortune) will be yours!