5 ms·

I built a billing site for my software business and had to decide which tech to use. SPA? React + Rails? Elixir? Keep in mind we are talking about single digit

I built a billing site for my software business and had to decide which tech to use. SPA? React + Rails? Elixir? Keep in mind we are talking about single digit req/min. I went with CGI. It has some drawbacks but consider the advantages: * Requires nothing but Apache running, minimizes attack surface area * Deploy is a simple `git pull`, no services to restart * No app server running 24/7 so I don't have to monitor memory usage or anything else. I love it. Takes little to no maintenance because it never changes. Runs on a $5/mo droplet. https://www.mikeperham.com/2015/01/05/cgi-rubys-bare-metal/ https://www.mikeperham.com/2015/01/05/cgi-rubys-bare-metal/

bdcravens 7y ago
> Deploy is a simple `git pull` Did you have to do anything to lockdown the .git folder?
- kencausey 7y ago
  Why do you think the file system is accessible at all? Due to possible errors in the script?
  - hedora 7y ago
    It is common for noobs to put index.cgi (or whatever) in the root of the git repo, and to point Apache at that by cutting and pasting a hello world example from google. A better approach is to put it in a subdirectory, and RTFM of Apache/nginx.
laumars 7y ago
I'm not about to dictate to someone that their choices are better nor worse than anybody else's but I don't think you make a particularly convincing argument in favour of CGI: > Requires nothing but Apache running, minimizes attack surface area Sure, but the attack surface remaining (CGI) is far less secure than pretty much everything else out there. > Deploy is a simple `git pull`, no services to restart Same could be said for a dozen other service side frameworks. > No app server running 24/7 so I don't have to monitor memory usage or anything else. I mean, if you exclude the server you're talking about, then sure. But you still have a server running 24/7 that you need to monitor so the framework becomes somewhat irrelevant from that perspective. --- Personally I still use CGI for personal projects I hack together. But none of them are directly open to the internet.
- wbl 7y ago
  CGI security depends on the framework you use after. It's just different from reverse proxy.
  - laumars 7y ago
    True but considering most peoples use of CGI is without a framework (otherwise you might as well just use that framework as the HTTP server) you're then having to place a lot of trust in the developer not to accidentally foot-gun themselves. It's like the Rust argument. Sure, a skilled developer could write good code in C++ but languages like Rust make it harder to accidentally foot-gun yourself and more obvious in the code when you do happen to do it.
- chasil 7y ago
  The thttpd server is efficient in the extreme, can constrain itself to a chroot(), and is able to execute CGIs. In that environment, even the largest attack surface will have great difficulty escaping confinement.
  - laumars 7y ago
    Apache httpd 2.4 can be chrooted (maybe 2.2 as well? Or at the very least some distros back ported that feature to 2.2) but it's not enabled by default and can take some set up to get working properly if you're not a seasoned sysadmin. chroot is definitely not common amongst Apache installations, let alone common amongst CGI usage (which likely comprise of more than just Apache httpd users). However one blessing is at least the execution directory is limited to /cgi-bin (even if software running inside cgi-bin can fork their own processes outside of that directory). It's also worth noting that "efficient" is a poor choice of words for CGI - be it in the context of security or it's more common usage in terms of performance. CGI work by forking processes (which is slooooow). In fact CGI is ostensibly a $SHELL for HTTP (if you look at the mechanics of how shells are written vs how CGI works). Someone elsewhere else in this discussion described CGI as a "protocol" and I wouldn't even go that far because all the HTTP headers and such like are passed to the forked process via environmental variables. In fact could literally set the same environmental variables in Bash (for example) and then run your CGI-enabled executable in the command line and get the same output as if you hit httpd first. But as I said in my first post: I don't hate CGI. Far from it, it's been a great tool over the years and I still use it now for hacking personal stuff together. But it's also not something I'd trust on the open internet any longer. It's one of those cool pieces of tech that simply doesn't make sense on the modern internet any longer (like VRML, Sockwave and Flash, the web 1.0 method of incremental page loads (I forget the name), FTP (that protocol really needs to die!) etc.
