code reviews

Code Reviews

James WaldenNorthern Kentucky University

CSC 666: Secure Software Engineering

Topics

1. Types of Reviews2. Code Review Process3. Checklists4. Prioritizing Code to Review


Code Reviews

Inspection of source code by one or more people who aren’t the author of the code.

Goal: Identify defects for later removal. People: Moderator, reviewers. Scope: Module or small set of classes. Time: 1-2 hours; <1kloc


Benefits of Code Reviews1. Find defects sooner in the lifecycle.

(IBM finds 82% of defects before testing.)

2. Find defects with less effort than testing.(IBM—rev: 3.5 hrs/defect, test: 15-25 hrs/defect.)

3. Find different defects than testing.(Can identify design and requirements problems too.)

4. Educate developers about security bugs.(Developers frequently make the same mistakes.)


PCI DSS6.3.7.b Obtain and review policies to confirm that all custom application code changes for web applications must be reviewed (using either manual or automated processes) as follows: Code changes are reviewed by individuals other �then the originating code author, and by individuals who are knowledgeable in code revietechniques and secure coding practices. Code reviews ensure code is developed accordin�to secure coding guidelines such as the Open Web Security Project Guide (see PCI DSS Requirement 6.5). Appropriate corrections are implemented prior to�release. Code review results are reviewed and approved �by management prior to release.


Inspections

Most formal process. Thorough coverage with separated roles. Use checklists to focus on specified goals. Collect metrics to track defects. Determine whether further inspections of

revised software needed at end of meeting. Extensive documentation of effectiveness.

One study found 16-20 defects/kloc with inspections compared with 3 defects/kloc in informal walkthrough.


Roles in Reviews

1. ModeratorManages meeting; follows up on issues.

2. ReaderParaphrases code during meeting.Not the author.

3. RecorderRecords bugs discovered.

4. AuthorProvides context for code; answers questions.Makes corrections after code review.


Walkthroughs

Less formal process. Author leads meeting and describes code. Focus on author needs, not quality goals. No checklists used or metrics gathered.

Quality varies widely. Walkthrough quality depends solely on author. Useful for educating developers about code,

provide high level view of design and defects.


Code Review Process

PlanningAuthorModerator

Prep

Everyone

Meeting

Everyone

Rework

Author

Follow-upAuthorModerator


Planning

1. Author initiates Planning once code ready.2. A Moderator is assigned to inspection.3. Author and Moderator assemble inspection pkg.4. Moderator identifies other participants.


Prep

Everyone

Meeting

Everyone

Rework

Author



Preparation

1. Reviewers examine inspection package.2. Reviewers use checklists and analysis

tools.3. Reviewers mark bugs found.


Prep

Everyone

Meeting

Everyone

Rework

Author



Meeting

1. Reader describes code in own words.2. Reviewers comment and ask questions.3. Recorder notes all potential bugs,

suggestions.4. Team appraises code at meeting

conclusion.


Prep

Everyone

Meeting

Everyone

Rework

Author



Rework

Author addresses issues recorded at meeting.


Prep

Everyone

Meeting

Everyone

Rework

Author



Follow-up

1. Moderator meets with Author about rework.

2. Moderator verifies all changes made correctly.

3. Author checks in corrected code.


Prep

Everyone

Meeting

Everyone

Rework

Author



Formality Spectrum

Review Planning Prep Meeting Rework FollowupInspection Yes Yes Yes Yes YesTeam Review Yes Yes Yes Yes NoWalkthrough Yes No Yes Yes NoPair Programming

Yes No Con-tinuous

Yes Yes

Peer Deskcheck

No Yes Possibly Yes No

Ad Hoc Review

No No Yes Yes No


Code Review Tips1. Know your limits.

Typical review speed is 150-200 lines/hour.Limit meeting length to 1-2 hours.

2. Know what bugs to look for.ChecklistsStatic analysis tools

3. Use tools.Simple tools: grep, findstrCode viewersStatic analysis tools

4. Require preparation before the meeting.


ChecklistsSecurity reviews should include checklists ofcommon problems, including:

1. SQL injection2. Cross-site scripting3. Input validation bugs4. Checking return values5. Resource name canonicalization6. Race conditions


Code Review Problems

1. Requires substantial expertise in area of programming and security to be effective.

2. Human readers are fallible and will miss mistakes.

3. Code reviews are slow. Unreviewed legacy code will take time to review.


Prioritizing Code

If you can’t review everything, review Code that runs with privileged mode. Code that listens on globally accessible

sockets. Code that is accessible w/o authentication. Code with a history of vulnerabilities. Code that handles sensitive data. Complex code. Code that changes frequently.


Reviewing for SQL Injection


Ex: Zune infinite loop on 12/31/08

year = 1980;

while (days > 365) { if (IsLeapYear(year)) { if (days > 366) { days -= 366; year += 1; } } else { days -= 365; year += 1; }}


Key Points

Roles Moderator Reader Recorder Author

Process Planning Preparation Meeting Re-work Followup


References1. Brian Chess and Jacob West, Secure Programming

with Static Analysis, Addison-Wesley, 2007.2. Michael Howard, “A Process for Performing Security

