I was developing CGI programs in the 1990s. Some of my code was in cgi-lib.pl, which was the first widely popular CGI library. I can say that people knew about the problems of trusting arbitrary user input.
Lincoln Stein, who wrote the CGI.pm (the second widely popular CGI library), also wrote "Web Security: A Step-by-Step Reference Guide", published in 1998, which was two years after he started the "World Wide Web Security FAQ". Here's the 1998 archive of the FAQ: http://web.archive.org/web/19980213181713/http://www13.w3.or...
SQL wasn't that widely used in the early- to mid-1990s. While some places used it, I don't think they went mainstream until Philip Greenspun's "Database Backed Web Sites: the thinking person's guide to web publishing" in 1997. So early SQL injection examples are hard to point out.
> The entire philosophy can be summed up as "Never trust input data." Most security holes are exploited by sending data to the script that the author of the script did not anticipate.
plus variations through Perl's pipe, backtick, exec, and eval commands, and C's popen().
It even mentions that using a
open(MAIL, "/usr/lib/sendmail -t")
print MAIL "To: $recipient\n";
doesn't go through the shell but does pass data unchecked to sendmail, so the one should make sure the code cannot be tricked.
If you did HTTP in the early 1990s then you very likely used NCSA's httpd. The security page for httpd, from 1998, is still available from archive.org: http://hoohoo.ncsa.uiuc.edu/cgi/security.html .
> A well-behaved client will escape any characters which have special meaning to the Bourne shell in a query string and thus avoid problems with your script misinterpreting the characters. A mischevious client may use special characters to confuse your script and gain unauthorized access.
Replace "Bourne shell" with "SQL" and you have a SQL injection attack.
You wrote: "However, at the time, the collective understanding of security issues was much lower."
I think you underestimate the collective understanding of 15 years ago and overestimate the collective understanding of now. I've seen a bunch of code written in the last few years (mostly for internal use, by non-professional programmers) which still which sends arbitrary user commands to system() and to SQL.
Lincoln Stein, who wrote the CGI.pm (the second widely popular CGI library), also wrote "Web Security: A Step-by-Step Reference Guide", published in 1998, which was two years after he started the "World Wide Web Security FAQ". Here's the 1998 archive of the FAQ: http://web.archive.org/web/19980213181713/http://www13.w3.or...
SQL wasn't that widely used in the early- to mid-1990s. While some places used it, I don't think they went mainstream until Philip Greenspun's "Database Backed Web Sites: the thinking person's guide to web publishing" in 1997. So early SQL injection examples are hard to point out.
But shell injection examples are a dime a dozen. Here's a posting from 1995 outlining the strategy for dealing with CGI input: http://groups.google.com/group/comp.infosystems.www.provider...
> The entire philosophy can be summed up as "Never trust input data." Most security holes are exploited by sending data to the script that the author of the script did not anticipate.
along with examples with the system() command:
plus variations through Perl's pipe, backtick, exec, and eval commands, and C's popen().It even mentions that using a
doesn't go through the shell but does pass data unchecked to sendmail, so the one should make sure the code cannot be tricked.If you did HTTP in the early 1990s then you very likely used NCSA's httpd. The security page for httpd, from 1998, is still available from archive.org: http://hoohoo.ncsa.uiuc.edu/cgi/security.html .
> A well-behaved client will escape any characters which have special meaning to the Bourne shell in a query string and thus avoid problems with your script misinterpreting the characters. A mischevious client may use special characters to confuse your script and gain unauthorized access.
Replace "Bourne shell" with "SQL" and you have a SQL injection attack.
You wrote: "However, at the time, the collective understanding of security issues was much lower."
I think you underestimate the collective understanding of 15 years ago and overestimate the collective understanding of now. I've seen a bunch of code written in the last few years (mostly for internal use, by non-professional programmers) which still which sends arbitrary user commands to system() and to SQL.