kawsper 7y ago
That is why I use ngx_lua for some (small) projects, on deploy just git pull, reload nginx, and now your code is updated. I've been meaning to try out the mruby nginx bindings, and maybe rewrite the Lua code to Ruby(ish) code but I haven't had the time yet.
mbell 7y ago
> Requires nothing but Apache running, minimizes attack surface area Shellshock comes to mind as a counter point.
- spc476 7y ago
  It's only a concern if the CGI script is written in shell or uses the `system()` function.

bdcravens 7y ago

> Deploy is a simple `git pull` Did you have to do anything to lockdown the .git folder?

kencausey 7y ago
Why do you think the file system is accessible at all? Due to possible errors in the script?
- hedora 7y ago
  It is common for noobs to put index.cgi (or whatever) in the root of the git repo, and to point Apache at that by cutting and pasting a hello world example from google. A better approach is to put it in a subdirectory, and RTFM of Apache/nginx.

laumars 7y ago

I'm not about to dictate to someone that their choices are better nor worse than anybody else's but I don't think you make a particularly convincing argument in favour of CGI: > Requires nothing but Apache running, minimizes attack surface area Sure, but the attack surface remaining (CGI) is far less secure than pretty much everything else out there. > Deploy is a simple `git pull`, no services to restart Same could be said for a dozen other service side frameworks. > No app server running 24/7 so I don't have to monitor memory usage or anything else. I mean, if you exclude the server you're talking about, then sure. But you still have a server running 24/7 that you need to monitor so the framework becomes somewhat irrelevant from that perspective. --- Personally I still use CGI for personal projects I hack together. But none of them are directly open to the internet.

wbl 7y ago
CGI security depends on the framework you use after. It's just different from reverse proxy.
- laumars 7y ago
  True but considering most peoples use of CGI is without a framework (otherwise you might as well just use that framework as the HTTP server) you're then having to place a lot of trust in the developer not to accidentally foot-gun themselves. It's like the Rust argument. Sure, a skilled developer could write good code in C++ but languages like Rust make it harder to accidentally foot-gun yourself and more obvious in the code when you do happen to do it.
chasil 7y ago
The thttpd server is efficient in the extreme, can constrain itself to a chroot(), and is able to execute CGIs. In that environment, even the largest attack surface will have great difficulty escaping confinement.
- laumars 7y ago
  Apache httpd 2.4 can be chrooted (maybe 2.2 as well? Or at the very least some distros back ported that feature to 2.2) but it's not enabled by default and can take some set up to get working properly if you're not a seasoned sysadmin. chroot is definitely not common amongst Apache installations, let alone common amongst CGI usage (which likely comprise of more than just Apache httpd users). However one blessing is at least the execution directory is limited to /cgi-bin (even if software running inside cgi-bin can fork their own processes outside of that directory). It's also worth noting that "efficient" is a poor choice of words for CGI - be it in the context of security or it's more common usage in terms of performance. CGI work by forking processes (which is slooooow). In fact CGI is ostensibly a $SHELL for HTTP (if you look at the mechanics of how shells are written vs how CGI works). Someone elsewhere else in this discussion described CGI as a "protocol" and I wouldn't even go that far because all the HTTP headers and such like are passed to the forked process via environmental variables. In fact could literally set the same environmental variables in Bash (for example) and then run your CGI-enabled executable in the command line and get the same output as if you hit httpd first. But as I said in my first post: I don't hate CGI. Far from it, it's been a great tool over the years and I still use it now for hacking personal stuff together. But it's also not something I'd trust on the open internet any longer. It's one of those cool pieces of tech that simply doesn't make sense on the modern internet any longer (like VRML, Sockwave and Flash, the web 1.0 method of incremental page loads (I forget the name), FTP (that protocol really needs to die!) etc.

kawsper 7y ago

That is why I use ngx_lua for some (small) projects, on deploy just git pull, reload nginx, and now your code is updated. I've been meaning to try out the mruby nginx bindings, and maybe rewrite the Lua code to Ruby(ish) code but I haven't had the time yet.

mbell 7y ago

> Requires nothing but Apache running, minimizes attack surface area Shellshock comes to mind as a counter point.

spc476 7y ago
It's only a concern if the CGI script is written in shell or uses the `system()` function.