Section 2. Auditing Source Code Manually


2. Auditing Source Code Manually

This exercise introduces the goals of auditing source code for security and spells out the steps involved in performing a basic audit.

Any kind of manual source code review requires patience, an eye for detail, and extensive knowledge about the types of problems that can cause a program to fail. A security audit is no different, but instead of thinking "what could go wrong?" the auditor must consider "what could an attacker force to go wrong?" The auditor's role is to pare down this infinite search space and identify the most dangerous problems and weaknesses in a program. Experience is invaluable but can only be gained through practice.

This exercise demonstrates a simple manual audit process for a small Web application. The files for this lesson are located under two subdirectories in the following directory: Install_Directory/Tutorial/do_manual_audit. The webapp subdirectory contains a sample Web application for this lesson. The Answers subdirectory contains responses to the questions posed below.

  1. Examine the webapp application. Do not look for specific issues yet, just become familiar with the application by asking the same types of questions that an auditor starting a code audit would ask, such as:

    • How large is the application?

    • What are the technologies involved?

    • What is the basic design of the application?

    • Who are the likely attackers?

    • What would an attacker hope to achieve?

    • How are the developers trying to protect the application?

    • What sorts of techniques might an attacker use to subvert the application?

    • What risks would a successful attack pose to the company (e.g., customer confidence, public image, etc.)?

    Some vulnerabilities are easier to spot than others. Generally speaking, when the scope of an issue is limited to a single screen of source code, it is much easier to find than an issue that requires understanding the interaction between pieces of code from multiple (far-flung) locations.

  2. Examine the source code of the following Servlet: webapp/src/java/com/simpleco/CountServlet.java.

    • How and when is this code executed?

    • What can an attacker control?

    • Can an attacker violate the programmer's assumptions?

    • What is vulnerable about this Servlet?

  3. Examine each of the application files, consider the interaction between the various modules, and identify issues that render the application vulnerable.

Exercises for the Reader

Beginner

  1. How many vulnerability patterns can you consciously look for as you are manually auditing the code5, 10, 100, 1,000?

  2. What techniques would you use to keep track of paths across files?

  3. How often should a security audit be performed? If you performed an audit today and fixed the problems, what would your confidence be in the code 90, 120, or 180 days later? How much new code would your developers write in 90, 120, or 180 days?

Advanced

  1. If you had to set up a process for manually auditing code in your company, how would you estimate the amount of effort and time required to do it effectively? How do the requirements scale as the size of the code base grows?

  2. What are the ideal skills for a security code auditor? How many people in your organization are well qualified? What jobs do they do today?

  3. Why do people perform security code audits rather than simply testing the software?

  4. If you cannot audit all of the code, how should you choose which section of code to audit? How confident are you about the results of the audit?

  5. Enumerate five programming styles or techniques that make auditing easier or harder.




Software Security. Building Security In
Software Security: Building Security In
ISBN: 0321356705
EAN: 2147483647
Year: 2004
Pages: 154
Authors: Gary McGraw

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net