4 ms·

No web dev here, but if memory serves, the main concerns about CGI were about safety, not performance or efficiency. If that's the case, I wonder if new more sa

No web dev here, but if memory serves, the main concerns about CGI were about safety, not performance or efficiency. If that's the case, I wonder if new more safe languages could make its use viable again.

yakubin 4y ago
With people reaching for kqueue, epoll and io_uring to handle the C10K problem it seems that spawning processes wouldn’t be a great idea, with the latency and memory overhead of spawning itself, as well as the meagre limits of the number of concurrent processes in a system.
mrweasel 4y ago
One issue was that people configured CGI wrong. You had executable scripts that had free range on the entire filesystem. Ideally you'd need to limit the cgi-scripts to a chroot, but that made it difficult to use Perl, Python and PHP. OpenBSD shipped/ships a chrooted Perl for use with CGI, but other operating systems just left that bit as an exercise to the programmer. More modern languages like Go or Rust provides a lot of safety and is pretty easy to statically compile, so it's easily chrooted. It would however be weird to do a CGI program in Go, because that language already have a really good build in webserver and more powerful/easily accessible features for interacting with requests compared to what CGI provides.
- sgbeal 4y ago
  > It would however be weird to do a CGI program in Go, because that language already have a really good build in webserver and more powerful/easily accessible features for interacting with requests compared to what CGI provides. Noting that not everyone has the ability to run standalone servers on their web hoster. Shared hosters generally enable CGIs but cannot support per-user standalone servers, in particular not on common ports like 80 or 443.
ptx 4y ago
What safety concerns are you referring to? CGI scripts often had issues with SQL injection and shell command injection, but that was because of badly designed (or poorly used) libraries and unrelated to CGI itself. Or if CGI programs were written in C (as a result of performance concerns) those would of course have the usual memory safety issues of C programs.
- diocles 4y ago
  (Not the parent but) one cool CGI-specific problem that always comes to mind is HTTPoxy: https://www.ionos.co.uk/digitalguide/server/configuration/httpoxy-behind-the-cgi-vulnerability/ https://www.ionos.co.uk/digitalguide/server/configuration/ht... You could write this off as a library implementation problem, but it comes about because of unfortunate mapping of HTTP parameters to well-known environment variables in CGI, and has tripped up multiple library authors.
- ilyt 4y ago
  Usually poor ops hygiene, same really as PHP problems: * Code runs as web server user * Code is deployed as web server user, because web monkey doesn't understand unix permission (or alternatively chmod 777 everything for same effect) * Code gets hacked, attacker can modify any file so they just leave backdoor in code If you deploy code as different user attacker can still of course steal all the data but at the very least they can't modify the code that is running. On top of that, a lot of poor security practices when it comes to qouting stuff. Perl had kinda interesting feature regarding that where in special mode (recommended for apps dealing with untrusted inputs) the variable was considered tainted [1] till something "cleaned" it by passing it thru regexp. So say taking argument directly from environment (so headers for web) or stdin and passing it with no processing to system() would trigger it. * [1] https://perldoc.perl.org/perlsec https://perldoc.perl.org/perlsec

yakubin 4y ago

With people reaching for kqueue, epoll and io_uring to handle the C10K problem it seems that spawning processes wouldn’t be a great idea, with the latency and memory overhead of spawning itself, as well as the meagre limits of the number of concurrent processes in a system.

mrweasel 4y ago

One issue was that people configured CGI wrong. You had executable scripts that had free range on the entire filesystem. Ideally you'd need to limit the cgi-scripts to a chroot, but that made it difficult to use Perl, Python and PHP. OpenBSD shipped/ships a chrooted Perl for use with CGI, but other operating systems just left that bit as an exercise to the programmer. More modern languages like Go or Rust provides a lot of safety and is pretty easy to statically compile, so it's easily chrooted. It would however be weird to do a CGI program in Go, because that language already have a really good build in webserver and more powerful/easily accessible features for interacting with requests compared to what CGI provides.

sgbeal 4y ago
> It would however be weird to do a CGI program in Go, because that language already have a really good build in webserver and more powerful/easily accessible features for interacting with requests compared to what CGI provides. Noting that not everyone has the ability to run standalone servers on their web hoster. Shared hosters generally enable CGIs but cannot support per-user standalone servers, in particular not on common ports like 80 or 443.

ptx 4y ago

What safety concerns are you referring to? CGI scripts often had issues with SQL injection and shell command injection, but that was because of badly designed (or poorly used) libraries and unrelated to CGI itself. Or if CGI programs were written in C (as a result of performance concerns) those would of course have the usual memory safety issues of C programs.

diocles 4y ago
(Not the parent but) one cool CGI-specific problem that always comes to mind is HTTPoxy: https://www.ionos.co.uk/digitalguide/server/configuration/httpoxy-behind-the-cgi-vulnerability/ https://www.ionos.co.uk/digitalguide/server/configuration/ht... You could write this off as a library implementation problem, but it comes about because of unfortunate mapping of HTTP parameters to well-known environment variables in CGI, and has tripped up multiple library authors.
ilyt 4y ago
Usually poor ops hygiene, same really as PHP problems: * Code runs as web server user * Code is deployed as web server user, because web monkey doesn't understand unix permission (or alternatively chmod 777 everything for same effect) * Code gets hacked, attacker can modify any file so they just leave backdoor in code If you deploy code as different user attacker can still of course steal all the data but at the very least they can't modify the code that is running. On top of that, a lot of poor security practices when it comes to qouting stuff. Perl had kinda interesting feature regarding that where in special mode (recommended for apps dealing with untrusted inputs) the variable was considered tainted [1] till something "cleaned" it by passing it thru regexp. So say taking argument directly from environment (so headers for web) or stdin and passing it with no processing to system() would trigger it. * [1] https://perldoc.perl.org/perlsec https://perldoc.perl.org/perlsec