I used to manage a fleet of cPanel servers years back, they were a pain to manage as users would regularly get infected on their local machines and have HTML infected with malicious javascript. We used a bunch of tools like clamav/configserver etc to keep on top of it but it was definitely whack-a-mole. Even with inotify style job triggers to check the newly uploaded content.
I set up a virtual guestbook for my daughter's birthday party last year on a cPanel-based hosting system. Couldn't for the life of me figure out why the damned thing wasn't working until I discovered that the admin had gone ahead and disabled my link "guestbook.cgi" since it was a common cPanel attack point. Apparently cPanel comes with a hackable default guest book of its own.
They use php-fpm pools where each website gets it's own uid:gid and the php process runs as that user. Then standard linux file permissions so you can only access your own uid files. To access web assets from nginx/apache, they add file permissions wich standard Linux acls.
Altough not fancy, the security model is actually quite mature. Security problems in these servers come from misconfigured permissions and scripts, not the security stack.
Sure, but there's nothing inherent to the language that fueled that. They could have done that with Python, for example.
Rather, it was popular software like bulletin boards and blogging platforms that built the demand. PHP used to have one of the lowest barriers to entry because you could get by with plain HTML and incrementally add business logic inline.
> Sure, but there's nothing inherent to the language that fueled that. They could have done that with Python, for example.
Not quite true. With shared hosting it was (is?) uncommon for a user directory to have ExecCGI enabled. If you wanted scripts to run they had to live in the cgi-bin directory. Additionally mod_rewrite could be expensive on low powered servers. This all meant doing anything dynamic meant "ugly" URLs and meta tag forwards if you were on such a shared host. It was also non-trivial amounts of effort to get some random CGI script working since you needed to know enough to get the shebang path correct for the server and set the right permissions.
Contrast this to PHP where you dropped a .php file into your user directory and you've got some dynamic content. Platforms built on PHP became popular because you could upload them to your user folder and they just sort of worked. There were no special executable paths, no shebangs, and no execute permissions to set.
Perl was huge in the CGI space for a long time but the (consumer) content platforms built on it weren't nearly as successful because of the difficulty of mere mortals getting them running on their shared hosting plans.
Not really; PHP had many features to make this easier; for example "safe_mode" and "open_basedir". These are not easily replicated in a stock Python by just "flicking a switch", even today (although the need for that today is a lot less than it was in 2000, and PHP even removed safe_mode). Not that these measures were perfect, but they were mostly "good enough".
There was a reason that in ~2000-2005 you could find PHP shared hosts for $1/$2 month, and that Python/Perl/etc. shared hosts were much harder to find and more expensive. People started using PHP bulletin boards and blogging platforms because at the time it was easier and cheaper to run, but that's an effect and not a cause.
These either weren't available at all in 2000 or very new and much harder to set up. You need to consider the state of things 20 years ago, not how they are today.
chroot and jails have been around for a while, i don’t know the date but since ive used bsd and linux they’ve been there. definitely during this era. selinux was launched in 2000.
Sure, you could even argue that PHP was a success despite the PHP language (which was, in the beginning, only a cobbled-together templating language, and then, to Rasmus Lerdorf's dismay, people started to implement their backend logic in the templating language), and Python could have done it, but, well, they didn't...
PHP succeed precisely because of how it executes .php files directly as scripts from a single running instance. This allowed it to be the shared hosting solution because it uses far far less resources than a similar python solution.
Python is great if you want to run your own server or VM per site. It's not so great if you want to run a shared server and it's shared servers (not VMs) that brought the price down and therefore opened the floodgates of allowing people to run their own sites cheaply and easily.
Python webserver support doesn't support SSI-style open and closing code tags in HTML files to be executed per-request, last I checked.
Is there anything like php or bml (bradfitz's equivalent for perl) for python, so that you can put code right in your html to be replaced at serving time with the code's output?
https://docs.python.org/3/library/cgi.html
All your prints are essentially sent as response with CGI, but I think for Python WSGI is the standard you should use, and you can e.g. use jinja to render HTML with templates where you can use variables, certain functions, etc. Is that what you are looking for?
With the recent problem in sudo, I suspect this to be a likely cause. The typical shared hosting stack uses that somewhere, so servers will have it installed. A fast, malicious user (and a slow update process) is enough to get root on one machine and penetrate the rest of the net from there (can still be avoided, but requires some effort).
I assume because they have more margin to keep up. If you work a system like this with $1/user minus the 30 cent Cpanel license, you have little to spend on security.
The "no vm per user" means any privilege escalation bug lets a hacker wipe it all. And your unsupported customers are probably running all sorts of vulnerable stuff.
