4 ms·

CGI offered much better security than the alternatives that replaced it.

• synergy20 3y ago
  how?CGI runs with the same permissions as http server,if you need run privileged operations you have to let it sudo.. fastcgi is safer
  • mgaunard 3y ago
    It runs in a separate process, and is therefore isolated from the HTTP server. Making it run as the owner of the file is also quite common and trivially achieved (suExec). mod_php, on the other hand, runs inside the HTTP server process and with the same uid and capabilities, with no way to change that.
• tlavoie 3y ago
  Persistent servers moved the goal-posts for problems at least. With stateless HTTP, maintaining state somewhere was always part of the challenge, so CGI programmers would be tempted to put too much into client-side cookies. That meant the user could see and tamper with that info. On the other hand, the brief existence of that CGI program meant that the OS cleaned up much of what the programmer may not have.
  • contingencies 3y ago
    Many of us that old remember independently implementing session engines before they were standard features in the various web-oriented languages of the era (mostly perl and php)... this solved the issue of trusted client-side state by isolating the shared secret to a session identifier and storing real state server side, usually in a file or database. Naïve implementations did not, however, solve for issues such as locking, enforced sequencing for multi-stage actions, token loss, or multiple sessions or clients under an individual account, leading to a plethora of web engine state related bugs, some of which probably re-emerge to this day in novel and embedded session engines.