Comment by pseudosavant
7 hours ago
Is it just me, or is it the truly brave that decide to deploy and protect PHP instances? Especially if WordPress or Drupal are involve?
I finished moving the remainder of my stuff off of PHP and WordPress last year and haven't missed it at all. Backwards compatibility was typically pretty bad.
It seemed like maintaining existing working PHP code was always a cycle of: upgrade to newer PHP, that version has breaking changes, fix that code or update to a new WordPress (plus all of the plugins that would inevitably need updating too).
I don't really want to be in the WordPress world anymore (I still maintain a couple alas).
But this isn't about PHP code, really — this is about C code (with less-than-ideal exception handler patterns). This problem is more Heartbleed than WP vulnerability.
I quite like modern PHP, I don't really think it's necessarily any less secure (exception handler weirdness notwithstanding), and more to the point, I don't think not using it is any kind of automatic improvement in web app security. It's not like server-side JavaScript is intrinsically better.
I am certainly doing some thinking today; I switched off a couple of web servers so I didn't have to think about them while I was working on other stuff, and actually I think they might not get switched back on. But it's not so much that they are running PHP as that they were kind of neglected and it's always worth reconsidering what you need to keep around.
I think I have reached a point where low value stuff is not worth subsidising just for fun.
(I have also reached the point where in future I won't be using distro packages for PHP)
Other runtimes certainly have their vulnerabilities. It is just that it seems like PHP values backwards compatibility less than Node, Python, Java, or C#. It seems like there is better tooling for running mixed versions of Node or Python than what I've experiences with PHP.
And with the security fixes only landing on the relatively recent PHP versions, it means vulnerabilities force you into the PHP upgrade churn.
> It seems like there is better tooling for running mixed versions of Node or Python than what I've experiences with PHP.
Yeah — the solution on a single machine is either containers or very careful use of different FPM environments, which has tripped me up more than once.
I think most of my inconsequential stuff is simply going to get moved to commercial hosting; my biggest problem right now is an entrenched application that has custom compilation of a PHP build before 8.1.
In nearly every org I've been in or contracted to, the public landing page of the company gets a special place outside of any ops of general technical team, and is instead the work of a marketing group or a "creative" outsourcer who will default to Wordpress on PHP.
Seems like most main company sites at places I've worked. If you are lucky, that WP instance is a fully managed service where they proactively deal with keeping it on the latest PHP, WordPress, and plug-in versions.
We run on SiteGround, and they had the patch up about an hour or so after it dropped and auto upgraded us.
My shit on Wolfi, managed by ChainGuard, a “security company”, didn’t have a patch live hours later.
The funny thing is, people running Wordpress have dealt with 0 day bullshit so often that it’s basically a Tuesday for them, not even a big deal. So hilariously Wordpress folks have plenty of options here simply because it’s been a nasty attack vector for so long and these people are so used to dealing with horrific vulns like this that patching it is actually pretty trivial
This rings extremely true. The good part about it is, unless there's some kind of exceptional factor (e.g. the app.companyname . com cookie using a cookie scoped unwisely to companyname . com), they can go right ahead and do that and while they might get the corpsite homepage pwned and redirected to penis-pill scam sites or something, any truly dangerous actor who gets a foothold there can't do jack shit in terms of actually compromising your valuable data, getting source code, stealing app sessions, etc because that server is not just outside the VPC, it's in a completely different cloud account somewhere far away.
I’ve been to a few places like this and managed to get rid of the Wordpress infestation.
This is how it began and should stay, when IT teams started to get involved in this they ran heavy overhead and aren't clued in on creative requirements. Stick to keeping emails and erp servers up.