This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Security Code Review Coverage"

From OWASP
Jump to: navigation, search
m (Switched navigation link for "Next" from an article to its navigation shell)
 
(35 intermediate revisions by 6 users not shown)
Line 1: Line 1:
[[OWASP Code Review Guide Table of Contents]]__TOC__
+
{{LinkBar
 +
  | useprev=PrevLink | prev=Security Code Review in the SDLC | lblprev=
 +
  | usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
 +
  | usenext=NextLink | next=OCRG1.1:Application Threat Modeling | lblnext=Application Threat Modeling
 +
}}
 +
__TOC__
  
Contact author: [mailto:[email protected] Eoin Keary]
+
==Understanding the Attack Surface==
 
 
 
 
==Transactional Analysis: ==
 
  
 
''“For every input there will be an equal and opposite output (Well sort of)”''
 
''“For every input there will be an equal and opposite output (Well sort of)”''
  
A Major part of actually performing a Secure Code inspection is performing a transactional analysis.
+
[[Image:Transactional_Analysis.jpg]]
An application takes inputs and produces output of some kind.
 
Attacking applications is down to using the streams for input and trying to sail a battleship up them that the application is not expecting.
 
Firstly all input to the code needs to be defined. Input for example can be:
 
* Browser input (HTTP)
 
* Cookies
 
* Other Entity  (machines/external processes).
 
* Property files
 
* ….
 
It is the input that changes the state of an application. It is the input streams attackers use to attack applications. Without any input into any system the system would be 100% secure? (probably not).
 
  
So we need to define the input points, the path the input takes in the application and any output resulting from the input received.
+
A major part of actually performing a security code review is performing an analysis of the attack surface. An application takes inputs and produces output of some kind. Attacking applications is like using the streams for input and trying to sail a battleship up them that the application is not expecting. Firstly, all input to the code needs to be identified. Input, for example, can be:
  
Transactional analysis is of paramount importance when performing code inspection. Any input stream that is overlooked may be a potential door for an attacker.
+
*Browser input
 +
*Cookies
 +
*Property files
 +
*External processes
 +
*Data feeds
 +
*Service responses
 +
*Flat files
 +
*Command line parameters
 +
*Environment variables
  
Transactional analysis includes any cookie or state information passed between the client and server and not just information inputted by the user, the payload.
+
Exploring the attack surface includes dynamic and static data flow analysis: Where and when variables are set and how the variables are used throughout the workflow, how attributes of objects and parameters might affect other data within the program. It determines if the parameters, method calls, and data exchange mechanisms implement the required security.  
  
Take into account any potential errors that can occur in the application for a given input, are the errors being caught?
+
All transactions within the application need to be identified and analyzed along with the relevant security functions they invoke. The areas that are covered during transaction analysis are:
  
Transactional Analysis includes dynamic and static data flow analysis:
+
*Data/Input Validation of data from all untrusted sources
Where and when are variables set and how the variable are used throughout the workflow, how attributes of objects and parameters might affect other data within the program. It determines if the parameters, method calls, and data exchange mechanisms implement the required security.
+
*Authentication
 +
*Session Management
 +
*Authorization
 +
*Cryptography (Data at rest and in transit)
 +
*Error Handling /Information Leakage
 +
*Logging /Auditing
 +
*Secure Code Environment
  
All transactions within the application need to be identified and analysed along with the relevant security functions they invoke.
+
== Understand What You Are Reviewing ==
The areas that are covered during transaction analysis are:
 
* Authentication
 
* Authorisation
 
* Cookie Management
 
* Data/Input Validation from all external sources.
 
* Error Handling /Information Leakage
 
* Logging /Auditing
 
* Cryptography (Data at rest and in transit)
 
* Secure Code Environment
 
* Session Management (Login/Logout)
 
  
== General principles (What to look for) ==
+
Many modern applications are developed on frameworks. These frameworks provide the developer less work to do, as the framework does much of the “Housekeeping”. The objects developed by the development team shall extend the functionality of the framework. <u>It is here that the knowledge of a given framework, and language in which the framework and application is implemented, is of paramount importance. </u> Much of the transactional functionality may not be visible in the developer’s code and handled in “Parent” classes.
  
