OWASP - User contributions [en]

User:Cwells

2010-02-11T20:24:37Z

Cwells:

Chris Wells wants to elevate the awareness of application security issues by teaching and encouraging developers to build applications that can defend themselves against the serious types of threats that exist on the Internet today.

Over his career, Chris has deployed security solutions for major healthcare, telecommunication, and financial industries, and is currently employed as an Information Security Architect for a major manufacturing company. He is an accomplished application security architect with over 10 years of application security experience.

Chris holds multiple security certifications including a Certified Information Security Systems Professional (CISSP), and holds a Bachelor degree from the University of Minnesota.

Searching for Code in J2EE/Java

2007-07-10T15:26:10Z

Cwells:

== Searching for key indicators ==
The basis of the code review is to locate and analyse areas of code which may have application security implications.
Assuming the code reviewer has a thorough understanding of the code, what it is intended to do and the context upon which it is to be used, firstly one needs to sweep the code base for areas of interest.

This can be done by performing a text search on the code base looking for keywords relating to API's and functions.
Below is a guide for .NET framework 1.1 & 2.0

=== Searching for code in .NET ===

Firstly one needs to be familiar with the tools one can use in order to perform text searching following on from this one need to know what to look for.

In this section we will assume you have a copy of Visual Studio (VS) .NET at hand. VS has two types of search "'''Find in Files'''" and a cmd line tool called '''Findstr'''

The test search tools in XP is not great in my experience and if one has to use this make sure SP2 in installed as it works better.
To start off one should scan thorough the code looking for common patterns or keywords such as "User", "Password", "Pswd", "Key", "Http", etc...
This can be done using the "Find in Files" tool in VS or using findstring as follows:

[Find In Files HERE]

'''findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*'''

====Architectural Analysis====
If we can identify major architectural components within that application (right away) it can help narrow our search, and we can then look for known vulnerabilities in those components and frameworks:

### Ajax
XMLHTTP
### Struts
org.apache.struts
### Spring
org.springframework
### Java Server Faces (JSF)
import javax.faces
### Hibernate
import org.hibernate
### Castor
org.exolab.castor
### JAXB
javax.xml
### JMS
JMS

====Http Request Strings====
Requests from external sources are onviously a key area of a secure code review. We need to ensure that all HTTP requests received are datavalidated for composition, max and min length and if the data falls with the relms of the parameter whitelist.
Bottom-line is this is a key area to look at and ensure security is enabled.

request.querystring
request.form
request.cookies
request.certificate
request.servervariables
request.IsSecureConnection
request.TotalBytes
request.BinaryRead

====HTML Output====
Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks result from poor response validation. XSS relies on this somewhat.

response.write
<% =
HttpUtility
HtmlEncode
UrlEncode
innerText
innerHTML

====Ajax and JavaScript====
Look for Ajax usage, and possible JavaScript issues:

