5 ms·
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 i
by RyanZAG 14y ago
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.
- minimax 14y agoYou have to be similarly careful with shell scripts. $ a=ec $ b=ho $ $a$b "Hello World"
- darkarmani 14y agoSure, 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.
- stevoski 14y agoThe phrase "SQL Injection" was coined in 2000. There was just about no understanding of the threat of these attacks in the 90s
- MichaelGG 14y agoI'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.
- SoftwareMaven 14y agoI'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.
- ucee054 14y agoSQL 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.
- dfox 14y agoI 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.
- 14y ago
- georgemcbay 14y agoAs 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.
- tptacek 14y agoWait, 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?
- btilly 14y agoIn 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.
- joe_the_user 14y agoI 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)
- darkarmani 14y agoI 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.