For each of the areas above a reviewer must look at the following principles in the enforcement of the requirement:
+
The analyst must be aware and knowledgeable of the underlying framework.
  
===Authentication: ===
+
===Java===
 
+
* Ensure all internal and external connections (user and entity) go through an appropriate and adequate form of authentication. Be assured that this control cannot be bypassed.
 
* Ensure all pages enforce the requirement for authentication.
 
* Ensure that whenever authentication credentials or any other sensitive information is passed, only accept the information via the HTTP “POST” method and will not accept it via the HTTP “GET” method.
 
* Any page deemed by the business or the development team as being outside the scope of authentication should be reviewed in order to assess any possibility of security breach.
 
* Ensure that authentication credentials do not traverse the wire in clear text form.
 
* Ensure not development/debug backdoors are present in production code.
 
 
 
===Authorization: ===
 
 
 
* Ensure that there are authorization mechanisms in place.
 
* Ensure that the application has clearly defined the user types and the rights of said users.
 
* Ensure there is a least privilege stance in operation.
 
* Ensure that the Authorization mechanisms work properly, fail securely, and cannot be circumvented.
 
* Ensure that authorisation is checked on every request.
 
* Ensure not development/debug backdoors are present in production code.
 
 
 
===Cookie Management: ===
 
 
 
* Ensure that sensitive information is not comprised.
 
* Ensure that unauthorized activities cannot take place via cookie manipulation.
 
* Ensure that proper encryption is in use.
 
* Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner.
 
* Determine if all state transitions in the application code properly check for the cookies and enforce their use.
 
* Ensure the session data is being validated.
 
* Ensure cookie contains as little private information as possible.
 
* Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie.
 
* Define all cookies being used by the application, their name and why they are needed.
 
 
 
 
 
=== Data/Input Validation: ===
 
 
 
* Ensure that a DV mechanism is present.
 
* Ensure all input that can (and will) be modified by a malicious user such as http headers, input fields, hidden fields, drop down lists & other web components are properly validated.
 
* Ensure that the proper length checks on all input exist.
 
* Ensure that all fields, cookies, http headers/bodies & form fields are validated.
 
* Ensure that the data is well formed and contains only known good chars is possible.
 
* Ensure that the data validation occurs on the server side.
 
* Examine where data validation occurs and if a centralized model or decentralized model is used.
 
* Ensure there are no backdoors in the data validation model.
 
* '''''Golden Rule: All external input, no matter what it is, is examined and validated.'''''
 
 
 
 
 
 
 
===Error Handling/Information leakage: ===
 
 
 
* Ensure that all method/function calls that return a value have proper error handling and return value checking.
 
* Ensure that exceptions and error conditions are properly handled.
 
* Ensure that no system errors can be returned to the user.
 
* Ensure that the application fails in a secure manner.
 
* Ensure resources are released if an error occurs.
 
 
 
 
 
===Logging/Auditing: ===
 
 
 
* Ensure that no sensitive information is logged in the event of an error.
 
* Ensure the payload being logged is of a defined maximum length and that the logging mechanism enforces that length.
 
* Ensure no sensitive data can be logged; E.g. cookies, HTTP “GET” method, authentication credentials.
 
* Examine if the application will audit the actions being taken by the application on behalf of the client particularly and data manipulation/Create, Update, Delete (CUD) operations.
 
* Ensure successful & unsuccessful authentication is logged.
 
* Ensure application errors are logged.
 
* Examine the application for debug logging with the view to logging of sensitive data.
 
 
 
 
 
===Cryptography: ===
 
 
 
* Ensure no sensitive data is transmitted in the clear, internally or externally.
 
* Ensure the application is implementing known good cryptographic methods.
 
 
 
 
 
===Secure Code Environment: ===
 
 
 
* Examine the file structure, are any components that should not be directly accessible available to the user.
 
* Examine all memory allocations/de-allocations.
 
* Examine the application for dynamic SQL and determine is vulnerable to injection.
 
* Examine the application for “main()” executable functions and debug harnesses/backdoors
 
* Search for commented out code, commented out test code, which may contain sensitive information.
 
