bofh wrote: > Heh. I think we're having far too much fun in the other threads. I > have a serious question.
thank goodness. :) > I'm a mangler in a largish company. We have > developers, and contractors. No coding standards and all that, so, > things are... messy. > > I'm not in charge of development, but I want to help them develop > something useful, and secure. Other than doing a braindump of the > developers here, what are the things that you people have found useful > to have in secure programming practises? > > I'm looking for advice, tips, procedures, processes, whatever. I will > be looking through my old notes from Matt Bishop's class at SANS, and > other things I've gathered throughout the years. Random throughts, no particular order, no particular structure. Don't take any of it as gospel unless it makes sense to you. Any time I think my own coding, I have flashbacks to a couple stupid programming errors I made when I was young and think I better stick to the www/ tree. :) * In addition to good coding practice, look at good DESIGN. After you do all you can to make the code secure, imagine that it ISN'T, and do what you can to contain the damage. * Decide if security is really your top goal. Get it in writing. If it is, keep it that way. Yes, the mere fact you are offering a service over the 'net means you are taking on some risk, but at every point, you should ask, "Is the risk worth the benefit?". Look at the actual risks of a loss-of-data-confinement, and ask yourself if you would be willing to explain that decision to someone who was the victim of a compromise brought on by that decision. Or explain it to a jury. So far, the legal system has been amazingly tolerant to people who write bad code, and instead opted to try to go after the people who commit the theft. Some day, however, people are going to start thinking bad design, like a defective lock on an unguarded vault, is a crime, too. * Don't store excess data outside the firewall: Somethings are needed to be stored on web applications. Other things should be unloaded and purged. If someone knocks over your web app, they shouldn't find a store of credit card numbers and personal user information, collected over the last few years, unless there is really a reason for it to be there. If you have to collect sensitive info, get it moved to another machine ASAP. * Don't punch holes inward through your firewall: Given a choice, have internal apps fetch data from outside machines, don't have outside machines put data into (or fetch data from) internal machines. Why? If the outside machine is compromised, you don't want it to be able to work-over machines inside your network, which presumably have a lot more data, much of it is probably more interesting. * Beware of people who when you talk to them about "secure programming" immediately talk about "encryption". Most security breaches happen at the endpoints, not in-transit. These people clearly don't understand secure PROGRAMMING, just one tiny feature. * Use things like privilege separation and chrooting PROPERLY. For example, the point of privilege separation isn't the buzzword itself, but rather to make sure that the privileged code is small, secure and correct. Simply priv-sep'ing code and having the part that runs as root being poorly written, bloated, unchecked, and unaudited is just complicating things, not improving security. * Good code first, "tricks" second. Look at the history of OpenBSD's security work. Sure, we got things like W^X, Propolice, privilege separation, chroot'ed apps, etc., but look at how it was done: Those things were done AFTER the basic code was cleaned up. I.e., provide extra protection to a secure system, not slap bandages over crap. * Beware of experts. Anyone who gives you one simple answer to "safe coding" is full of it. It ain't that simple. Anyone who says, "I've got all the info you need" is also probably dangerous. Anyone eager to jump into the computer security business and bless your project is either a fraud or a fool. This stuff is too complicated to ever be able to wave your hands and say, "this is secure". I sometimes wonder if anyone who really understands all the threats out there is even willing to use a computer for anything other than recreational purposes, and (s)he'd probably never be willing to endorse someone else's code. * Never stop looking for problems in existing code. Don't stick it into use and say, "It's done". * When you (*ahem* or someone) finds a bug/hole, don't fix it and say "done", fix it, and go find the other instances of the same bug. Plan on making a longer explanation of why you couldn't find additional instances of the same bug than you would of why the same error happened five times. * Management has to have an interesting balance of attitude: that quality code is a REQUIREMENT, crap is unacceptable, and yet recognize that Stuff Happens, and that if you condemn people for finding bugs, they will (surprise!) find no bugs (but the bad guys will). * There needs to be a positive attitude towards improving code, not just adding features. Heck, even on the OpenBSD lists, which gets more excitement, the adding of a new feature (even if not complete!), or the fixing of a subtle, long-time code flaw that never bit anyone (yet)? Management has to appreciate the quality of the code, not just the cute features the user sees. * Plan the security in at the beginning, before the first line of code is written. Examine the threats the system will face, and figure out how you minimize each one. If the project deviates from the starting plan or other risks are thought of, re-examine the threats. * Use existing code you trust over re-writing the same basic task. * Don't forget the user, and what stupid things they will do. Sure, you can't prevent them from doing stupid things, but you might be able to avoid provoking them to do stupid things to get around annoyances in your app. (WHY oh WHY do some websites where all I'm interested in is downloading an application and reading documentation a: insist that I log in at all, b: have a password of 37 or more characters, mixed case, odd punctuation, three digits and want to know when my mother gave up her virginity?) If you follow the above advice, you will not be guaranteed quality code, but I can assure you your project will take much longer and cost more than management was hoping. And this is why shit happens. Nick.
