<br><br><div class="gmail_quote">On Wed, Sep 23, 2009 at 7:09 PM,  <span dir="ltr"><<a href="mailto:john@netdirect.ca">john@netdirect.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div class="im">-----<a href="mailto:kwlug-disc-bounces@kwlug.org" target="_blank">kwlug-disc-bounces@kwlug.org</a> wrote: -----<br></div><div><div class="im">
>To: KWLUG discussion <<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a>><br></div><div class="im">>To be fair, 20 years ago, the environment that programs would be<br>><br>>deployed in was far less hostile than what it is today for web<br>
>servers.<br>>Apart from the Morris worm, there was no port scans, remote expolits,<br>>code injection, SQL injection, Cross Site Scripting, Cross Site<br>>Request Forgery, ...etc. ad nauseum.<br>><br>>The worst that could happen was that an insider would do a Robin<br>
><br>>Hood and Friar Tuck<br>><br>><a href="http://www.csd.uwo.ca/%7Emagi/personal/humour/Computer_Folklore/Robin%2" target="_blank">http://www.csd.uwo.ca/~magi/personal/humour/Computer_Folklore/Robin%2</a><br>
>0Hood%20And%20Friar%20Tuck.html<br><br></div>I should clarify. I learned user-space application programming, not operating system programming. The bugs above were either kernel level or service level. We learned to edit user input to obtain clean data. <br>
</div></font></blockquote><div><br>Me too, I started out with applications as well. Sanitizing the application's input was mandatory, but not for security reasons, rather for application and data sanity. I remember one manager who used to test an app's data input screen by pressing the keyboard randomly and reporting any unexpected behavior.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div><br>
I suppose the advent of SQL, where we are tempted to build command strings using input data is one major turning point for security bugs.  In other databases we didn't have that option since the interface was programmatic not command oriented. I wonder how many programmers don't know to use replaceable parameters in SQL calls.<br>
<br>Should we blame SQL or SQL library designers for allowing us to make commands strings?<br></div></font></blockquote><div><br>Yes, strings were part of it, but the absence of a hostile population makes it less likely to be exploited.<br>
<br>But, even if we have a security hole in an internal business application that is not on a public network (think TTY connections, or a private LAN), it does not matter as much as when it is on the internet. If someone injects SQL or code ...etc. they can be traced down because there are user name and passwords, and a finite list of employees that are authorized to use the application. So the pool of potential "evil doers" is far less, and they can always be tracked down and punished.<br>
<br>In a hostile environment, like the internet, you can't do much, other than know that someone has broken in from an address in the Ukraine/Russia or whatever. Oh well, then you fix your service.<br><br>You take pro-active defensive measures, realize that is, and alway will be, an arms race scenario, update your stack and applications to the latest security patches, and life goes on.<br>
</div></div>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra<br>
Simplicity is the ultimate sophistication. --   Leonardo da Vinci<br>