Re: Strategies for teaching secure coding practices

[Andrew Gray <adsgray () shaw ca>]

On Fri, Dec 12, 2003 at 11:24:46AM -0500, Steve Litt wrote:
> 1. If you must use pointers or memory copies, be very, very careful!
> 2. When accepting user input, test it.
> 3. Never let the user write in the name of a process or subroutine to run.
> 4. Always truncate excess user input.
> 5. Permissions
> 6. How to handle files writeable by CGI
> 7. Validate all incoming URL's.
>
> SteveT

I think it's important to focus not on application or language specific
things, but to teach general principles:

(i) E.g. points 2, 3, 4, and 7 could all be encompassed by the principle
"all user input should be considered tainted/malicious and should be
carefully laundered before use". Of course specific examples are very
useful to illustrate it.

(ii) Another principle could be "always carefully ensure that you
satisfy the preconditions of any library or system function you
use". Your point 1 could be considered a special case of this: since
memcpy, strcpy et al. cannot check that the destination buffer is big
enough, an implicit precondition of those functions is that the caller
has allocated enough room. This leads to the suggestion that implicit
preconditions shouldn't be, that is they should be made explicit in
comments or other documentation.

(iii) Another is "always check the return value of any library or system
function you use". Ignoring return values can lead to subtle bugs and
therefore possibly security holes. I'm thinking of read(2) and write(2)
but there are others.

(iv) "The principle of least permission/capabality." This could cover
points 5 and maybe 6 above. *nix specific examples are "only run as
root if you don't have to" and "restrict file permissions only to the
smallest group of users and/or groups that is necessary, and no more".

These are really just defensive coding and system design practices,
but if they are applied religiously they can reduce common security-hole
causing bugs, IMO.

 - Andrew