Secure programming is NOT just good programming

[dwheeler at ida.org (David A. Wheeler)]

mikeiscool claimed:
> Secure programming is good programming.
> Most books teach good programming.

I strongly disagree with you, on both counts.
At the least, those who say they practice good programming
practices, and books that say they teach good programming
practices, are GROSSLY INADEQUATE for developing secure programs.

First, "Secure programming is good programming":
Most people and organizations who claim that they perform
good programming practices do NOT perform practices
necessary for security.  You could argue that therefore they
aren't really doing "good programming", but that doesn't
help fix anything. And organizations STILL generally
place features over security, and when there's a perceived
conflict, security almost always loses... and they'll STILL
say that they practice "good programming" practices (they just
happen to correctly implement insecure programs).

Here are some practices you should typically be doing
if you're worried about security, and note that many are
typically NOT considered "good programming"
by the general community of software developers:
* You need to identify your threats that you'll counter (as requirements)
* Design so that the threats are countered, e.g., mutually
   suspicious processes, small trusted computer base (TCB), etc.
* Choose programming languages where you're less likely to
   have security flaws, and where you can't (e.g., must use C/C++), use extra
   security scanning tools and warning flags to reduce the risk.
* Train on the specific common SECURITY failures of that
   language, so you can avoid them. (E.G., gets() is verbotin.)
* Have peer reviews of the code, so that others can help find
   problems/vulnerabilities.
* Test specifically for security properties, and use fuzz testing
   rigged to test for them.
Few of these are done, particularly the first two. I'll concede
that many open source software projects do peer reviews, but you
really want ALL of these practices.

Next, "Most books teach good programming." Pooey, though I wish they did.
I still find buffer overflows in examples inside books on C/C++.
I know the first version of K&R used scanf("...%s..."..) without noting
that you could NEVER use this on untrusted input; I think the
second edition used gets() without commenting on its security problems.
A typical PHP book is littered with examples that are XSS disasters.

The "Software Engineering Body of Knowledge" is supposed to
summarize all you need to know to develop big projects.. yet
it says essentially NOTHING about secure programming
(it presumes that all programs are stand-alone, and never connect
to an Internet or use data from an Internet - a ludicrous assumption).
(P.S. I understand that it's being updated, hopefully it'll correct this.)

I'd agree that "check your inputs" is a good programming
practice, and is also critically important to secure programming.
But it's not enough, and what people think of when you say
"check your inputs" is VERY different when you talk to security-minded
people vs. the general public.

One well-known book (I think it was "Joel on Software") has some
nice suggestions, but strongly argues that you should accept
data from anywhere and just run it (i.e., that you shouldn't
treat data and code as something separate). It claimed that sandboxing
is a waste of time, and not worthwhile, even when running code from
arbitrary locations... just ask the user if it's okay or not
(we know that users always say "yes"). When that author thinks
"check your inputs", he's thinking "check the syntax" -
not "prevent damage".  This is NOT a matter of "didn't implement it
right" - the program is working AS DESIGNED.  These programs
are SPECIALLY DESIGNED to be insecure.  And this was strongly
argued as a GOOD programming practice.

> People just don't care.

There, unfortunately, we agree.  Though there's hope for the future.

--- David A. Wheeler