While I get that your intentions are good, if your proxy has a vulnerability, it can be exploited. Many people use nginx as a proxy, and it has its own vulnerabilities that have been fixed over the years. You may have solved one problem while opening up another. Even those fronting services have their own vulnerabilities that have to be fixed.
If a system is accessible by someone else, it is inherently insecure and needs to be hardened.
It, at the very least, adds additional complexity to exploit your service by putting another layer between attackers and secrets / capabilities held by the application.
And in a case like this, with so many exploitable PHP boxes out there for attackers to choose from instead, certainly buys you some additional protection.
I wouldn’t choose to roll my own on the day I needed it though.
Relying on this patch, you're only protected against these specific CVes, but in general a proxy can protect you from more. It's strictly additive security, right?
And if you can't or won't patch your PHP, this is strictly better than getting pwned and having your PHP-FPM execute arbitrary commands. That's as bad as it gets, and you better hope that Linux user permissions can constrain it, but your apps are basically gone. PHP-FPM even allows PHP to overwrite .php files, meaning next time they are hit, it's completely arbitrary code that persists.
As a side note: https://qbixserver.com is a project I started several months ago, that is a pure PHP server without needing nginx, and it forks after loading your classes, instead of preforking like php-fpm. It's not vulnerable to php2shell, and it is able to rewrite php code on the fly when it loads it, to make it more safe. It does things like disallowing your php scripts to write to .php files, and it makes require($filename) check that $filename actually ends in .php ... a lot of stuff like that.
The security added by this proxy is strictly additive, it can't make things worse. This proxy can be run by a Linux user with no permissions at all, so it just transforms input. Can it have a sleeper code that transforms input in a way that causes your PHP to do something even worse? Well, this is why you should point Claude at the repo and ask it if it has any backdoors. It's completely open source and GitHub actions has been used to build the binary. So I guess if you don't trust GitHub, you can also compile it yourself, but then you're trusting GCC. (Ken Thompson has an interesting talk on Trusting Trust of compilers, from 30 years ago.) But at this point we're way past what people usually are concerned about.
Right. But it can’t, for several reasons:
1) The proxy is open source and much simpler than PHP runtime or a web application. Its code only takes input and generates output. It is basically a pipe. It has no other capabilities to exploit.
2) The operating system, such as BSD or Linux, supports running processes under a user and enforces limits on that user. So you just jail this proxy — since it has one purpose. Unlike your application, which may do many things and you can’t restrict it, it may become a confused deputy
How exactly is being open source supposed to protect it from memory safety issues? Even if you jail it, you still run the risk of the proxy leaking sensitive requests of other users…
> When do people understand that LLMs are no oracles. Just because some LLMs tell you the code is safe or has no backdoor doesn't mean it is true.
if it tells me there is a backdoor, and shows me how its used, i can be pretty sure that there is one though.
if claude cant find the backdoor, chances are that claude cant find a backdoor. its still not an oracle, but that is still useful feedback for updating priors
1) The proxy is open source and much simpler than PHP runtime or a web application. Its code only takes input and generates output. It is basically a pipe. It has no other capabilities to exploit.
2) The operating system, such as BSD or Linux, supports running processes under a user and enforces limits on that user. So you just jail this proxy — since it has one purpose. Unlike your application, which may do many things and you can’t restrict it, it may become a confused deputy
What this has taught me is that we should decouple as much as possible into microservices, so that we can properly sandbox each service, and that way we have chokepoints.
The inherent danger with a proxy is that you end up eventually with a rule that boils down to “if it got past the proxy it’s fine” - which is how things get broken open like an egg.
If a system is accessible by someone else, it is inherently insecure and needs to be hardened.