4 ms·

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 (

by 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

by ptx 4y ago

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