Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

Re: What do you take for secure programming?

Subject: Re: What do you take for secure programming?
Date: Thu, 27 Jan 2005 20:14:36 +0000
Nice broad question:-).

Here are some thoughts on the matter.

Spend time and take care on the problem definition. Examine it at
length, looking for ways to adjust the problem spec so a simpler,
more robust implementation can meet it. The less code you've gotta
write, the fewer security-critical bugs you'll write.

Try to find well-maintained, carefully-analyzed existing components
that can be used to solve parts of the problem. The less code you've
gotta write, the fewer ....

Try to find the highest-level programming language with which you
are confident and comfortable to use to write the remaining bits.
The less code you've gotta write ....

Carefully scrutinize the data flow; concentrate on places where
data crosses trust boundaries, e.g. places where unauthenticated
users present data to trusted services, places where less-privileged
processes present data to more-privileged ones, etc. Be meticulous
about data validation at these points, and try and keep that data
validation logic as simple, clear, clean, and compact as possible.
The less code ....

If you've succeeded, you've written as little code as possible, and
have a simple, clear architecture. So find someone else, who has had
nothing to do with the specification, design, or implementation, and
explain the whole lot to them. Besides the possibility that they
might spot bugs you've overlooked, the simple process of describing
and explaining it forces you to review it in a different way.

Look for auditing tools, ideally ones completely disconnected from
your specific architecture and design; both code-analysis (one-time)
and data-monitoring (permanent watchdog) tools are great safety
nets.

Least privilege is a great technique. In traditional Unix systems,
this can often be implemented by decomposing the system into
processes, that run as distinct, unprivileged uids, where possible
in chrooted jails. Shoving subsystems that do more sophisticated
(==fragile) processing into such jails is an especially big win.

-Bennett

Attachment: pgpz8xo7lym2c.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>