document.write
eval(
document.cookie
window.location
document.URL
XMLHTTP
window.createRequest

====SQL & Database====
Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determine if the application is vulnerable to SQL injection. One aspect of this is to verify that the code uses either ''SqlParameter'', ''OleDbParameter'', or ''OdbcParameter''(System.Data.SqlClient). These are typed and treats parameters as the literal value and not executable code in the database.

exec sp_executesql
execute sp_executesql
select from
Insert
update
delete from where
delete
exec sp_
execute sp_
exec xp_
execute sp_
exec @
execute @
executestatement
executeSQL
setfilter
executeQuery
GetQueryResultInXML
adodb
sqloledb
sql server
driver
Server.CreateObject
.Provider
.Open
ADODB.recordset
New OleDbConnection
ExecuteReader
DataSource
SqlCommand
Microsoft.Jet
SqlDataReader
ExecuteReader
GetString
SqlDataAdapter
CommandType
StoredProcedure
System.Data.sql

====Cookies====
Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionality as this would have a bearing on session security.
System.Net.Cookie
HttpOnly
document.cookie

==== HTML Tags====
Many of the HTML tags below can be used for client side attacks such as cross site scritping. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display and use of such tags withing a web application.

HtmlEncode
URLEncode
<applet>
<frameset>
<embed>
<frame>
<html>
<iframe>
<img>
<style>
<layer>
<ilayer>
<meta>
<object>
<body>
<frame security
<iframe security

====Input Controls====
The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application.

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

====web.config====
The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation.

requestEncoding
responseEncoding
trace
authorization
CustomErrors
httpRuntime
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
authentication mode
allow
deny
credentials
identity impersonate
timeout

====global.asax====
Each application has its own Global.asax if one is required. Global.asax sets the event code and values for an application using scripts. One must ensure that application variables do not contain sensitive information, as they are accessible to the whole application and to all users within it.

Application_OnAuthenticateRequest
Application_OnAuthorizeRequest
Session_OnStart
Session_OnEnd

====logging====
Logging can be a source of information leakage. It is important to examing all calls to the logging subsystem and to determine if any sensitive information is being logged. Common mistakes are logging userID in conjunction with passwords within the authentication functionality or logging database requests which may contains sensitive data.

log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace

====Machine.config====
Its important that many variables in machine.config can be overridden in the web.config file for a particular application.
validateRequest
enableViewState
enableViewStateMac

====Threads and Concurrancy====
Locating code that contains multithreaded functions. Concurrancy issues can result in race conditions which may result in security vulnerabilities. The Thread keyword is where new threads objects are created. Code that uses static global variables which hold sensitive security information may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threads call Dispose at the same time, this may cause resource release issues.

Thread
Dispose

====Class Design====
Public and Sealed relate to the design at class level. Classes whicch are not intended to be derived from should be sealed. Make sure all class fields are Public for a reason. Dont expose anything you dont need to.

Public
Sealed

====Reflection, Serialization====
Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized.

Serializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity
System.Reflection

====Exceptions & Errors====
Ensure that the catch blocks do not leak information to the user in the case of an exception. Ensure when dealing with resources that the finally block is used. Having trace enabled is not great from an information leakage perspective. Ensure custonised errors are properly implemented.

catch{
Finally
trace enabled
customErrors mode

====Crypto====
If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are passwords that are being persisted hashed, they should be.
How are random numbers generated? Is the PRNG "random enough"?

RNGCryptoServiceProvider
SHA
MD5
base64
xor
DES
RC2
System.Random
Random
System.Security.Cryptography

====Storage====
If storing sensitive data in memory recommend one uses the following.
SecureString
ProtectedMemory

====Authorization, Assert & Revert====
Bypassing the code access security permission? Not a good idea. Also below is a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR.

.RequestMinimum
.RequestOptional
Assert
Debug.Assert
CodeAccessPermission
ReflectionPermission.MemberAccess
SecurityPermission.ControlAppDomain
SecurityPermission.UnmanagedCode
SecurityPermission.SkipVerification
SecurityPermission.ControlEvidence
SecurityPermission.SerializationFormatter
SecurityPermission.ControlPrincipal
SecurityPermission.ControlDomainPolicy
SecurityPermission.ControlPolicy

====Leagcy methods====
printf
strcpy

=== Searching for code in J2EE/Java ===

====Input Streams====
Java.io
FileInputStream
ObjectInputStream
FilterInputStream
PipedInputStream
SequenceInputStream
StringBufferInputStream
BufferedReader
ByteArrayInputStream
CharArrayReader
File
ObjectInputStream
PipedInputStream
StreamTokenizer
getResourceAsStream

====Servlets====
javax.servlet.
getParameterNames
getParameterValues
getAttribute
getAttributeNames
isSecure
HttpServletRequest
getQueryString
getHeader
getPrincipal
isUserInRole
getOutputStream
getWriter
addCookie
addHeader
setHeader

====SQL & Database====
Searching for Java Database related code this list should help you pinpoint classes/methods which are involved in the persistance layer of the application being reviewed.
jdbc
executeQuery
select
insert
update
delete
execute
executestatement
====SSL====
com.sun.net.ssl
SSLContext
SSLSocketFactory
TrustManagerFactory
HttpsURLConnection
KeyManagerFactory

====Session Management====
getSession
invalidate
getId

====Data Validation====

====Legacy Interaction====

====Crypto====

====Security Manager====

====System====

====Logging====

====Other====
Developers say the darnedest things in their source code. Look for the following keywords as pointers to possible software vulnerabilities:

Hack
Kludge
Bypass
Steal
Stolen
Divert
Broke
Trick
Fix
ToDo

Searching for Code in J2EE/Java

2007-07-10T15:06:11Z

Cwells:

== Searching for key indicators ==
The basis of the code review is to locate and analyse areas of code which may have application security implications.
Assuming the code reviewer has a thorough understanding of the code, what it is intended to do and the context upon which it is to be used, firstly one needs to sweep the code base for areas of interest.

This can be done by performing a text search on the code base looking for keywords relating to API's and functions.
Below is a guide for .NET framework 1.1 & 2.0

=== Searching for code in .NET ===

Firstly one needs to be familiar with the tools one can use in order to perform text searching following on from this one need to know what to look for.

In this section we will assume you have a copy of Visual Studio (VS) .NET at hand. VS has two types of search "'''Find in Files'''" and a cmd line tool called '''Findstr'''

The test search tools in XP is not great in my experience and if one has to use this make sure SP2 in installed as it works better.
To start off one should scan thorough the code looking for common patterns or keywords such as "User", "Password", "Pswd", "Key", "Http", etc...
This can be done using the "Find in Files" tool in VS or using findstring as follows:

[Find In Files HERE]

'''findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*'''

====Http Request Strings====
Requests from external sources are onviously a key area of a secure code review. We need to ensure that all HTTP requests received are datavalidated for composition, max and min length and if the data falls with the relms of the parameter whitelist.
Bottom-line is this is a key area to look at and ensure security is enabled.

request.querystring
request.form
request.cookies
request.certificate
request.servervariables
request.IsSecureConnection
request.TotalBytes
request.BinaryRead

====HTML Output====
Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks result from poor response validation. XSS relies on this somewhat.

response.write
<% =
HttpUtility
HtmlEncode
UrlEncode
innerText
innerHTML

====Ajax and JavaScript====
Look for Ajax usage, and possible JavaScript issues:

document.write
eval(
document.cookie
window.location
document.URL
XMLHTTP
window.createRequest

====SQL & Database====
Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determine if the application is vulnerable to SQL injection. One aspect of this is to verify that the code uses either ''SqlParameter'', ''OleDbParameter'', or ''OdbcParameter''(System.Data.SqlClient). These are typed and treats parameters as the literal value and not executable code in the database.

exec sp_executesql
execute sp_executesql
select from
Insert
update
delete from where
delete
exec sp_
execute sp_
exec xp_
execute sp_
exec @
execute @
executestatement
executeSQL
setfilter
executeQuery
GetQueryResultInXML
adodb
sqloledb
sql server
driver
Server.CreateObject
.Provider
.Open
ADODB.recordset
New OleDbConnection
ExecuteReader
DataSource
SqlCommand
Microsoft.Jet
SqlDataReader
ExecuteReader
GetString
SqlDataAdapter
CommandType
StoredProcedure
System.Data.sql

====Cookies====
Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionality as this would have a bearing on session security.
System.Net.Cookie
HttpOnly
document.cookie

==== HTML Tags====
Many of the HTML tags below can be used for client side attacks such as cross site scritping. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display and use of such tags withing a web application.

HtmlEncode
URLEncode
<applet>
<frameset>
<embed>
<frame>
<html>
<iframe>
<img>
<style>
<layer>
<ilayer>
<meta>
<object>
<body>
<frame security
<iframe security

====Input Controls====
The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application.

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

====web.config====
The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation.

requestEncoding
responseEncoding
trace
authorization
CustomErrors
httpRuntime
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
authentication mode
allow
deny
credentials
identity impersonate
timeout

====global.asax====
Each application has its own Global.asax if one is required. Global.asax sets the event code and values for an application using scripts. One must ensure that application variables do not contain sensitive information, as they are accessible to the whole application and to all users within it.

Application_OnAuthenticateRequest
Application_OnAuthorizeRequest
Session_OnStart
Session_OnEnd

====logging====
Logging can be a source of information leakage. It is important to examing all calls to the logging subsystem and to determine if any sensitive information is being logged. Common mistakes are logging userID in conjunction with passwords within the authentication functionality or logging database requests which may contains sensitive data.

log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace

====Machine.config====
Its important that many variables in machine.config can be overridden in the web.config file for a particular application.
validateRequest
enableViewState
enableViewStateMac

====Threads and Concurrancy====
Locating code that contains multithreaded functions. Concurrancy issues can result in race conditions which may result in security vulnerabilities. The Thread keyword is where new threads objects are created. Code that uses static global variables which hold sensitive security information may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threads call Dispose at the same time, this may cause resource release issues.

Thread
Dispose

====Class Design====
Public and Sealed relate to the design at class level. Classes whicch are not intended to be derived from should be sealed. Make sure all class fields are Public for a reason. Dont expose anything you dont need to.

Public
Sealed

====Reflection, Serialization====
Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized.

Serializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity
System.Reflection

====Exceptions & Errors====
Ensure that the catch blocks do not leak information to the user in the case of an exception. Ensure when dealing with resources that the finally block is used. Having trace enabled is not great from an information leakage perspective. Ensure custonised errors are properly implemented.

catch{
Finally
trace enabled
customErrors mode

====Crypto====
If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are passwords that are being persisted hashed, they should be.
How are random numbers generated? Is the PRNG "random enough"?

RNGCryptoServiceProvider
SHA
MD5
base64
xor
DES
RC2
System.Random
Random
System.Security.Cryptography

====Storage====
If storing sensitive data in memory recommend one uses the following.
SecureString
ProtectedMemory

====Authorization, Assert & Revert====
Bypassing the code access security permission? Not a good idea. Also below is a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR.

.RequestMinimum
.RequestOptional
Assert
Debug.Assert
CodeAccessPermission
ReflectionPermission.MemberAccess
SecurityPermission.ControlAppDomain
SecurityPermission.UnmanagedCode
SecurityPermission.SkipVerification
SecurityPermission.ControlEvidence
SecurityPermission.SerializationFormatter
SecurityPermission.ControlPrincipal
SecurityPermission.ControlDomainPolicy
SecurityPermission.ControlPolicy

====Leagcy methods====
printf
strcpy

=== Searching for code in J2EE/Java ===

====Input Streams====
Java.io
FileInputStream
ObjectInputStream
FilterInputStream
PipedInputStream
SequenceInputStream
StringBufferInputStream
BufferedReader
ByteArrayInputStream
CharArrayReader
File
ObjectInputStream
PipedInputStream
StreamTokenizer
getResourceAsStream

====Servlets====
javax.servlet.
getParameterNames
getParameterValues
getAttribute
getAttributeNames
isSecure
HttpServletRequest
getQueryString
getHeader
getPrincipal
isUserInRole
getOutputStream
getWriter
addCookie
addHeader
setHeader

====SQL & Database====
Searching for Java Database related code this list should help you pinpoint classes/methods which are involved in the persistance layer of the application being reviewed.
jdbc
executeQuery
select
insert
update
delete
execute
executestatement
====SSL====
com.sun.net.ssl
SSLContext
SSLSocketFactory
TrustManagerFactory
HttpsURLConnection
KeyManagerFactory

====Session Management====
getSession
invalidate
getId

====Data Validation====

====Legacy Interaction====

====Crypto====

====Security Manager====

====System====

====Logging====

====Other====
Developers say the darnedest things in their source code. Look for the following keywords as pointers to possible software vulnerabilities:

Hack
Kludge
Bypass
Steal
Stolen
Divert
Broke
Trick
Fix
ToDo

Searching for Code in J2EE/Java

2007-07-10T14:56:46Z

Cwells:

== Searching for key indicators ==
The basis of the code review is to locate and analyse areas of code which may have application security implications.
Assuming the code reviewer has a thorough understanding of the code, what it is intended to do and the context upon which it is to be used, firstly one needs to sweep the code base for areas of interest.

This can be done by performing a text search on the code base looking for keywords relating to API's and functions.
Below is a guide for .NET framework 1.1 & 2.0

=== Searching for code in .NET ===

Firstly one needs to be familiar with the tools one can use in order to perform text searching following on from this one need to know what to look for.

In this section we will assume you have a copy of Visual Studio (VS) .NET at hand. VS has two types of search "'''Find in Files'''" and a cmd line tool called '''Findstr'''

The test search tools in XP is not great in my experience and if one has to use this make sure SP2 in installed as it works better.
To start off one should scan thorough the code looking for common patterns or keywords such as "User", "Password", "Pswd", "Key", "Http", etc...
This can be done using the "Find in Files" tool in VS or using findstring as follows:

[Find In Files HERE]

'''findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*'''

====Http Request Strings====
Requests from external sources are onviously a key area of a secure code review. We need to ensure that all HTTP requests received are datavalidated for composition, max and min length and if the data falls with the relms of the parameter whitelist.
Bottom-line is this is a key area to look at and ensure security is enabled.

request.querystring
request.form
request.cookies
request.certificate
request.servervariables
request.IsSecureConnection
request.TotalBytes
request.BinaryRead

====HTML Output====
Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks result from poor response validation. XSS relies on this somewhat.

response.write
<% =
HttpUtility
HtmlEncode
UrlEncode
innerText
innerHTML

====SQL & Database====
Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determine if the application is vulnerable to SQL injection. One aspect of this is to verify that the code uses either ''SqlParameter'', ''OleDbParameter'', or ''OdbcParameter''(System.Data.SqlClient). These are typed and treats parameters as the literal value and not executable code in the database.

exec sp_executesql
execute sp_executesql
select from
Insert
update
delete from where
delete
exec sp_
execute sp_
exec xp_
execute sp_
exec @
execute @
executestatement
executeSQL
setfilter
executeQuery
GetQueryResultInXML
adodb
sqloledb
sql server
driver
Server.CreateObject
.Provider
.Open
ADODB.recordset
New OleDbConnection
ExecuteReader
DataSource
SqlCommand
Microsoft.Jet
SqlDataReader
ExecuteReader
GetString
SqlDataAdapter
CommandType
StoredProcedure
System.Data.sql

====Cookies====
Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionality as this would have a bearing on session security.
System.Net.Cookie
HttpOnly
document.cookie

==== HTML Tags====
Many of the HTML tags below can be used for client side attacks such as cross site scritping. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display and use of such tags withing a web application.

HtmlEncode
URLEncode
<applet>
<frameset>
<embed>
<frame>
<html>
<iframe>
<img>
<style>
<layer>
<ilayer>
<meta>
<object>
<body>
<frame security
<iframe security

====Input Controls====
The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application.

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

====web.config====
The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation.

requestEncoding
responseEncoding
trace
authorization
CustomErrors
httpRuntime
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
authentication mode
allow
deny
credentials
identity impersonate
timeout

====global.asax====
Each application has its own Global.asax if one is required. Global.asax sets the event code and values for an application using scripts. One must ensure that application variables do not contain sensitive information, as they are accessible to the whole application and to all users within it.

Application_OnAuthenticateRequest
Application_OnAuthorizeRequest
Session_OnStart
Session_OnEnd

====logging====
Logging can be a source of information leakage. It is important to examing all calls to the logging subsystem and to determine if any sensitive information is being logged. Common mistakes are logging userID in conjunction with passwords within the authentication functionality or logging database requests which may contains sensitive data.

log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace

====Machine.config====
Its important that many variables in machine.config can be overridden in the web.config file for a particular application.
validateRequest
enableViewState
enableViewStateMac

====Threads and Concurrancy====
Locating code that contains multithreaded functions. Concurrancy issues can result in race conditions which may result in security vulnerabilities. The Thread keyword is where new threads objects are created. Code that uses static global variables which hold sensitive security information may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threads call Dispose at the same time, this may cause resource release issues.

Thread
Dispose

====Class Design====
Public and Sealed relate to the design at class level. Classes whicch are not intended to be derived from should be sealed. Make sure all class fields are Public for a reason. Dont expose anything you dont need to.

Public
Sealed

====Reflection, Serialization====
Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized.

Serializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity
System.Reflection

====Exceptions & Errors====
Ensure that the catch blocks do not leak information to the user in the case of an exception. Ensure when dealing with resources that the finally block is used. Having trace enabled is not great from an information leakage perspective. Ensure custonised errors are properly implemented.

catch{
Finally
trace enabled
customErrors mode

====Crypto====
If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are passwords that are being persisted hashed, they should be.
How are random numbers generated? Is the PRNG "random enough"?

RNGCryptoServiceProvider
SHA
MD5
base64
xor
DES
RC2
System.Random
Random
System.Security.Cryptography

====Storage====
If storing sensitive data in memory recommend one uses the following.
SecureString
ProtectedMemory

====Authorization, Assert & Revert====
Bypassing the code access security permission? Not a good idea. Also below is a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR.

.RequestMinimum
.RequestOptional
Assert
Debug.Assert
CodeAccessPermission
ReflectionPermission.MemberAccess
SecurityPermission.ControlAppDomain
SecurityPermission.UnmanagedCode
SecurityPermission.SkipVerification
SecurityPermission.ControlEvidence
SecurityPermission.SerializationFormatter
SecurityPermission.ControlPrincipal
SecurityPermission.ControlDomainPolicy
SecurityPermission.ControlPolicy

====Leagcy methods====
printf
strcpy

=== Searching for code in J2EE/Java ===

====Input Streams====
Java.io
FileInputStream
ObjectInputStream
FilterInputStream
PipedInputStream
SequenceInputStream
StringBufferInputStream
BufferedReader
ByteArrayInputStream
CharArrayReader
File
ObjectInputStream
PipedInputStream
StreamTokenizer
getResourceAsStream

====Servlets====
javax.servlet.
getParameterNames
getParameterValues
getAttribute
getAttributeNames
isSecure
HttpServletRequest
getQueryString
getHeader
getPrincipal
isUserInRole
getOutputStream
getWriter
addCookie
addHeader
setHeader

====SQL & Database====
Searching for Java Database related code this list should help you pinpoint classes/methods which are involved in the persistance layer of the application being reviewed.
jdbc
executeQuery
select
insert
update
delete
execute
executestatement
====SSL====
com.sun.net.ssl
SSLContext
SSLSocketFactory
TrustManagerFactory
HttpsURLConnection
KeyManagerFactory

====Session Management====
getSession
invalidate
getId

====Data Validation====

====Legacy Interaction====

====Crypto====

====Security Manager====

====System====

====Logging====

====Other====
Developers say the darnedest things in their source code. Look for the following keywords as pointers to possible software vulnerabilities:

Hack
Kludge
Bypass
Steal
Stolen
Divert
Broke
Trick
Fix
ToDo

User:Cwells

2006-06-13T13:32:54Z

Cwells:

Chris Wells wants to elevate the awareness of application security issues by teaching and encouraging developers to build applications that can defend themselves against the serious types of threats that exist on the Internet today.

Over his career, Chris has deployed security solutions for major healthcare, telecommunication, and financial industries, and is currently employed as an Information Security Consultant for a major financial institution. He is an accomplished application security architect with over 10 years of application security experience.

Chris holds multiple security certifications including a Certified Information Security Systems Professional (CISSP), and holds a Bachelor degree from the University of Minnesota.

Code Review Introduction

2006-06-13T13:27:30Z

Cwells: /* The Checklist */

[[OWASP Code Review Guide Table of Contents]]__TOC__

==Preface==

This document is not a “How to perform a Secure Code review” walkthrough but more a guide on how to perform a successful review. Knowing the mechanics of code inspection is a half the battle but I’m afraid people is the other half.

To Perform a proper code review, to give value to the client from a risk perspective and not from an academic or text book perspective we must understand what we are reviewing.

Applications may have faults but the client wants to know the “real risk” and not necessarily what the security textbooks say.

Albeit there are real vulnerabilities in real applications out there and they pose real risk but how do we define real risk as opposed to best practice?

This document describes how to get the most out of a secure code review. What is important when managing an engagement with a client and how to keep your eye on the ball the see the “wood from the trees”.

== Introduction ==

The only possible way of developing secure software and keeping it secure going into the future is to make security part of the design. When cars are designed safety is considered and now a big selling point for people buying a new car, “How safe is it?” would be a question a potential buyer may ask, also look at the advertising referring to the “Star” rating for safety a brand/model of car has.

Unfortunately the software industry is not as evolved and hence people still buy software without paying any regard to the security aspect of the application.

This is what OWASP are trying to do; to bring security in web application development into the mainstream, to make it a selling point. 30% to 35% of Microsoft’s budget for “Longhorn” is earmarked for security, a sign of the times. <u>http://news.bbc.co.uk/2/hi/business/4516269.stm</u>

Every day more and more vulnerabilities are discovered in popular applications, which we all know and use and even use for private transactions over the web.

I’m writing this document not from a purest point of view. Not everything you may agree with but from experience it is rare that we can have the luxury of being a purest in the real world.

Many forces in the business world do not see value in spending a proportion of the budget in security and factoring some security into the project timeline.

The usual one liners we hear in the wilderness:

''“We never get hacked (that I know of), we don’t need security” ''

''“We never get hacked, we got a firewall”.''

''Question: “How much does security cost”? Answer: “How much shall no security cost”?''

''"Not to know is bad; not to wish to know is worse."''

'' - I love proverbs as you can see.''

Code inspection is a fairly low-level approach to securing code but is very effective.

==The Basics: What we know we don’t know and what we know we know. ==

===What is Secure Code Review? ===

Secure code review is the process of auditing code for an application on a line by line basis for its security quality. Code review is a way of ensuring that the application is developed in an appropriate fashion so as to be “self defending” in its given environment.

Secure Code review is a method of assuring secure application developers are following secure development techniques. A general rule of thumb is that a pen test should not discover any additional application vulnerabilities relating to the developed code after the application has undergone a proper secure code review.

Secure code review is a manual process. It is labour intensive and not very scalable but it is accurate if performed by humans (and not tools, so far).

Tools can be used to perform this task but they always need human verification. Tools do not understand context, which is the keystone of secure code review. Tools are good at assessing large amounts of code and pointing out possible issues but a person needs to verify every single result and also figure out the false positives and worse again the false negatives.

There are many source code review tool vendors out there but I have yet to see the “Silver bullet” which does not cost the price of a small island off the west coast of Ireland.

Code review can be broken down into a number of discrete phases.

# Discovery (Pre Transaction analysis).
# Transactional analysis.
# Post transaction analysis.
# Procedure peer review.
# Reporting & Presentation.

===Laying the ground work ===

(Ideally the reviewer should be involved in the design phase of the application, but this is not always possible so we assume the reviewer was not.)

There are two scenarios to look at.

# The security consultant was involved since project inception and has guided and helped integrate security into the SDLC.
# The security consultant is brought into the project near project end and is presented with a mountain of code, has no insight into the design, functionality or business requirements.

So we’ve got 100K lines of code for secure code inspection, how do we handle this?

The most important step is collaboration with developers. Obtaining information from the developers is the most time saving method for performing an accurate code review in a timely manner.

Performing code review can feel like an audit, and everybody hates being audited. The way to approach this is to create an atmosphere of collaboration between the reviewer, the development team & vested interests. Portraying an image of an advisor and not a policeman is very important if you wish to get full co-operation from the development team.

“''Help me help you''” is the approach and ideal that needs to be communicated.

===Discovery: Gathering the information ===

As mentioned above talking to developers is arguably the most accurate and definitely the quickest way of gaining insight into the application.

A culture of collaboration between the security analyst and the development team is important to establish.

Other artefacts required would be design documents, business requirements, functional specifications and any other relating information.

'''Before we start:'''

The reviewer(s) need to be familiar with:
# '''Code''': The language used, the features and issues of that language form a security perspective. The issues one needs to look out for and best practices from a security and performance perspective.
# '''Context''': They need to be familiar with the application being reviewed. All security is in context of what we are trying to secure. Recommending military standard security mechanisms on an application that vends apples would be over-kill, and out of context. What type of data is being manipulated or processed and what would the damage to the company be if this data was compromised. Context is the “''Holy Grail''” of secure code inspection and risk assessment…we’ll see more later.
# '''Audience''': From 2 (above) we need to know the users of the application, is it externally facing or internal to “Trusted” users. Does this application talk to other entities (machines/services). Do humans use this application?
# '''Importance''': The availability of the application is also important. Shall the enterprise be affected in any great way if the application is “bounced” or shut down for a significant or insignificant amount of time?

===Context, Context, Context ===

The context in which the application is intended to operate is a very important issue in establishing potential risk.

Defining context should provide us with the following information:
*Establish the importance of application to enterprise.
*Establish the boundaries of the application context.
*Establish the trust relationships between entities.
*Establish potential threats and possible countermeasures.

So we can establish something akin to a threat model. Take into account where our application sits, what its expected to do and who uses it.

Simple questions like:

“'''''What type/how sensitive is the data/Asset contained in the application?'''''”:

This is a keystone to security and assessing possible risk to the application. How desirable is the information? What effect would it have on the enterprise if the information were compromised in any way?

“'''''Is the application internal or external facing?'''''”, “'''''Who uses the application, are they trusted users?'''”''

This is a bit of a false sense of security as attacks take place by internal/trusted users more often than is acknowledged. It does give us context that the application ''should'' be limited to a finite number of identified users but its not a guarantee that these users shall all behave properly!!”

''“'''Where does the application host sit'''?”''

Users should not be allowed past the DMZ into the LAN without being authenticated. Internal users also need to be authenticated. No authentication = no accountability and a weak audit trail.

If there are internal and external users, what are the differences from a security standpoint? How do we identify one from another. How does authorisation work?

“'''''How important is this application to the enterprise?'''''”.

Is the application of minor significance or a Tier A / Mission critical application, which the enterprise would fail without. Any good web application development policy would have additional requirements for different applications of differing importance to the enterprise. It would be the analyst’s job to ensure the policy was followed from a code perspective also.

A useful approach is to present the team with a checklist, which asks the relevant, questions pertaining to any web application.:

===The Checklist ===

Defining a generic checklist which can be filled out by the development team is of high value is the checklist asks the correct questions in order to give us context. The checklist should cover the “Usual Suspects” in application security such as:

* Authentication
* Authorization
* Data Validation (a''nother “holy grail”'')
* Session management
* Logging
* Error handling
* Cryptography
* Topology (where is this app in the network context).

An example can be found:

<u>http://www.owasp.org/docroot/owasp/misc/designreviewchecklist.doc</u>

The checklist is a good barometer for the level of security the developers have attempted or thought of.

[[Category:OWASP Code Review Project]]