Code Reviews.” IEEE Security & Privacy, July 2006.3. Eoin Keary et. al., OWASP Code Review Guide 1.1,

http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project, 2008.

4. Steve McConnell, Code Complete, 2/e, Microsoft Press, 2004.

5. Gary McGraw, Software Security, Addison-Wesley, 2006.

6. PCI Security Standards Council, PCI DSS Requirements and Security Assessment Procedures, v1.2, 2008.

7. Karl Wiegers, Peer Reviews in Software, Addison-Wesley, 2002.

http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project


Static Analysis

James WaldenNorthern Kentucky University


Topics

1. Why Static Analysis?2. False Positives and Negatives3. Static Analysis Internals4. Using the Tools


What is Static Analysis?

Static = without program execution Includes everything except testing. Usually used to refer to compiler type tools.

Examples Static type checking Vulnerability detection tools Formal methods


Why Static Analysis?

1. Code reviews require substantial expertise in secure programming.

2. Human readers are fallible and will miss mistakes.

3. Code reviews are slow. Unreviewed legacy code will take time to review.


Verification TechniquesA

ssur

ance

Cost

PenetrationTesting

FormalVerification

SecurityTesting

CodeReview

StaticAnalysis


False Negatives and Positives

False Positives Tool reports bugs in code that aren’t there. Complex control or data flow can confuse

tools.False Negatives

Tool fails to discover bugs that are there. Code complexity or lack of rules to check.


False Negatives and PositivesM

ista

kes

False Negatives

False Positives

Check Heuristics


Static Analyis Approaches

1. Standard compiler warnings and type checking.

2. Lexing source checkers that look for bad names like strcpy() and gets().

3. Parsing source code checkers.4. Parsing checkers with annotations.5. Formal proof based program verification.


Static Analysis Internals

Parser Model Builder Analysis Engine


Parser

Convert programming language to AST.

Must have a parser for each language that tool supports.

Abstract Syntax Tree


Control Flow Graph

nConsec = 0 s1 = getHexChar(a)s2 = getHexChar(b)

return nConsec

if(a > b)


Data Flow with SSA

Source Code:if (bytesRead < 8) { tail = (byte) bytesRead;

}

SSA Form:if (bytesRead1 < 8) {tail2 = (byte) bytesRead1;

}tail3 = φ(tail1, tail2);


Taint Propagation

Track flow of data from source to sink. Source: where data comes into program. Sink: function that consumes the data.

Vulnerabilities reported if Data comes from an untrusted source. Data consumed by a dangerous sink. No function between source and sink makes

the data safe.


Tainting SQL Injection Example

$link = mysql_connect($DB_HOST, $DB_USERNAME, $DB_PASSWORD) or die ("Couldn't connect: " . mysql_error());

mysql_select_db($DB_DATABASE);$username = $_GET[‘username’];$password = $_GET[‘password’];$query = "select count(*) from users where username =

'$username' and password = '$password'";$result = mysql_query($query);

Source

Source

Sink


Local vs. Global Analysis

Local Analysis: Analysis of an individual function, a.k.a. intraprocedural analysis.

Global Analysis: Follows control and data flow between functions, a.k.a. interprocedural analysis.


Rules

Security knowledge base for tool. Identify data sources. Identify data sinks. Model behavior of validation functions. Check for dangerous configurations. Check control flow (i.e. every lock released.)

Customize for process + project Check coding style is obeyed. Check for custom functions, standards.


Static Analysis Tools

Simple search (lexing) tools Flawfinder ITS4 RATS

Parsing Tools Fortify Source Code Analyzer Coverity Prevent Klocwork K7 Suite FindBugs splint


Using the ToolsWho runs the tools?

Developers Security team

When do you run the tool? While code is being written (IDE integration) Before code check-in After each build After major milestones

What do you do with the results? Support code review process. Support security metrics. Use to decide if project should be released.


Code Reviews

ReviewCodeRun Tool

ReviewResults

Fix BugsUpdateRules


Static Analysis Metrics

Vulnerability density (vulns/KLOC) Vulnerabilities divided by severity

Critical, high, medium, low Vulnerability types

Injection, XSS, race conditions, etc. Vulnerability dwell

How long bug remains in code after detection. Audit coverage

Percentage of code covered by reviews.


Evolution of a Single Project


Key Points Static Analysis

Source code needed, but not execution. Fast, repeatable, objective analysis.

Sources and Sinks Malicious input enters program via sources. Exploitation occurs at the sink.

Mistakes False positives False negatives


References1. Brian Chess and Jacob West, Secure

Programming with Static Analysis, Addison-Wesley, 2007.

2. Eoin Keary et. al., OWASP Code Review Guide 1.1, http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project, 2008.

3. Gary McGraw, Software Security, Addison-Wesley, 2006.

4. PCI Security Standards Council, PCI DSS Requirements and Security Assessment Procedures, v1.2, 2008.

5. Karl Wiegers, Peer Reviews in Software, Addison-Wesley, 2002.



code reviews

Documents

software security

secure programming

security code reviews

code complete

code complexity

parsing source code

unreviewed legacy code

owasp code review guide