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. |

| 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
pgpz8xo7lym2c.pgp
Description: PGP signature
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | What do you take for secure programming?, Gustavo Rios |
|---|---|
| Next by Date: | Re: What do you take for secure programming?, Chris |
| Previous by Thread: | What do you take for secure programming?, Gustavo Rios |
| Next by Thread: | Re: What do you take for secure programming?, Chris |
| Indexes: | [Date] [Thread] [Top] [All Lists] |