Secure Coding Practices

This document started out as a rewrite of the Mozilla Security Reviewers' Guide (http://www.mozilla.org/projects/security/components/reviewguide.html), tailored for Chandler.

Attack Trees

@@@TODO

Plan to Mitigate Security Threats

This section describes generic steps we can take to help eliminate security problems in the first place, find and fix them in design, implementation and testing phases, and respond to problems found after we ship.

Security Training

@@@TODO

Security Reviews of Design and Implementation

It is possible and beneficial to look at a feature's design, and think how it could be broken, and how it could be made more resilient to attacks. Ideally security will always be in the mind of the designers but at a minimum there should be at least one security review of the design. The designs should contain sections about security implications.

UI and Security: http://www.sims.berkeley.edu/~rachna/security_usability.html

Security reviews should also be done during and after implementation. All modules, objects and functions should assume the outside world is hostile and bent on their destruction. Are all the assumptions the code makes correct? Does it fail safely? Defense in depth?

Ask others to review your code whenever possible.

Hunt Down Security Problems

We can scan for security problems using various tools, but also manually looking at the code for some common vulnerabilities like buffer overflows, integer overflows and sign mismatches, race conditions and so on can be useful.

The attack trees provide good ways to start for manual bug hunts.

Security Testing

While normal testing asserts that the program does what it is supposed to do, security testing makes sure that the program doesn't do anythin else, and it can't be exploited for unwanted purposes.

Security testing should include testing with huge data values (large buffers, many buffers), unusually frequent or rare calls, random data, slightly corrupted data, and so on.

The designs, manuals and attack trees are good starting points for security testing.

Whenever security bugs are found in Chandler, we need to investigate and make sure that there are no other similar bugs lurking around (there quite often are similar problems).

Also, when security problems are found in completely different products, we need to evaluate if the problem applies to Chandler and if so, investigate if the problem(s) can be found in Chandler.

Concrete Issues

Look at the separate page on some concrete tips and issues to look for in making robust software: SecurityTips.

Tools

Cross-platform:

• Flawfinder

Windows:

• MS AppVerifier^? etc.

Recommended Reading

• Building Secure Software: How to Avoid Security Problems the Right Way by John Viega and Gary McGraw, ISBN 020172152X. Book site 1.
• Writing Secure Code, 2nd Edition by Michael Howard and David LeBlanc, ISBN 0-7356-1722-8. Errata

• Secure Programming Cookbook for C and C++ by John Viega and Matt Messier, ISBN 0-596-00394-3. Book site 1. Errata.