Upcoming article series regarding security - some thoughts

First of all: while researching for my upcoming articles, I stumbled upon the book “Pro PHP Security” by Chris Snyder. From what I can see on Google Books, it looks like a very comprehensive in-depth look at some of the stuff that I will present in my series, too. I just ordered it but I doubt I will use any of the stuff, just because I have my own idea in my head and I don’t want to spoil it. This is also meant as a disclaimer: I am not going to copy from “Pro PHP Security”. However, the TOC reads like it’s an extremely interesting book. So, if you want a PHP security book, go buy this one. If you’re german, however, buy my book. But that goes without saying.

The few of you that followed my doings during the last odd two years will have found that at some point in time, I more or less retired from the PHP security field. This was mainly due to the fact that pursuing a career in that field would have interfered with my plans for life (especially attaining a PhD before I’m too old and satisfied with life).

Another point was that I could not quite see my place in PHP security. The “common” topics like XSS, CSRF, SQL Injection, RFI, you name it, are surely important and need to be put into new users’ heads, but I can’t see myself jetting back and forth giving people the same training course over and over. There is relatively few innovation potential in these security topics and I even foresee that the hype for “Web 2.0 vulnerabilities” that is currently on a wild rampage through blogs, “security expert” columns and other media is going to decline extremly fast. After all, it’s just the same shit with a different presentation layer. Of course, XSS becomes more dangerous when dealing with AJAX applications, nobody in their sane minds would claim otherwise. However, it’s still the same boring security bug, it’s still fixable with the same boring htmlentities() or whatnot and generally, I could care less.

Actually, I’ve always been more interested in the administrative side - getting a secure mod_php, keeping all those script kids outside and trying to get it all to run as smoothly as possible on an open platform while maintaining compatibility. On my own hosting platform, I’ve had limited success - partly due to the amount of trust I put in my end users, an attitude that ultimately backfired. It always backfires to trust end users in any way. With stuff like Suhosin, mod_security, but also Apparmor etc. we add layer upon layer of security in front of our PHP applications and things get very technical, very unwieldy and very boring quickly. It’s a job that has to be done, but not necessarily a job you want to keep writing and talking about. Believe me, spending a day teaching a seminar group how to compile, deploy and configure a hardened PHP installation is not an extremely funny task, although I very much enjoy teaching people some of my meagre knowledge. I regularly do this job though, and it’s just very tiring to see yet another R57shell or however they’re called and cleaning up after the mess someone else made.

During writing of my master’s thesis, I learned a lot about the beauty of X.509 based PKIs and I really like the general idea. However, it’s still relatively scarcely implemented in the PHP world. As an effort to combine my current profession (which is mainly related to Grid Computing, has nothing to do whatsoever with PHP and relies heavily on in-depth knowledge about PKI in general and OpenSSL in detail), I’m putting only this upcoming series of postings.

My plan is (and this is very much a braindump for me as well as a preview for you readers) to give you a how-to for your complete corporate PKI that is as scalable as it can be while being as secure as possible in a no-budget environment. This should be a rather holistic approach that includes all kinds of information, not only PHP. However, PHP will be crucial to some of the components, but if you’re rather the Python/Perl/java type, there’s an SSL API for most of these languages too...
I plan on first giving you an overview how you can implement PKI in your organization and how different departments and roles should be designed. Then, the goal is to tell you how to set up your own CA and operate it in a convenient, yet rather secure manner (using PHP), how to give end-users an opportunity to request certificates and how to issue those certificates. I’ll try to keep this stuff as practical as possible, but also go a bit into detail how “real” CAs do things, what caveats you might want to beware of and so on.

Then, I’ll review the part that is currently online and actually the last part of the article series. Don’t ask me why I’m putting the cart before the horse, but I felt that this topic was interesting enough to merit immediate attention. I’ll try to get plugins for some common software that I’m using to work (like maybe phpMyAdmin, Serendipity, Typo3 etc.) and show you how you can benefit from the quasi-single-sign-on that PKI logins give you.

So much for my plan - I’ll try to have the first article online mid-June.