* Ensure all logical decisions have a default clause.
 
* Ensure no development environment kit is contained on the build directories.
 
* Search for any calls to the underlying operating system or file open calls and examine the error possibilities.
 
 
 
 
 
=== Session management: ===
 
 
 
* Examine how and when a session is created for a user, unauthenticated and authenticated.
 
* Examine the session ID and verify is a complex enough to fulfil requirements regarding strength.
 
* Examine how sessions are stored: E.g. In a database, in memory etc.
 
* Examine how the application tracks sessions.
 
* Determine the actions the application takes if an invalid session ID occurs.
 
* Examine session invalidation.
 
* Determine how multithreaded/multi-user session management is performed.
 
* Determine the session HTTP inactivity timeout.
 
* Determine how the log-out functionality functions.
 
 
 
 
 
 
 
==
 
Understand what you are reviewing: ==
 
Many modern applications are developed on frameworks. These frameworks provide the developer less work to do as the framework does much of the “House Keeping”. So the objects developed by the development team shall extend the functionality of the framework.
 
<u>It is here that the knowledge of a given framework and language which the framework and application is implemented in is of paramount importance</u>. Much of the transactional functionality may not be visible in the developers code and handled in “Parent” classes.
 
 
 
The analyst must be aware and knowledgeable of the underlying framework
 
 
 
'''For example:'''
 
 
 
===Java: ===
 
 
In struts the ''struts-config.xml'' and the ''web.xml'' files are the core points to view the transactional functionality of an application.
 
In struts the ''struts-config.xml'' and the ''web.xml'' files are the core points to view the transactional functionality of an application.
 
  
 
  <?xml version="1.0" encoding="ISO-8859-1" ?>
 
  <?xml version="1.0" encoding="ISO-8859-1" ?>
Line 169: Line 60:
 
   </global-forwards>
 
   </global-forwards>
 
   <!--  Action Mapping Definitions  -->
 
   <!--  Action Mapping Definitions  -->
   <action-mappings>
+
   <font color="blue"><action-mappings>
 
     <action
 
     <action
    path="/login"
+
        path="/login"
    type="test.struts.LoginAction" >
+
        type="test.struts.LoginAction" >
    <forward name="valid" path="/jsp/MainMenu.jsp" />
+
            <forward name="valid" path="/jsp/MainMenu.jsp" />
    <forward name="invalid" path="/jsp/LoginView.jsp" />
+
            <forward name="invalid" path="/jsp/LoginView.jsp" />
</action>
+
    </action>
   </action-mappings>
+
   </action-mappings></font>
 
  <!-- Validator Configuration -->
 
  <!-- Validator Configuration -->
  <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
+
  <font color="red"><plug-in className="org.apache.struts.validator.ValidatorPlugIn"></font>
 
   <set-property property="pathnames"
 
   <set-property property="pathnames"
 
  value="/test/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/>
 
  value="/test/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/>
Line 186: Line 77:
 
The ''struts-config.xml'' file contains the action mappings for each HTTP request while the ''web.xml'' file contains the deployment descriptor.
 
The ''struts-config.xml'' file contains the action mappings for each HTTP request while the ''web.xml'' file contains the deployment descriptor.
  
'''Example''': The struts framework has a validator engine, which relies on regular expressions to validate the input data. The beauty of the validator is that no code has to be written for each form bean. (Form bean is the java object which received the data from the HTTP request) . The validator is not enabled by default in struts. To enable the validator a plug-in must be defined in the <plug-in> section of struts-config.xml in Red above. The property defined tells the struts framework where the custom validation rules are defined (validation.xml) and a definition of the actual rules themselves (validation-rules.xml).
+
'''Example''': The struts framework has a validator engine, which relies on regular expressions to validate the input data. The beauty of the validator is that no code has to be written for each form bean. (Form bean is the Java object which received the data from the HTTP request). The validator is not enabled by default in struts. To enable the validator, a plug-in must be defined in the <plug-in> section of struts-config.xml in Red above. The property defined tells the struts framework where the custom validation rules are defined (validation.xml) and a definition of the actual rules themselves (validation-rules.xml).  
  
