Difference between revisions of "Static Code Analysis"

From OWASP
Jump to: navigation, search
(Added __FORCETOC__ to create contents table)
 
(42 intermediate revisions by 3 users not shown)
Line 11: Line 11:
 
==Description==
 
==Description==
  
Static Code Analysis is usually performed as part of a Code Review and is carried out at the Implementation phase of a Security Development Lifecycle (SDL). Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within source code by using techniques such as Flow Control and/or Pattern Matching.
+
Static Code Analysis (also known as Source Code Analysis) is usually performed as part of a Code Review (also known as white-box testing) and is carried out at the Implementation phase of a Security Development Lifecycle (SDL). Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within 'static' (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis.
  
==Risk Factors==
+
Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.
  
* Talk about the [[OWASP Risk Rating Methodology|factors]] that this control affects
+
Some tools are starting to move into the Integrated Development Environment (IDE). For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.
* What effect does this countermeasure have on the attack or vulnerability?
+
* Does this control reduce the technical or business impact?
+
  
 +
The UK Defense Standard 00-55 requires that Static Code Analysis be used on all 'safety related software in defense equipment'. [0]
  
==Difficulty to Implement==
+
==Techniques==
 +
There are various techniques to analyze static source code for potential vulnerabilities that maybe combined into one solution. These techniques are often derived from compiler technologies.
  
* Discuss the typical difficulty of implementing this control, emphasizing the factors that make it easier or harder
+
===Data Flow Analysis===
* Steer clear of language/platform specific information here
+
Data flow analysis is used to collect run-time (dynamic) information about data in software while it is in a static state (Wögerer, 2005).
  
 +
There are three common terms used in data flow analysis, basic block (the code), Control Flow Analysis (the flow of data) and Control Flow Path (the path the data takes):
 +
 +
Basic block: A sequence of consecutive instructions where control enters at the beginning of a block, control leaves at the end of a block and the block cannot halt or branch out except at its end (Wögerer, 2005).
 +
 +
Example PHP basic block:
 +
 +
<pre>
 +
1. $a = 0;
 +
2. $b = 1;
 +
3.
 +
4. if ($a == $b)
 +
5. { # start of block
 +
6.  echo “a and b are the same”;
 +
7. } # end of block
 +
8. else
 +
9. { # start of block
 +
10. echo “a and b are different”;
 +
11.} # end of block
 +
</pre>
 +
 +
=== Control Flow Graph (CFG) ===
 +
An abstract graph representation of software by use of nodes that represent basic blocks. A node in a graph represents a block; directed edges are used to represent jumps (paths) from one block to another. If a node only has an exit edge, this is known as an ‘entry’ block, if a node only has a entry edge, this is know as an ‘exit’ block (Wögerer, 2005).
 +
 +
Example Control Flow Graph; ‘node 1’ represents the entry block and ‘node 6’ represents the exit block.
 +
 +
[[File:Control_flow_graph.png|400x200px]]
 +
 +
===Taint Analysis===
 +
Taint Analysis attempts to identify variables that have been 'tainted' with user controllable input and traces them to possible vulnerable functions also known as a 'sink'. If the tainted variable gets passed to a sink without first being sanitized it is flagged as a vulnerability.
 +
 +
Some programming languages such as Perl and Ruby have Taint Checking built into them and enabled in certain situations such as accepting data via CGI.
 +
 +
===Lexical Analysis===
 +
Lexical Analysis converts source code syntax into ‘tokens’ of information in an attempt to abstract the source code and make it easier to manipulate (Sotirov, 2005).
 +
 +
Pre tokenised PHP source code:
 +
 +
<pre>
 +
&lt;?php $name = "Ryan"; ?&gt;
 +
</pre>
 +
 +
Post tokenised PHP source code:
 +
 +
<pre>
 +
T_OPEN_TAG
 +
T_VARIABLE
 +
=
 +
T_CONSTANT_ENCAPSED_STRING
 +
;
 +
T_CLOSE_TAG
 +
</pre>
 +
 +
==Strengths and Weaknesses==
 +
 +
=== Strengths ===
 +
* Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))
 +
