5 ms·

The phrase "SQL Injection" was coined in 2000. There was just about no understanding of the threat of these attacks in the 90s

MichaelGG 14y ago
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.
- SoftwareMaven 14y ago
  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.
  - ucee054 14y ago
    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.
  - dfox 14y ago
    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.
  - MichaelGG 14y ago
    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".
  - Retric 14y ago
    I think it's more of an Eternal September (http://en.wikipedia.org/wiki/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.
    - SoftwareMaven 14y ago
      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.
  - dalke 14y ago
    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.org/Security/faq/www-security-faq.html 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.providers/msg/cec253d29c0e5c1b?dmode=source 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 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.
georgemcbay 14y ago
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.
- tptacek 14y ago
  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?
btilly 14y ago
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.
joe_the_user 14y ago
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)
darkarmani 14y ago
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.

MichaelGG 14y ago

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.

SoftwareMaven 14y ago
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.
- ucee054 14y ago
  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.
- dfox 14y ago
  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.
- MichaelGG 14y ago
  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".
- Retric 14y ago
  I think it's more of an Eternal September (http://en.wikipedia.org/wiki/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.
  - SoftwareMaven 14y ago
    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.
- dalke 14y ago
  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.org/Security/faq/www-security-faq.html 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.providers/msg/cec253d29c0e5c1b?dmode=source 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 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.

georgemcbay 14y ago

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.

tptacek 14y ago
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?

btilly 14y ago

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.

joe_the_user 14y ago

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)

darkarmani 14y ago

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.