I'm curious if you were actually developing software in the 90s. Of course, in hind-sight, SQL injections are obvious. However, at the time, the collective understanding of security issues was much lower. Most people developing code were doing so for desktop users, where people would be "injecting" themselves, so no thought was given to the need to sanitize.

Those attitudes and behaviors spilled over into web development. I know I built more than one perl cgi script that concatenated user-input values together without thought or concern.

It wasn't until very near 2000 that the collective consciousness started to come around the new and different problems web programming brought. It still isn't completely there.

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.

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:

    Perl:
        system("/usr/lib/sendmail -t $foo_address < $input_file");

    C: 
        sprintf(buffer, "/usr/lib/sendmail -t %s < %s", foo_address, input_file);
        system(buffer);

    C++:
        system("/usr/lib/sendmail -t " + FooAddress + " < " + InputFile);

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.

I think it's more of an Eternal September (http://en.wikipedia.org/wiki/Eternal_September) event where security was fairly well understood by a small group of people that needed it in the 80's, but 'those in the know' (Banks, NSA, etc) never really spoke with the new generation of web developers.

PS: There is a reason that phrase refers to September 1993.

I remember when Eternal September began. I wasn't exactly a seasoned veteren at that point, but I had at least enough history to have compiled a Usenet FAQ (I came online in 1990). It was sad what the Eternal September did to misc.kids. I still miss that group from before that time.

I believe that for many programmers who knew what they was doing in 90's the problem that we now call "SQL Injection" was about functionality ("Why can't my article contain an apostrophe?") and not security. It's similar to many buffer overflow vulnerabilities and so on: often it is not only security issue but also functionality issue.

Yes, but my first real commercial stuff was on the web. Web apps aren't that special though: it holds true for any server-based app. A point-of-sale app that allows a clerk to inject and change prices is pretty messed up. Same principles.

Although, maybe it's just a different mindset. Some developers seem to aim to develop "easiest thing that can work" and others aim for "easiest thing that won't break".

SQL injection style security problems are merely a subclass of sanitizing user inputs.

Bad user inputs can cause crashes/catastrophic problems e.g. buying -1 shares from a stock market system.

Therefore computer science teaches to always sanitize inputs. I was taught this in high school in the 80s.

"I know I built more than one perl cgi script that concatenated user-input values together without thought or concern."

You have no excuse.