As others have said, most uses of Tcl was no doubt Eggdrop bots. I made an eggdrop bot to do some interesting stuff in an irc channel. I also learned nice and important lesson in the process about Tcl and dynamic execution in general (such as in SQL) : Fully dynamic execution is great as long as you spend more time checking input than actually writing logic.
As an example, you can do the following in Tcl as the article points out:
set a pu
set b ts
$a$b "Hello World"
Awesome! I'll use this kind of dynamic behavior to let users of the bot have more freedom. Bzzzzt. This was back in the 90s and the idea of 'SQL injection' wasn't as widespread as it is now... Getting around these kind of injections in Tcl requires constant vigilance and sometimes is very confusing.
Another interesting issue is the lack of types and how Tcl interprets them. Ask the user for a number and check if its between 1 and 3, and reject if it isn't. Works fine until the user tries the number 0x01, which matches 1 in some places but not in others. Gave me a lot of appreciation for typed languages where an int really is an int.
Sure, but people don't generally write large programs in shell scripts.
If you want to relegate TCL to short scripts, i guess it's the same as shell scripting, but if you want to use it for more than that this behavior is dangerous.
In your circles they may have been "just about no understanding", but in my circles there was.
For the record, the standard database interface that Perl uses, DBI, was first released as early alpha on Oct 12, 1994. Its solution to SQL injection is bind parameters. As far as I can tell, that first release had support for bind parameters, but I don't have that version's documentation for that feature.
The first release of the first real database driver was 24th Feb 1995. (Again, early alpha, you couldn't actually fetch data.) From the comments in the change log, bind variables were always a priority, and finally arrived for DBD::Oracle on 22 Aug 1995. From that point on if you used Perl and connected using DBI in the way recommended by the documentation, you were protected from SQL injection attacks.
I'm sorta confused when you say there was "no understanding". It's not like a basic SQL injection is something hidden, or even remotely difficult to understand, and it doesn't even exploit a complicated environment.
You're literally passing user input to a language interpreter - what else could you expect? I don't believe there needs to be "understanding" to realise that you just wrote exec($userinput) and that might be bad.
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.
> 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.
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".
As someone who spent his teenage years "hacking" in multiple senses of the word, I can assure you there were plenty of people using buffer overflows before rtm's worm and there were plenty of people using data injection attacks long before the phrase "SQL Injection" was coined.
Back before the mid-2000s it used to take years/decades for ideas like that to bubble up into being "common wisdom" but in those years/decades, there would be hundreds to thousands of people exploiting the ideas, sharing information with other like-minded individuals privately (pre-everyone-has-a-blog), etc.
Wait, what? There were tons of people exploiting buffer overflows to upload code into running processes before 1988?
I call shenanigans.
Like you, I'm personally acquainted with a pretty good cross section of the best known people in vuln research in the '90s, and I was in the room with Peter Zatko and Dave Goldsmith and, at other times, San Mehat, Tim Newsham, and Ivan Arce as they figured out various ways to exploit overflows. This stuff was (weirdly!) new when 8lgm published it in '95. I sincerely doubt that it was old news to anyone when RTM used it in the worm.
If this was in any sense old hat to anyone, where are all the overflow exploits between 1988 and the Lopatic NCSA HTTPD exploit from 1995?
I remember conceiving of the idea of Sql injection all by my lonesome in 1996. When mentioned this thread to my employers, I was old that "we do not to consider such possibilities since they exist in every part of our code".
So there was "no understanding" in only a particular sense of the terms... (I doubt I was the only smart person to conceive of these attacks back in the day)
I would believe you if you said buffer overruns. There was an understanding about buffer overruns, but the tools to help protect against them weren't developed until much later.
As an example, you can do the following in Tcl as the article points out:
Awesome! I'll use this kind of dynamic behavior to let users of the bot have more freedom. Bzzzzt. This was back in the 90s and the idea of 'SQL injection' wasn't as widespread as it is now... Getting around these kind of injections in Tcl requires constant vigilance and sometimes is very confusing.Another interesting issue is the lack of types and how Tcl interprets them. Ask the user for a number and check if its between 1 and 3, and reject if it isn't. Works fine until the user tries the number 0x01, which matches 1 in some places but not in others. Gave me a lot of appreciation for typed languages where an int really is an int.