3 ms·

Speaking as someone who has pentested a few PHP codebases over the years, rather than as a developer, It's a bit like C. That is, it's an absolute footgun in th

Speaking as someone who has pentested a few PHP codebases over the years, rather than as a developer, It's a bit like C. That is, it's an absolute footgun in the wrong hands, and a lesser footgun in experienced hands. For experienced devs following best practices and using modern frameworks it's "mostly fine", and that's the side of things that's been improved over the years, but most of the old rakes are still there to be stood on.

wvenable 3y ago
> but most of the old rakes are still there to be stood on. I don't think that's necessarily true -- a lot of features have been deprecated and removed.
- kemayo 3y ago
  Most notably, in 5.4.0 (in 2012!) they removed register_globals and magic_quotes. (Which had both been deprecated and off-by-default for a while before, I believe.) The former was notoriously insecure, as what it did was promote anything passed in as a cookie, GET, or POST variable into a global-scoped variable inside your script. Since PHP didn't require any sort of declaring-your-variables-before-using-them, it was pretty easy to wind up with scripts written in a way that would allow this an unwise amount of access to the script's internals. The latter automatically escaped special characters with backslashes in all the aforementioned user-provided variables so you could pass them straight into mysql queries. It was, however, optional and so caused errors because code got written relying on it and then ran on servers with it disabled, allowing SQL injection attacks... or double-escaping things in code written the other way around. But these days are long behind us!
lucb1e 3y ago
Also a pentester here. I find C and PHP to be quite different. Somehow, C applications always have catastrophic issues pop up, sooner or later, where you can make it execute random code at least under some circumstances. PHP applications can be the same if the team is inexperienced or doesn't get the necessary time to apply best practices, but I've also seen plenty of PHP applications where we didn't find significant issues with the server-side aspects. PHP applications are fun to test because most teams found another set of solutions to the same problems (it has so much history that wheels have been reinvented a lot), so you get to see new things. They're also typically larger than newer and new-style services written in a shiny new language, which haven't had time to accumulate as many features and are often written as a microservice (smaller components where one/each dev can know all the ins and outs, allowing to have a total overview so that security controls can much more easily be implemented in a unified way).

wvenable 3y ago

> but most of the old rakes are still there to be stood on. I don't think that's necessarily true -- a lot of features have been deprecated and removed.

kemayo 3y ago
Most notably, in 5.4.0 (in 2012!) they removed register_globals and magic_quotes. (Which had both been deprecated and off-by-default for a while before, I believe.) The former was notoriously insecure, as what it did was promote anything passed in as a cookie, GET, or POST variable into a global-scoped variable inside your script. Since PHP didn't require any sort of declaring-your-variables-before-using-them, it was pretty easy to wind up with scripts written in a way that would allow this an unwise amount of access to the script's internals. The latter automatically escaped special characters with backslashes in all the aforementioned user-provided variables so you could pass them straight into mysql queries. It was, however, optional and so caused errors because code got written relying on it and then ran on servers with it disabled, allowing SQL injection attacks... or double-escaping things in code written the other way around. But these days are long behind us!

lucb1e 3y ago

Also a pentester here. I find C and PHP to be quite different. Somehow, C applications always have catastrophic issues pop up, sooner or later, where you can make it execute random code at least under some circumstances. PHP applications can be the same if the team is inexperienced or doesn't get the necessary time to apply best practices, but I've also seen plenty of PHP applications where we didn't find significant issues with the server-side aspects. PHP applications are fun to test because most teams found another set of solutions to the same problems (it has so much history that wheels have been reinvented a lot), so you get to see new things. They're also typically larger than newer and new-style services written in a shiny new language, which haven't had time to accumulate as many features and are often written as a microservice (smaller components where one/each dev can know all the ins and outs, allowing to have a total overview so that security controls can much more easily be implemented in a unified way).