Okay, I love to rant, so what?
Just the other day I have complained about Rails’s suggestion for world-writable logs and solved it by making it use syslog and now I’m in front of another situation that makes me think that people still don’t know how to stop themselves from creating software that is pretty much insecure by design.
So what’s up? For a customer of mine I ended up having to install a full LAMP stack, rather than my usual LAPR. In particular, this is for a website that will have to run WordPress. Thankfully, I have ModSecurity to help me out, especially since not even two hours after actually setting up the instance, Spiderlabs announced two more security issues including an extract of their commercial rules.
Anyway, the WordPress instance will have to be managed/administered by a friend of mine, who has already had some trouble before with a different hoster, where the whole WordPress instance was injected with tons of malware, so was quite keen on letting me harden the security as much as I could… the problem here is that it seems like there’s not much that I can!
The first problem is that I don’t have a clean way to convert the admin section to forced SSL: not only wp-login.php is outside of the admin subdirectory, but most of WordPress seem to use fully qualified, absolute URIs rather than relative URLs — such as the ones I’m used with Rails, which in the case both of Typo and Radiant let me restrict the admin/ directory to SSL quite easily. Why is that so important to me? Because I would have used an admin URL outside of the website’s domain for SSL: I don’t own a certificate for the website’s domain, which is not mine, nor I want to add it to the list of aliases of my own box. Oh well for now they’ll live with the “invalid certificate” warning.
Next stop is updating the webapp itself; I was sure at that point that “updating the webapp” meant letting the web server write to the wordpress deployment directory… yes, but that’s just part of it. As it happens, plugins are updated via FTP, like my friend told me.. but not in the sense of “downloaded from an FTP website and written to the filesystem” but the other way around: you have to tell WordPress how to access its own deployment via FTP. In a clear-text web form. Admittedly, it supports FTPS, but it’s still not very funny.
I’m unsure if it was a good idea on my part to accept hosting WordPress: we’re talking about installing MySQL, PHP, vsftpd and enabling one more service on the box (vsftp) just to get a blogging platform. Comparatively, Rails look like a lightweight approach.
Helped my fiancee set up a WP install on her own VPS. I have the firewall locked down as tight as I can. (And, I guess I’ll admit it, I’m getting interested in your mod_security work, after seeing some souhosin lines in my logs on rosettacode.org.)I have ftp blocked on the public interface. It’s sufficient for WP to be able to access it via the loopback interface. Conveniently, I was able to bang things mostly together using the Debian distro’s packages, which keeps her and myself from having to do manual updates and upgrades, but I still want to bang things a bit more so that plugin installation only modifies files accessible by the web server and the user in question.
Hi Flameeyes, why do you love so much the rails framework if there’s always something wrong with it, and the ruby stack with all its problems with interfaces, versions and releases and 0 retro-compatibility?
I don’t like the Rails framework, but I despise other stuff much more. As I thought I expressed well enough in my post, Rails with all its defects is still better that anything else I’ve seen out there lately…
You don’t need the FTP trick anymore for WordPress.Unless your PHP user is not the same as the user owning the WordPress files. You should look into PHP-FPM if you want to have better isolation (an user per PHP project or so).But I agree, web developers usually don’t get security, even the basic ones like UNIX permissions. They tend to “fix” things by allowing everything for anyone.