Code audits are mostly focused on the public CAcert web site since it represents the exposed surface of the CAcert system and interact directly with openssl.
These are some policies that can help both developers in writing secure code and auditors in finding missing security features and bad practices.
- The code must be secure with any php.ini, it must enforce restrictions by itself.
- Despite register_globals on or off every document must initialize it's variables and check for direct inclusion and calling document using defined constants.
- No globals emulation layer has to be present in the code.
- Development must be done with debugging (E_NOTICE).
- Use the security framework: secure_integer(), secure_mail(), secure_url(), secure_sql() and secure_html() must be called when acquiring user inputs.
- User inputs must be managed at the beginning of the source or at the beginning of the proper logic block, inputs should be documented in the comment header of every file.
- Programmers and auditors must pay attention to decoding issues, the input should be never decoded.
- Dynamic evaluation should be avoided.
Auditors can check the code both by it's inputs (eg: grep "_POST\|_GET\|_COOKIE\|_SESSION\|_SERVER\|$GLOBALS\|[..etc..]" ./ -R) and by sensible functions: for example execution calls (grep "exec\|passthru\|system\|[..etc..]" ./ -R), file includes (grep "require_once\|require\|include_once\|include\|[..etc..]" ./ -R), dynamic evaluations (eval(), $$variable, $$function()), file operations (fopen, file_[get|put]_contents, etc), database operations and any other function that could be of trouble.
support on code metrics by OSNews/Focus Shift