* For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.
 +
 +
=== Weaknesses ===
 +
* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.
 +
* High numbers of false positives.
 +
* Frequently can't find configuration issues, since they are not represented in the code.
 +
* Difficult to 'prove' that an identified security issue is an actual vulnerability.
 +
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.
 +
 +
==Limitations==
 +
 +
===False Positives===
 +
A static code analysis tool will often produce false positive results where the tool reports a possible vulnerability that in fact is not. This often occurs because the tool cannot be sure of the integrity and security of data as it flows through the application from input to output.
 +
 +
False positive results might be reported when analysing an application that interacts with closed source components or external systems because without the source code it is impossible to trace the flow of data in the external system and hence ensure the integrity and security of the data.
 +
 +
===False Negatives===
 +
The use of static code analysis tools can also result in false negative results where vulnerabilities result but the tool does not report them. This might occur if a new vulnerability is discovered in an external component or if the analysis tool has no knowledge of the runtime environment and whether it is configured securely.
 +
 +
==Important Selection Criteria==
 +
 +
* Requirement: Must support your language, but not usually a key factor once it does.
 +
* Types of Vulnerabilities it can detect (The OWASP Top Ten?) (more?)
 +
* Does it require a fully buildable set of source?
 +
* Can it run against binaries instead of source?
 +
* Can it be integrated into the developer's IDE?
 +
* License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)
 +
* Does it support Object-oriented programming (OOP)?
  
 
==Examples==
 
==Examples==
  
