RE: The Right Approach to Web Developer Education

["Burke, Charles" <Charles_Burke () HomeDepot com>]

Respectfully,

I have developed applications for retail, manufacturing, telecom,
software, and security software!
Only a fraction of the projects considered security important enough
(from a development standpoint) to allow time and resources for it $$$$.

What about the many 'good' and 'bad' programmers who are 'driven' to
'crunch' out code hour to hour.
These programmers cannot write security frameworks from scratch.  They
need help.  
Developers don't write GUI controls from scratch anymore.  They use
toolkits.  GUI Toolkits, Security Toolkits,  far from failures!

-----Original Message-----
From: Yvan Boily [mailto:yboily () seccuris com] 
Sent: Tuesday, June 29, 2004 1:20 PM
To: 'Mark Curphey'
Cc: webappsec () securityfocus com
Subject: RE: The Right Approach to Web Developer Education


Respectfully, why should it be easy?

Making things easy rarely improves security, and generally reinforces a
false sense of security.  Take a look, for example, at modern airport
security.  To test if a piece of electronics works they ask you to turn
it on.  Anyone with a minimal understanding of electronics and machine
level programming could implement a fake system which would be enough to
mimic the power on test.  This practice gives a nice fuzzy blanket to
the individual passenger, and raises the bar for the most limited
offenders, but will do nothing to stop a determined attacker.  

This may not be an apt comparison to most web applications, however a
recent billing system that I worked with could have been compromised and
abused in a fashion that would result in termination of services for
non-payment. Given that some of the clients handled by the billing
services reside in northern communities who rely on the electrical
services provided to generate heat a successful attack in the middle of
January at -40C weather could result in this billing front end affecting
a life-critical system. This was not a fear-uncertainty-doubt
vulnerability or risk identified as an external auditor, but rather a
legitimate concern discovered internally that resulted in an ongoing
training and education plan put in place to keep the organizations
software developers aware of security concerns.

Allowing ignorance to be compensated for by technologies which require
the implementor to make subjective decisions about the usage explicitly
reduces the reliability of the application because you now have two
unreliable components where before you had one.  A bad programmer is a
bad programmer. A bad programmer with a security framework, and the
responsibility to use it as they see fit is a recipe for disaster.

I do not mean to imply that creating a security framework that can be
readily used as a basis to implement secure software is a Bad Thing, but
it is can definitely be a step in the wrong direction.  Unless it is a
heavily reviewed, open framework it just adds yet another black box to
the process of implementing security.  In my opinion a toolkit like this
at a low level to 'raise the bar' is a failure in the implementation of
security.

Yvan Boily


> -----Original Message-----
> From: Mark Curphey [mailto:mark () curphey com]
> Sent: Tuesday, June 29, 2004 10:34 AM
> To: webappsec () securityfocus com
> Subject: The Right Approach to Web Developer Education
>
> Well said. If you want people to do the right thing, you have
> to make it
> easy for them to do the right thing ! 
>
> -----Original Message-----
> From: Madsen, Villy [mailto:Villy.Madsen () atcoitek com]
> Sent: Tuesday, June 29, 2004 10:19 AM
> To: Mads Rasmussen; Mark Curphey
> Cc: webappsec () securityfocus com; Jeff Williams
> Subject: RE: Finally - Curphey award 2004 to SPI Dynamics
>
> While I do not advocate that Developers be allowed to get lazy about 
> security,
>
> I also feel that providing a standard tool that they can use
> to filter input
> is a bad thing.
>
> Way back a couple of decades ago, I was involved in a Telco project to

> rewrite an application used by Long Distance Telephone operators to
> manage "Time and Charges" calls.   The application was 
> finally shut down
> in 2000.
>
> One of the "breakthroughs" that we pioneered was the heavy
> use of what was
> we called Table Driven IO.  All data input or output from the 
> system was
> defined by a set of mapping tables, that defined what the 
> data could look
> like, how long it was, and where it was mapped to in the 
> application data
> schema. 
>
> The "mapping" applications were general purpose, checked for
> proper type
> - performing whatever data conversions where necessary, 
> guarded against
> overflows etc etc.
>
> Sounds very similar to me.
>
> I thought it was a great idea then, and I still do...
>
> One application to vet (the mapping routine), and a bunch of tables to

> validate.
>
> Easier than validating all of the code snippets that are
> "accepting Input"
> from the external world....
>
>
> Villy
>
>
> Villy Madsen ISP GSEC
> Information Security
> ATCO I-Tek
> Bus: (780) 420-5093
> Cell: (780) 975-0110
> Fax: (780) 420-3916
> Mailto:Villy.Madsen () atcoitek com
>
> The information transmitted is intended only for the addressee and may

> contain confidential, proprietary and/or privileged material.  Any 
> unauthorized review, distribution or other use of or the taking of any

> action in reliance upon this information is prohibited.  If you 
> received this in error, please contact the sender and delete or
> destroy this message
> and any copies.
>
>
> -----Original Message-----
> From: Mads Rasmussen [mailto:mads () opencs com br]
> Sent: Tuesday, June 29, 2004 5:47 AM
> To: Mark Curphey
> Cc: webappsec () securityfocus com; Jeff Williams
> Subject: Re: Finally - Curphey award 2004 to SPI Dynamics
>
>
> Mark Curphey wrote:
> > Here I am, depressed at the prospect of filling in mountains of
> > expense claims from weeks of traveling and approving 
> mundane mails to
> > webappsec about XSS after XSS and along comes a shining
> light. At last
>
> > an "application security" company that gets it ! Hats of to
> the folks
> > at SPI and the Curphey Award for 2004 for leading the industry down
> > the right path !
> >
> > http://biz.yahoo.com/prnews/040628/clm006_1.html
>
> Here is another link
> http://www.eweek.com/article2/0,1759,1617901,00.asp
>
> I don't know about you guys but I have a bad feeling about this. I am
> not sure this is the right path.
>
> The article quotes Caleb Sima, founder and chief technology
> officer of 
> SPI Dynamics saying "It doesn't require developers to learn about 
> security," - "You really just need to validate input to 
> eliminate most 
> application vulnerabilities."
>
> Shouldn't you at least have a feeling for where the developers makes
> their mistakes to be able to insert the right piece of secure code?
>
> By all means it looks like a cool product, but how much can
> we trust it?
>
> One of its features is, qoute
> "Input Validation objects will check incoming data on web forms to 
> validate user-supplied input against a set of rules and prevent 
> parameter manipulation exploits, such as SQL Injection attacks."
>
> Can we trust these "set of rules".
> If they opened their technology, the OWASP team could
> contribute rules 
> to such a database and then we just might get somewhere by 
> having a list
>
> of f.ex regular expressions for using the validator classes
> in .Net or 
> input validation in general but that would probably not happen.
>
> I am concerned that products like this just leads to lazy developers.
>
> Jeff what do you think about this? You wanted to start an input
> validation project based on filters, a database like described above 
> would be quite handy :o)
>
> Just my two bits
>
> --
> Mads Rasmussen, M.Sc.
> Open Communications Security
> www.opencs.com.br
> +55 11 3345 2525