[kwlug-disc] Security arguments

Khalid Baheyeldin kb at 2bits.com
Wed Sep 23 19:37:52 EDT 2009


On Wed, Sep 23, 2009 at 7:09 PM, <john at netdirect.ca> wrote:

> -----kwlug-disc-bounces at kwlug.org wrote: -----
> >To: KWLUG discussion <kwlug-disc at kwlug.org>
> >To be fair, 20 years ago, the environment that programs would be
> >
> >deployed in was far less hostile than what it is today for web
> >servers.
> >Apart from the Morris worm, there was no port scans, remote expolits,
> >code injection, SQL injection, Cross Site Scripting, Cross Site
> >Request Forgery, ...etc. ad nauseum.
> >
> >The worst that could happen was that an insider would do a Robin
> >
> >Hood and Friar Tuck
> >
> >http://www.csd.uwo.ca/~magi/personal/humour/Computer_Folklore/Robin%2<http://www.csd.uwo.ca/%7Emagi/personal/humour/Computer_Folklore/Robin%2>
> >0Hood%20And%20Friar%20Tuck.html
>
> 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.
>

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.


> 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.
>
> Should we blame SQL or SQL library designers for allowing us to make
> commands strings?
>

Yes, strings were part of it, but the absence of a hostile population makes
it less likely to be exploited.

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.

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.

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.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20090923/609b14d1/attachment.htm>


More information about the kwlug-disc mailing list