← Back to context

Comment by redox99

6 hours ago

As long as PHP is written in C, it will be insecure.

It sounds cliche but yes, they should rewrite PHP in rust or other memory safe language.

As long as programmers trust 3rd-party-provided content-length input, it will be insecure. At this point, I'm not sure why we even use content-length anymore since you're going to need to size your buffers based on the actual content.

  • Because when file finishes you want to verify whether the size matches.

    And for non-malicious content, you can drop file above the upload max limit before user wastes time sending the file.

There should be more interpreters or runtimes. Regardless of the language they are written in. Indeed a rustPHP, maybe a JPHP, cPHP, etc etc. There is zend, but AFAIK that's still using the "official" PHP under the hood. And there is or was hiphop. Not sure how that is going, though.

Because now a vulnerability in PHP affects practically 100% of the users. But with more diversity, it would affect only a part. And if one runtime proves insecure more often than another one, organizations have a choice to move to an interpreter that better fits their security needs.

And, i don't understand why we are still using PHP. Agents can use Rust or go directly and we get benefit of performance...

  • Because like 30% of the websites in the world are on WordPress, and countless others in custom PHP? Not exactly a trivial task.

    • Claude please rewrite my entire WordPress site as an OCaml Mirage Unikernel that runs directly on bare metal, no Linux.

      I bet that takes a week at most.

      2 replies →

  • and the increased costs of maintenance of a code base that humans will be reluctant to read.

  • Because its way easier to verify LLM generated code for Laravel over some Rust project. Or do you just vibe it and dont look at code anymore?

I'm generally bullish on migrating C projects to Rust, but that will only reduce a particular class of vulnerabilities. There will still be other vulnerabilities which remain discoverable by LLMs, and for those, the problem of accelerated exploit creation will remain.

I'm really not sure how you mitigate this issue, other than serving static HTML and reducing the attack surface to cut out dependencies like PHP.