Comment by dhx
15 hours ago
I'm not seeing any discussion here about woeful web application architectures from the 1990s still in use?
The single biggest problem I came across over a decade ago when maintaining an open source PHP web application was web applications at the time typically having access to a common database server role (often also common between users and administrators) which allowed a web application process to read and sometimes write to the entire database. No use of user-specific roles in database servers and row-level-security/column-level-security authorisation. At the time I don't think PostgreSQL even had row-level-security support built into it. A runaway PHP process could return the entire database to the attacker, or change every single row of data held within the database.
The second biggest and related problem was web applications accepting files uploaded from users, or having to generate reports (maybe with external software) and save them to disk for a user to download, and not being able to ensure a runaway PHP process can't just dump all of those files or reports to an attacker. You might have been able to store the user files (or at least a decryption key for the files) in a database but then you're back to dealing with problem (1) above.
Even a decade ago it was fairly common for web application developers (of the PHP sorts too) to be well aware of the need to make their web root read-only, put the web application source code into a read-only directory outside the web root, execute interpreters such as PHP with "nobody"-like permissions, launch a new interpreter process for each connection (not multiple threads within the same process), firewall off the server the web application sits on so a runaway PHP process can't connect to internal servers, etc. Outside of an attacker messing with a database, most other aspects of PHP web applications at the time were immutable if the web application developer / system administrator had setup the environment correctly.
Is there a solution for (1) and (2) for PHP web application development that has become popular in the proceeding decade?
edit: also nominating the shared $_SESSION state of PHP that was typical a decade ago to just be left to default (e.g. all PHP processes just read/write session files to a common /tmp directory). https://www.php.net/manual/en/function.session-set-save-hand... should probably instead be used by web application developers to somehow better isolate session state between users.
As far as I can tell none of this is related to the current vulnerability in PHP itself. Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
A dynamic language having access to all of the files it has access to is not unique to PHP. Vulnerabilities are not unique to PHP, and I doubt the Dutch National Cyber Security Center took their website offline because they lack user-specific roles in the database: https://www.ncsc.nl/index-en.html
So maybe save your elitism for a day when so many of us aren't already putting out fires? Congratulations on not being part of the 75% of the internet affected.
PHP is definitely more at risk of this class of vulnerability because fatal errors are longjmps which skip resource clean-ups. In a runtime with real unwinding, this exploit class can't exist.
you could just use a MAC-framework? like recommended for years...
> Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
Vulnerable but perhaps with no impact. If you've setup your web server well, the vulnerable PHP process is sandboxed, at least to some degree, and an attacker executing their own code within the compromised PHP process can't move laterally through your internal networks, write files to disk, read files from disk, etc because you've locked down the PHP process.
In 2026, perhaps it's possible to:
1. Use systemd socket activation with Accept=yes [1] and strict sandboxing applied to a systemd service that executes the PHP interpreter. The result being each incoming request is dealt with inside an isolated PHP process spawned specifically to handle the request. Compromise of a PHP process doesn't impact any other concurrent requests, or any future requests, except through defined sandbox interfaces such as access to a database server socket.
2. For each user of the web application (perhaps including an 'anonymous' user too if anonymous users have access to dynamic content), if using PostgreSQL, create a role in PostgreSQL for each web application user. Then use row-level-security permissions and security barrier views within the database, and have the PHP process accept credentials from the user which are then needed to be passed through to PostgreSQL to login as that individual user.
It's not without some significant downsides:
1. It's complex and you might be the only person in the world trying to use PHP in this secure way. And if you're going this far, for a complex web application, it'd be best to split it into smaller web applications each with their own systemd service defining specific sandboxing constraints. E.g. microservice architecture where "login", "file upload", "user administration" are all separated with different sandboxing constraints applied to each.
2. Performance will suffer and you'll need more resources--for spawning new PHP processes from scratch for each request (although this is already the case with php-fpm which is most widely used), and for dealing with row-level-security in PostgreSQL (see e.g. LEAKPROOF functions).
The more common pattern I've come across on public websites in recent times that might mirror some of the above is client-side JavaScript dynamic rendering with API calls to a GraphQL database exposed on the Internet (using e.g. field-level access control). The user isolation problem is essentially pushed from PHP+PostgreSQL to a GraphQL implementation.
[1] https://www.freedesktop.org/software/systemd/man/latest/syst...
It's not elitism to call out bad practices
The bad practices mentioned in GP have nothing to do with this vulnerability
1 reply →
This.
The one gripe I'll have is that rowlevel security is slow and messy to use. If a design allows skipping it, it should be skipped.
PHP has been the worst thing to happen to the web. It was insecure many decades ago and still is. Even CGI with C is probably more secure, never mind technologies like Java, ASP.NET and Rust with are far more secure.
I even have a preference for web stores which use ASP.NET or Java since I know my personal information are safe there.
There are probably thousands of web stores using PHP unwittingly too. I've noticed only about half of them have been taken offline.