Secure Coding mailing list archives

RE: Is developer education a lost cause?


From: "Michael S Hines" <mshines () purdue edu>
Date: Fri, 23 Jan 2004 14:30:09 +0000

So long as you include the analysts in that definition of developers... Then
I agree with you.

Many of our problems are a result of bad specifications.(the error of
omission (in specs) - followed by the error of assumption (in code))

The example in the VanWyk book 'Secure Coding' (SYN flood) for example -
assumes the error was in testing - however the specifications never
addresses what to do about incomplete handshake protocols - a simple 'drop
it' would have saved many people much grief (this is the classic DDoS
attack).

Personally, I believe the problem starts much earlier in the development
cycle.  Of course there are plenty of opportunities for error all along the
product production phases (code, unit test, integration test, QA,
implementation).

MSH
-----------------------------------
Michael S Hines
[EMAIL PROTECTED]

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Joe Teff
Sent: Thursday, January 22, 2004 9:59 PM
To: [EMAIL PROTECTED]
Subject: Re: [SC-L] Is developer education a lost cause?


I beleive that educating developers is the single best method to improve
the security of software. Corners get cut every day because of
constraints of one type or another. That is a fact of life and I don't
see it going away. By educating the builders of the code, at least they
understand what is possible and can start taking better precautions. By
educating the decision makers, we can start redefining which corners just
can't be cut. Or at least what the risks are if they are cut. There are
too many instances where decisions are made because the potential result
is not understood.

Part of my job is to educate developers and architects about web
application security. It is amazing how many do not understand the
weaknesses of various technologies. There is tendency for developers to
only think in terms of how thier software should be used; not in how
someone may misuse it. This tendency causes vulnerabilities like SQL
Injection, command injection, cross-site cripting, buffer overflows,
hidden field/parameter/cookie tampering, direct browsing, directory
traversal, etc.

That doesn't mean they will write 100% safe code forever. Most developers
tend to program more defensively once they are exposed to the possibility
of vulnerable practices.

My next goal is to start educating the decision makers.

joe teff












Current thread: