
Serverless: From a PHP Developer - withinboredom
https://withinboredom.info/2018/12/23/serverless-from-a-php-developers-experience/
======
kiwidrew
Yep, the original "serverless" was using FTP to upload CGI scripts (Perl, PHP,
or even C) into your /cgi-bin directory, whereupon your webhost would
magically execute said script each time a client sent an HTTP request. No
provisioning required!

------
theamk
I think the reason why most server companies avoid PHP is because it has a
potential of security nightmare. The environment where the code is allowed and
expected to modify itself means that most of the existing security tools are
useless; and the moment there is a software exploit, you have a huge botnet
army.

(There is already another environment where code is allowed and expected to
modify itself -- IOT devices -- and it has been converted to huge botnet.)

Naturally, the PHP language itself does not require insecure software
practices, and it is entirely possible to have W^X PHP scripts. But this
requires a separate channel for code update -- be it a ssh access to server,
control panel or a secondary server running as a different user -- and thus is
fundamentally incompatible with PHP's "generic server" architecture.

~~~
withinboredom
I would hope that's not the reason. I've seen plenty of insecure Javascript
libraries.

~~~
theamk
But it is a different kind of insecurity. For example, your javascript app
might be full of code execution exploits, but it still runs in docker. So once
vendor releases a fix, you remove old docker container (with all backdoors
that could have been installed there), create a new one, and you are done. In
fact, since the default way to upgrade version is to re-create docket
container, you might be removing backdoors without even being aware of the
fact.

Compare this to typical PHP “ftp” style install, for example. You install
plugins, configure system and update code using config.php. If you ever get
compromised, your backdoor is there to stay. If you are lucky and it made all
new “backdoor.php”, you might be able to note that from file manager. But what
if it just added two lines to footer.php? The chances you will find it are
very slim. And if that backdoor disabled your auto-update system, you won’t
even know something is wrong.

Just to make it clear, yes you can deploy your php apps in a secure way. But
doing so makes install much harder, so I have not seen many PHP apps that
adopt this approach.

~~~
withinboredom
No offense, but what you just said makes zero sense.

An "ftp style install" is not typical at any company I've been at. Most (good)
exploits are executable code in the database, and not even visible (unless you
know where to look). That also applies to Javascript/Python/C/etc that would
survive docker containers and horizontally scaled servers.

The exploits in WordPress (mostly) come from people installing poorly written
plugins without validating the quality of the code, professionals don't let
their company do that. The same could be said about other dependencies in code
everywhere. Always validate your dependencies if you need to ensure quality
and security. It doesn't matter what language you're using.

~~~
theamk
> An "ftp style install" is not typical at any company I've been at

I am glad for you -- as I mentioned, it is possible to have secure PHP
installation, and apparently your company does this. But unfortunately, there
are many people who just want to get app going as fast as possible -- and thus
often end up with "ftp style" install.

Let's look at Wordpress: searching for "install wordpress" brings me here:
[https://codex.wordpress.org/Installing_WordPress#Famous_5-Mi...](https://codex.wordpress.org/Installing_WordPress#Famous_5-Minute_Installation)
, which says "Upload the WordPress files to the desired location on your web
server" and "Run the WordPress installation script by accessing the URL in a
web browser." \-- typical "ftp style install"

Joomla install even talks about ftp clients!
[https://docs.joomla.org/J3.x:Installing_Joomla](https://docs.joomla.org/J3.x:Installing_Joomla)

> Most (good) exploits are executable code in the database, and not even
> visible (unless you know where to look). That also applies to
> Javascript/Python/C/etc that would survive docker containers and
> horizontally scaled servers.

Sure, exploits happen. But the question is: will they persist? Your code might
have database-driven XSS or RCE bug, but hopefully this will be noticed and
fixed -- and once you will install latest version, those database records
would be ignored/rendered inert, and your system is clean.

.. that is, unless you were running Wordpress installed in a recommended way.
There, once you are exploited once, you can click on "upgrade" in admin.php as
much as you want, but your system will stay exploited forever.

But luckily, things are improving. I remember trying to install ownCloud few
years ago, and it _really_ wanted its code dir to be writeable. I just checked
their website today, and they offer Docker install now -- this is great!
Unfortunately, there is still a ton of existing PHP apps which rely on being
able to modify their own code.

~~~
withinboredom
> Upload the WordPress files to the desired location on your web server

Yes, this is how you'd generally install /anything/ on a server. Whether it's
Java/Ruby/Go/etc. You copy/install the files where they need to go so that the
server can execute them. Sometimes an installer will do this for you (ie, `go
get`), but sometimes you have to do it yourself even then, just because you
have a non-standard install.

> there is still a ton of existing PHP apps which rely on being able to modify
> their own code.

Yes, WordPress is very stateful. It's pretty annoying. However, simply
revoking write permissions to the filesystem is pretty straightforward. This
(generally) will keep you amazingly safe from most simple exploits. Running
WordPress in a stateless way is not that difficult.