Without a proper understanding of the struts framework and by simply auditing the java code one would net see any validation being executed and one does not see the relationship between the defined rules and the java functions.
+
Without a proper understanding of the struts framework, and by simply auditing the Java code, one would not see any validation being executed, and one does not see the relationship between the defined rules and the Java functions.  
  
The action mappings in Blue define the action taken by the application upon receiving a request. Here, above we can see that when the URL contains /login the '''''LoginAction''''' shall be called. From the action mappings we can see the transactions the application performs when external input is received.  
+
The action mappings in Blue define the action taken by the application upon receiving a request. Here, above we can see that when the URL contains /login the LoginAction shall be called. From the action mappings we can see the transactions the application performs when external input is received.
  
===.NET: ===
+
===.NET===
ASP.NET/ IIS applications use an optional XML-based configuration file named ''web.config'', to maintain application configuration settings. This covers issues such as authentication, authorisation, Error pages, HTTP settings, debug settings, web service settings etc..
+
ASP.NET / IIS applications use an optional XML-based configuration file, named ''web.config'', to maintain application configuration settings.This covers issues such as authentication, authorization, Error pages, HTTP settings, debug settings, web service settings, etc.
  
Without knowledge of these files a transactional analysis would be very difficult and not accurate.
+
Without knowledge of these files, a transactional analysis would be very difficult and not accurate.
  
Optionally, you may provide a file ''web.config'' at the root of the virtual directory for a Web application. If the file is absent, the default configuration settings in ''machine.config'' will be used. If the file is present, any settings in ''web.config'' will override the default settings.
+
Optionally, you may provide a file ''web.config'' at the root of the virtual directory for a web application. If the file is absent, the default configuration settings in ''machine.config'' will be used. If the file is present, any settings in ''web.config'' will override the default settings.
  
Example of the web.config file:
+
Example of a web.config file:
  
 
  <authentication mode="Forms">
 
  <authentication mode="Forms">
Line 215: Line 106:
 
  </authentication>
 
  </authentication>
  
OK so from this config file snippet we can see that:
+
From this config file snippet we can see:
  
 
'''authentication mode''': The default authentication mode is  ASP.NET forms-based authentication.
 
'''authentication mode''': The default authentication mode is  ASP.NET forms-based authentication.
  
'''loginUrl: '''Specifies the URL where the request is redirected for logon if no valid authentication cookie is found.
+
'''loginUrl: '''Specifies the URL where the request is redirected for login if no valid authentication cookie is found.
  
'''protection: '''Sepcifies that the cookie is encrypted using 3DES or DES but DV is not performed on the cookie. Beware of plaintext attacks!!
+
'''protection: '''Specifies that the cookie is encrypted using 3DES or DES but DV is not performed on the cookie. Beware of plaintext attacks!!  
  
 
'''timeout: '''Cookie expiry time in minutes
 
'''timeout: '''Cookie expiry time in minutes
  
The point to make here is that many of the important security settings are not set in the code per se but in the framework configuration files.  
+
The point to make here is that many of the important security settings are not set in the code per se, but in the framework configuration files. Knowledge of the framework is of paramount importance when reviewing framework-based applications.
Knowledge of the framework is of paramount importance when reviewing framework-based applications.
 
  
 +
{{LinkBar
 +
  | useprev=PrevLink | prev=Security Code Review in the SDLC | lblprev=
 +
  | usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
 +
  | usenext=NextLink | next=Application Threat Modeling | lblnext=
 +
}}
  
 
[[Category:OWASP Code Review Project]]
 
[[Category:OWASP Code Review Project]]

Latest revision as of 15:26, 9 September 2010

«««« Main
(Table of Contents)
»»Application Threat Modeling»»

Understanding the Attack Surface

“For every input there will be an equal and opposite output (Well sort of)”

Transactional Analysis.jpg

A major part of actually performing a security code review is performing an analysis of the attack surface. An application takes inputs and produces output of some kind. Attacking applications is like using the streams for input and trying to sail a battleship up them that the application is not expecting. Firstly, all input to the code needs to be identified. Input, for example, can be:

  • Browser input
  • Cookies
  • Property files
  • External processes
  • Data feeds
  • Service responses
  • Flat files
  • Command line parameters
  • Environment variables