===Short example name===
+
===RIPS PHP Static Code Analysis Tool===
: A short example description, small picture, or sample code with [http://www.site.com links]
+
[[File:Rips.jpg|400px|thum|]]
  
===Short example name===
+
===OWASP LAPSE+ Static Code Analysis Tool===
: A short example description, small picture, or sample code with [http://www.site.com links]
+
[[File:LapsePlusScreenshot.png|400px|thum|]]
  
 
== Tools ==
 
== Tools ==
 +
 +
===OWASP Tools===
 +
* [https://www.owasp.org/index.php/Category:OWASP_Code_Crawler OWASP Code Crawler] (.NET & Java)
 +
* [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project] (Java,PHP,C & JSP)
 +
* [[OWASP_LAPSE_Project | OWASP LAPSE Project]] (Java)
 +
* [[OWASP O2 Platform]]
  
 
=== Open Source/Free ===
 
=== Open Source/Free ===
  
* [https://www.owasp.org/index.php/OWASP_LAPSE_Project OWASP LAPSE  ] (Java)
+
* [http://www.stachliu.com/resources/tools/google-hacking-diggity-project/attack-tools/ Google CodeSearchDiggity] (Multiple)
 
* [http://pmd.sourceforge.net/ PMD] (Java)
 
* [http://pmd.sourceforge.net/ PMD] (Java)
 
* [http://www.dwheeler.com/flawfinder/ FlawFinder] (C/C++)
 
* [http://www.dwheeler.com/flawfinder/ FlawFinder] (C/C++)
Line 45: Line 135:
 
* [http://findbugs.sourceforge.net/ FindBugs] (Java)
 
* [http://findbugs.sourceforge.net/ FindBugs] (Java)
 
* [http://sourceforge.net/projects/rips-scanner/ RIPS] (PHP)
 
* [http://sourceforge.net/projects/rips-scanner/ RIPS] (PHP)
 +
* [http://sourceforge.net/projects/agnitiotool/ Agnitio] (Objective-C, C#, Java & Android)
 +
* [http://msdn.microsoft.com/en-us/library/ms933794.aspx Microsoft PreFast] (C/C++)
 +
* [https://www.fortify.com/ssa-elements/threat-intelligence/rats.html Fortify RATS] (C, C++, Perl, PHP & Python)
 +
* [http://www.devbug.co.uk DevBug] (PHP)
  
 
=== Commercial ===
 
=== Commercial ===
  
* [https://www.fortify.com/ Fortify]
+
* [https://www.fortify.com/ Fortify] (OWASP Member)
* [http://www.veracode.com/ Veracode]
+
* [https://www.veracode.com/ Veracode] (OWASP Member)
 
* [http://www.grammatech.com/ GrammaTech]
 
* [http://www.grammatech.com/ GrammaTech]
 
* [http://www.parasoft.com/jsp/home.jsp ParaSoft]
 
* [http://www.parasoft.com/jsp/home.jsp ParaSoft]
* [http://www.armorize.com/codesecure/ Armorize CodeSecure]
+
* [http://www.armorize.com/codesecure/ Armorize CodeSecure] (OWASP Member)
* [http://www.checkmarx.com/ Checkmarx Cx Suite]
+
* [http://www.checkmarx.com/ Checkmarx Static Code Analysis] (OWASP Member)
 +
* [http://www-01.ibm.com/software/rational/products/appscan/source/ Rational AppScan Source Edition]
 +
* [http://www.coverity.com/products/static-analysis.html Coverity]
 +
* [http://www.klocwork.com/products/insight.asp Insight]
  
==Related [[Attacks]]==
+
===Other Tool Lists===
  
* [[Attack 1]]
+
* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html NIST - Source Code Security Analyzers]
* [[Attack 2]]
+
* [http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis Wikipedia - List of tools for static code analysis]
  
 +
==References==
  
==Related [[Vulnerabilities]]==
+
[0] Ministry of Defence (MoD). (1997) ''SAFETY RELATED SOFTWARE IN DEFENSE EQUIPMENT'' [Online]. Available at: http://www.software-supportability.org/Docs/00-55_Part_2.pdf (Accessed: 5 January 2012).
  
* [[Vulnerability 1]]
+
[1] Northumbria University. (2012) ''Implementing Basic Static Code Analysis into Integrated Development Environments (IDEs) to Reduce Software Vulnerabilities'' [Online]. Available at: http://www.ethicalhack3r.co.uk/wp-content/uploads/2012/09/Implementing-Basic-Static-Code-Analysis-into-Integrated-Development-Environments-IDEs-to-Reduce-Software-Vulnerabilities.pdf (Accessed: 19 March 2013)
* [[Vulnerabiltiy 2]]
+
 
+
 
+
 
+
==Related [[Controls]]==
+
 
+
* [[Control 1]]
+
* [[Control 2]]
+
 
+
 
+
==References==
+
  
 
== Further Reading ==
 
== Further Reading ==
  
 +
* [https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf OWASP Code Review Guide v1.1]
 
* http://www.crosstalkonline.org/storage/issue-archives/2003/200311/200311-German.pdf
 
* http://www.crosstalkonline.org/storage/issue-archives/2003/200311/200311-German.pdf
 
* http://www.ida.liu.se/~TDDC90/papers/industrial95.pdf
 
* http://www.ida.liu.se/~TDDC90/papers/industrial95.pdf
 +
* http://www.php-security.org/downloads/rips.pdf
 +
* http://www.seclab.tuwien.ac.at/papers/pixy.pdf
  
 
[[Category:FIXME|
 
[[Category:FIXME|
Line 108: Line 198:
 
Session Management Control
 
Session Management Control
 
]]
 
]]
__NOTOC__
+
__FORCETOC__
  
 
[[Category:Control]]
 
[[Category:Control]]

Latest revision as of 17:57, 19 March 2013

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


Every Control should follow this template.


This is a control. To view all control, please see the Control Category page.

Last revision (mm/dd/yy): 03/19/2013

Contents

Description

Static Code Analysis (also known as Source Code Analysis) is usually performed as part of a Code Review (also known as white-box testing) and is carried out at the Implementation phase of a Security Development Lifecycle (SDL). Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within 'static' (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis.

Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.

Some tools are starting to move into the Integrated Development Environment (IDE). For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.

The UK Defense Standard 00-55 requires that Static Code Analysis be used on all 'safety related software in defense equipment'. [0]

Techniques

There are various techniques to analyze static source code for potential vulnerabilities that maybe combined into one solution. These techniques are often derived from compiler technologies.

Data Flow Analysis

Data flow analysis is used to collect run-time (dynamic) information about data in software while it is in a static state (Wögerer, 2005).

There are three common terms used in data flow analysis, basic block (the code), Control Flow Analysis (the flow of data) and Control Flow Path (the path the data takes):

Basic block: A sequence of consecutive instructions where control enters at the beginning of a block, control leaves at the end of a block and the block cannot halt or branch out except at its end (Wögerer, 2005).

Example PHP basic block:

1. $a = 0;
2. $b = 1;
3. 
4. if ($a == $b) 
5. { # start of block
6.   echo “a and b are the same”;
7. } # end of block 
8. else 
9. { # start of block 
10. echo “a and b are different”;
11.} # end of block

Control Flow Graph (CFG)

An abstract graph representation of software by use of nodes that represent basic blocks. A node in a graph represents a block; directed edges are used to represent jumps (paths) from one block to another. If a node only has an exit edge, this is known as an ‘entry’ block, if a node only has a entry edge, this is know as an ‘exit’ block (Wögerer, 2005).

Example Control Flow Graph; ‘node 1’ represents the entry block and ‘node 6’ represents the exit block.

Control flow graph.png

Taint Analysis

Taint Analysis attempts to identify variables that have been 'tainted' with user controllable input and traces them to possible vulnerable functions also known as a 'sink'. If the tainted variable gets passed to a sink without first being sanitized it is flagged as a vulnerability.

Some programming languages such as Perl and Ruby have Taint Checking built into them and enabled in certain situations such as accepting data via CGI.

Lexical Analysis

Lexical Analysis converts source code syntax into ‘tokens’ of information in an attempt to abstract the source code and make it easier to manipulate (Sotirov, 2005).

Pre tokenised PHP source code:

<?php $name = "Ryan"; ?>

Post tokenised PHP source code:

T_OPEN_TAG
T_VARIABLE
=
T_CONSTANT_ENCAPSED_STRING
;
T_CLOSE_TAG
 

Strengths and Weaknesses

Strengths

  • Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))
  • For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.

Weaknesses

  • Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.
  • High numbers of false positives.
  • Frequently can't find configuration issues, since they are not represented in the code.
  • Difficult to 'prove' that an identified security issue is an actual vulnerability.
  • Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.

Limitations

False Positives

A static code analysis tool will often produce false positive results where the tool reports a possible vulnerability that in fact is not. This often occurs because the tool cannot be sure of the integrity and security of data as it flows through the application from input to output.

False positive results might be reported when analysing an application that interacts with closed source components or external systems because without the source code it is impossible to trace the flow of data in the external system and hence ensure the integrity and security of the data.

False Negatives

The use of static code analysis tools can also result in false negative results where vulnerabilities result but the tool does not report them. This might occur if a new vulnerability is discovered in an external component or if the analysis tool has no knowledge of the runtime environment and whether it is configured securely.

Important Selection Criteria

  • Requirement: Must support your language, but not usually a key factor once it does.
  • Types of Vulnerabilities it can detect (The OWASP Top Ten?) (more?)
  • Does it require a fully buildable set of source?
  • Can it run against binaries instead of source?
  • Can it be integrated into the developer's IDE?
  • License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)
  • Does it support Object-oriented programming (OOP)?

Examples

RIPS PHP Static Code Analysis Tool

Rips.jpg

OWASP LAPSE+ Static Code Analysis Tool

LapsePlusScreenshot.png

Tools

OWASP Tools

Open Source/Free

Commercial

Other Tool Lists

References

[0] Ministry of Defence (MoD). (1997) SAFETY RELATED SOFTWARE IN DEFENSE EQUIPMENT [Online]. Available at: http://www.software-supportability.org/Docs/00-55_Part_2.pdf (Accessed: 5 January 2012).

[1] Northumbria University. (2012) Implementing Basic Static Code Analysis into Integrated Development Environments (IDEs) to Reduce Software Vulnerabilities [Online]. Available at: http://www.ethicalhack3r.co.uk/wp-content/uploads/2012/09/Implementing-Basic-Static-Code-Analysis-into-Integrated-Development-Environments-IDEs-to-Reduce-Software-Vulnerabilities.pdf (Accessed: 19 March 2013)

Further Reading