“This article is a first in series that deals with secure programming and related issues. Before we begin though, let’s first define secure programming. A ‘secure program’ is an application that sits on a security boundary, taking input from a source that does not have the same access rights as the program. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs.”
If you concidered reading the article you probably know everything it has to say. Nothing on coding, just some “basics”.
(For some code) maybe check this out instead:
http://www.dwheeler.com/secure-programs/
Reviewing the basics is always good. Never trust input period, database, file, ipcs, everything is suspect nowadays.
“Page 3 of 4
Continued…
The next question that’s important to ask is: should we use secure programming in all the programs we make,”
Yes!
“or in some specific cases? I don’t think we need secure programming in all applications, but a select few certainly demand enhanced security techniques. All these programs have some common characteristics. These characteristics include:”
Just wait until someone calls your code from a CGI script, or some (other) kind of wrapper/portal/interface, or installs it suid, or whatever… And the enduser who’s machine gets hacked into puts the blame on you.
Sort of agree with you in that secure thinking and programming need to become ingrained in a developers habits.
That said – there are a great many programs that are written for occasional use behind closed doors for a limited time. Crunching data between old and new systems would be one example. These do not, IMHO, warrant costly security audits.
Prototypes are again another category where security can (sometimes) take a back seat on the basis that you’re gonna rewrite the thing anyway (to quote the Mythical Man Month).
It sort of comes down to self discipline being healthy and dogmatism being kinda scary.