Exploring the attack surface includes dynamic and static data flow analysis: Where and when variables are set and how the variables are used throughout the workflow, how attributes of objects and parameters might affect other data within the program. It determines if the parameters, method calls, and data exchange mechanisms implement the required security.

All transactions within the application need to be identified and analyzed along with the relevant security functions they invoke. The areas that are covered during transaction analysis are:

  • Data/Input Validation of data from all untrusted sources
  • Authentication
  • Session Management
  • Authorization
  • Cryptography (Data at rest and in transit)
  • Error Handling /Information Leakage
  • Logging /Auditing
  • Secure Code Environment

Understand What You Are Reviewing

Many modern applications are developed on frameworks. These frameworks provide the developer less work to do, as the framework does much of the “Housekeeping”. The objects developed by the development team shall extend the functionality of the framework. It is here that the knowledge of a given framework, and language in which the framework and application is implemented, is of paramount importance. Much of the transactional functionality may not be visible in the developer’s code and handled in “Parent” classes.

The analyst must be aware and knowledgeable of the underlying framework.

Java

In struts the struts-config.xml and the web.xml files are the core points to view the transactional functionality of an application.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
         "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN"
         "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">
<struts-config>
 <form-beans>
 	<form-bean name="login" type="test.struts.LoginForm" />
 </form-beans>
 <global-forwards>
 </global-forwards>
 <action-mappings>
   <action
       path="/login"
       type="test.struts.LoginAction" >
           <forward name="valid" path="/jsp/MainMenu.jsp" />
           <forward name="invalid" path="/jsp/LoginView.jsp" />
   </action>
 </action-mappings>
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
 <set-property property="pathnames"
value="/test/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/>
</plug-in>
</struts-config>

The struts-config.xml file contains the action mappings for each HTTP request while the web.xml file contains the deployment descriptor.

Example: The struts framework has a validator engine, which relies on regular expressions to validate the input data. The beauty of the validator is that no code has to be written for each form bean. (Form bean is the Java object which received the data from the HTTP request). The validator is not enabled by default in struts. To enable the validator, a plug-in must be defined in the <plug-in> section of struts-config.xml in Red above. The property defined tells the struts framework where the custom validation rules are defined (validation.xml) and a definition of the actual rules themselves (validation-rules.xml).

Without a proper understanding of the struts framework, and by simply auditing the Java code, one would not see any validation being executed, and one does not see the relationship between the defined rules and the Java functions.

The action mappings in Blue define the action taken by the application upon receiving a request. Here, above we can see that when the URL contains /login the LoginAction shall be called. From the action mappings we can see the transactions the application performs when external input is received.

.NET

ASP.NET / IIS applications use an optional XML-based configuration file, named web.config, to maintain application configuration settings.This covers issues such as authentication, authorization, Error pages, HTTP settings, debug settings, web service settings, etc.

Without knowledge of these files, a transactional analysis would be very difficult and not accurate.

Optionally, you may provide a file web.config at the root of the virtual directory for a web application. If the file is absent, the default configuration settings in machine.config will be used. If the file is present, any settings in web.config will override the default settings.

Example of a web.config file:

<authentication mode="Forms">
  <forms name="name"
         loginUrl="url" 
         protection="Encryption"
         timeout="30" path="/" >
         requireSSL="true|"
         slidingExpiration="false">
     <credentials passwordFormat="Clear">
        <user name="username" password="password"/>
     </credentials>
  </forms>
  <passport redirectUrl="internal"/>
</authentication>

From this config file snippet we can see:

authentication mode: The default authentication mode is ASP.NET forms-based authentication.

loginUrl: Specifies the URL where the request is redirected for login if no valid authentication cookie is found.

protection: Specifies that the cookie is encrypted using 3DES or DES but DV is not performed on the cookie. Beware of plaintext attacks!!

timeout: Cookie expiry time in minutes

The point to make here is that many of the important security settings are not set in the code per se, but in the framework configuration files. Knowledge of the framework is of paramount importance when reviewing framework-based applications.


«««« Main
(Table of Contents)
»»»»