3 ms·

> You drop a file in your public web server folder and you’re done. The implications of what this meant for security were very important too, but in a negative

> You drop a file in your public web server folder and you’re done. The implications of what this meant for security were very important too, but in a negative way. Instead of an application with a single or few small entry points (like CGI), you could just design your PHP app with a bunch of files spread across the exposed public directory structure, and for a long time this was the reigning paradigm for PHP. This, combined with the extension controlling whether it was processed as a PHP script or a plain text file meant that anyone making a quick and dirty backup of a file they were changing that didn't consider this would often end up exposing files to the public they didn't intend (mv config.php config.php.bak). Additionally, since most people were running on shared hosting platforms and PHP was usually run as the webserver user, and many applications were designed to be dropped entirely into a public web structure, any capability for writing locally (like allowing file uploads) often consisted of setting a directory world writable to drop files in. Even ignoring how often people screwed up setting permissions and set everything of theirs world writable, even when done correct this usually ended up being security through not-so-obscurity, since common apps had default locations they used more often than not (customizing that required more user interaction and knowledge to set up, which was against the ethos of "drop in and use" PHP heavily leaned on initially). PHP's ease of use was the ease of use of Windows 95 compared to Windows NT or Windows 2000. Sure, things are easier when you don't have to care about users and permissions and security. But you need to bootstrap any success you have into fixing those problems ASAP. PHP was always a victim of it's own success in this regard. The thing that made it easy to use for people was that it did away with a lot of the security concerns that were (barely) in place at that time, and the effects of that are what made it a nightmare for those managing it, and often at one point or another those using it as they were bitten by these problems. I'm glad we've all moved on from that. PHP did a lot to make it easier for people to do stuff online, and that in itself is a good thing and a laudable achievement. I'm unsure if it was a net gain though. It's too complex for me to easily say it was one, nor that it was definitively a net loss.

simon1ltd 5y ago
I'm not convinced that security is actually that much higher. I agree with your examples, but the complexity of most environments now is such that you almost have to know what you're doing in order to attempt to stay secure. How often do people leak things via S3 because they couldn't set the permissions properly? Same thing as you mention, except it's yet another layer that has to be maintained. I went from Perl to PHP, and my productivity definitely improved, and the speed of execution also improved significantly. mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that.
- kbenson 5y ago
  > How often do people leak things via S3 because they couldn't set the permissions properly? Same thing as you mention, except it's yet another layer that has to be maintained. I think the fact that it's another layer and not essential for anything is a pretty good reason why it's not necessarily the same. What I'm talking about is the default or minimal install complexity and how that affected what was to come. I'm not sure anyone considers S3 a default or minimal config for a website or code execution on the web. I do agree it's much easier to add complexity these days though, and there are plenty of resources that probably encourage it. > mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that. You didn't miss much. While mod_perl was first released within a year or two of the first version of PHP, it works in a fundamentally different way, as wasn't really suitable for shared hosting, so it was never going to have the same popularity. mod_perl keeps a perl interpreter persistent per Apache thread, but it doesn't (can't) really completely separate one request from the next, and given's the prevalence of globals that Perl lets you tweak that affect how many built-ins function (and the ability to redefine portions of the symbol table), it wasn't really suitable for shared environments, just for applications which were mostly the sole purpose of the webserver. In fact, the way it works is sort of to just take any file set to be handled by it, and eval the content of it in a sub (to deal with some scoping issues), and display the output. As you might imagine, this required special care to not accidentally create closures and pollute subsequent request handling with data in variables from prior requests.

simon1ltd 5y ago

I'm not convinced that security is actually that much higher. I agree with your examples, but the complexity of most environments now is such that you almost have to know what you're doing in order to attempt to stay secure. How often do people leak things via S3 because they couldn't set the permissions properly? Same thing as you mention, except it's yet another layer that has to be maintained. I went from Perl to PHP, and my productivity definitely improved, and the speed of execution also improved significantly. mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that.

kbenson 5y ago
> How often do people leak things via S3 because they couldn't set the permissions properly? Same thing as you mention, except it's yet another layer that has to be maintained. I think the fact that it's another layer and not essential for anything is a pretty good reason why it's not necessarily the same. What I'm talking about is the default or minimal install complexity and how that affected what was to come. I'm not sure anyone considers S3 a default or minimal config for a website or code execution on the web. I do agree it's much easier to add complexity these days though, and there are plenty of resources that probably encourage it. > mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that. You didn't miss much. While mod_perl was first released within a year or two of the first version of PHP, it works in a fundamentally different way, as wasn't really suitable for shared hosting, so it was never going to have the same popularity. mod_perl keeps a perl interpreter persistent per Apache thread, but it doesn't (can't) really completely separate one request from the next, and given's the prevalence of globals that Perl lets you tweak that affect how many built-ins function (and the ability to redefine portions of the symbol table), it wasn't really suitable for shared environments, just for applications which were mostly the sole purpose of the webserver. In fact, the way it works is sort of to just take any file set to be handled by it, and eval the content of it in a sub (to deal with some scoping issues), and display the output. As you might imagine, this required special care to not accidentally create closures and pollute subsequent request handling with data in variables from prior requests.