From a developer point of view… secure coding
For most of us here, we are looking to hack and crack systems. But spare a thought to those poor souls who have try to ensure their code stands up to the hack attack. And coming from a developer background, I should *really* know more about the security aspects of coding.
As you may know there are a number of different programming languages out there. The most commonly used programming languages for web applications are PHP and perl. Both have potential security pitfalls as they mix the ability to send and receive data through web applications with performing system level tasks.
There are number of gotchas that coders can look for. With PHP, OWASP have their own top 5. There’s even a hardening php project. But the best guide I’ve seen so far is i-love-jack-daniels along with these brief PHP thoughts. With Perl, there is CPAN’s perlsec pod and cgisecurity has a good reference as well. One of the things you can apply whilst you code is tainting as described by developer.com, which should flag up issues with any dodgy variables and program arguments.
There some programming languages which offer a framework that handles security more implicitly but it still takes a daft developer to insert some dangerous code. Anyhow, Microsoft have a security guide for asp.net applications, whilst Java have their own.
Generally speaking, a developer should do their own code audit and code review before it is released. Naturally, there’s always pressure from sales, marketing, MD’s, etc. but in an ideal world, things should be done PROPERLY.
I don’t like some of the links you provided (mostly the Ounce Labs ones)… they cheapen the code review process and sound a lot more like introductory marketing material to the subject.
It’s a huge process, and probably the best tool for code review has been around since forever - Fagan inspection. This applies to the whole SDLC: starting with requirements. I’d like to see more people using tools like the NASA SATC Automated Requirement Measurement Tool or Microsoft Research SpecExplorer while performing early reviews such as those mentioned in `The Art of Software Security Assessment’. Cigital also has some good training and presentations on the subject. The Microsoft SDL makes a notion of “abuse cases” instead of “use cases” for requirements gathering.
Most important to design review is taking everything you can from MITRE CAPEC to integrate with attack-models and threat-models. The attackpatterns.org website, buildsecurityin website, and the Octotrike tool are excellent resources.
Finally, when you get to the programming phase (where only 5% of security vulnerabilities are uncovered), there needs to be more process, testing, and tool usage in place. Fortify, OunceLabs, and Klockwork all sell automated static checkers specifically for security that should be used both in IDE as well as during smoke testing efforts, such as nightly builds.
Some open-souce static bytecode analysis tools already have security checks in place - FindBugs and FxCop being fine examples of this. These can also be integrated into smoke testing, which is typically a build server such as Luntbuild or CruiseControl .NET working under continuous integration. Bugs must be submitted to an issue tracking system (such as Trac) that developers are responsible for. When working with source-code management (e.g. CVS, Subversion), developers should also work to a certain coding standard (e.g. CheckStyle) and promote some warnings to errors (especially ones that are quality or security related). For example, having all imports available in all the builds can be critical to solving the “third-party code” vulnerability problem and tools such as Ivy / IvyDE can help with this a great deal.
Nothing can get past good, formal Fagan inspection - and with IM clients, SCM to email systems, and great code review tools such as the commercial ones from Atlassian (JIRA and FishEye integration, Crucible, etc) - there is basically no excuse to not perform Fagan inspection code review at every check-in. Yes, I’m serious: every check-in. At the very least, code review can be done at every component check-in into the build system if the scale of unit-based code review scares your development department.
There are plenty of tools to also add serious quality checks at build-time - usually that support XML syntax configuration and integrate as Ant tasks (or NAnt). Besides the aforementioned static source code analyzers and static bytecode analyzers, there are also tools that will do smart-fuzz testing in the build or even can be configured for complex fault-injection.
My favorite build-server integrated tools that would help for security purposes, as well as quality purposes are the open-source Java PathFinder or SPIN (model-checkers), as well as Canoo WebTest, WindMill, or Jameleon (data-driven, unit-test integrated, system integration and functional test tools). Of unique special mention is CUTE, a C concolic unit test engine, as well as jCUTE (for Java), which is the only build-time tool that supports smart-fuzz testing natively. However, to combine fault-injection tests for web application security testing into, say, Canoo WebTest - would be not only a snap, but more like two snaps up in a circle. I’m not aware of any commercial tools that do this (Microsoft has internal tools such as FuzzGuru), but for model-checking - Coverity PREVENT is known for its bug-finding flexibility and power, although rarely “just” a vulnerability-finding tool.
If GPF or EFS had Ant task integration, this sort of testing would be ideal. Imagine having the spec writers also code the protocol dissectors for working with a fuzzing framework such as Sulley or Peach - and integrating this into the build server. That would save a lot of time and effort! Make sure you’re developer-testers have read or seen the Charlie Miller presentation at Toorcon 9 on using code coverage to enhance fuzzing, where he demonstrates usage of gcov, lcov, PaiMei, EFS, and satifiabliity solvers such as the stp tool to improve security testing results. This would move the likelihood of finding vulnerabilities after code is live/sold (where 70% of known vulnerabilities are usually found) to before the quality testing phase (which usually finds less than 20% of known vulnerabilities).
Eventually, I would like to see a world where every commercial software package would be required to provide code coverage results and other metrics from these sorts of tests, along with the samples of the “worst” and “most untested” code. Then, people could know how crappy their software is, and actually how many security bugs exist in a typical component in modern-day applications. Then we can start to get lawyers and compliance involved as more of an actuary science instead of pissing matches.
The more I think about it, though, I also want to integrate operational review / architectural review concepts into the whole “secure coding” landscape. But who really thinks that grsecurity, CORE GRASP, and PHP-IDS are going to _solve_ the vulnerability problem? They may help us explain or understand certain issues better - and possibly delay some adversaries under ideal conditions. So - yes, design review and application/code review are certainly most important - and developers are just too lazy to care (or being pushed too hard on deadlines) about fixing the sad state that we’re in with a typical/average/common day-in-the-life of these less-popular review processes.
There’s some hardcore and useful information in there. The original post was meant to be an introduction.
But the bottom line is well, I wouldn’t say some developers are lazy to care. They are more pushed by deadlines in a corporate world.
[...] Operation n » From a developer point of view… secure coding (tags: security development) [...]