OWASP - User contributions [en]

Reviewing Code for Buffer Overruns and Overflows

2007-01-17T23:30:05Z

TBeattie: /* Good Patterns & procedures to prevent buffer overflows: */ fix the formatting of the example code

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

==The buffer ==

A Buffer is an amount of contiguous memory set aside for storing information. Example: A program has to remember certain things, like what your shopping cart contains or what data was inputted prior to the current operation this information is stored in memory in a buffer.

==How to locate the potentially vulnerable code==

In locating potentially vulnerable code from a buffer overflow standpoint one should look for particular signatures such as:

'''Arrays''':
int x[20];
int y[20][5];
int x[20][5][3];

'''Format Strings:'''
printf() ,fprintf(), sprintf(), snprintf().
%x, %s, %n, %d, %u, %c, %f

'''Over flows:'''

strcpy (), strcat (), sprintf (), vsprintf ()

==Vulnerable Patterns for buffer overflows==

===‘Vanilla’ buffer overflow: ===

Example: A program might want to keep track of the days of the week (7). The programmer tells the computer to store a space for 7 numbers. This is an example of a buffer. But what happens if an attempt to add 8 numbers is performed?
Languages such as C and C++ do not perform bounds checking and therefore if the program is written in such a language the 8th piece of data would overwrite the program space of the next program in memory would result in data corruption.
This can cause the program to crash at a minimum or a carefully crafted overflow can cause malicious code to be executed, as the overflow payload is actual code.

void copyData(char *userId) {
char smallBuffer['''10''']; // size of 10
'''strcpy'''(smallBuffer, userId);
}
int main(int argc, char *argv[]) {
char *userId = "'''01234567890'''"; // Payload of 11
copyData (userId); // this shall cause a buffer overload
}

Buffer overflows are the result of stuffing more code into a buffer than it is meant to hold.

===The Format String: ===
A format function is a function within the ANSI C specification. It can be used to tailor primitive C data types to human readable form. They are used in nearly all C programs to output information, print error messages, or process strings.

Some format parameters:

%x hexadecimal (unsigned int)
%s string ((const) (unsigned) char *)
%n number of bytes written so far, (* int)
%d decimal (int)
%u unsigned decimal (unsigned int)

Example:

printf ("Hello: %s\n", a273150);

The %s in this case ensures that the parameter (a273150) is printed as a string.

Through supplying the format string to the format function we are able
to control the behaviour of it. So supplying input as a format string makes our application do things its not meant to! What exactly are we able to make the application do?

===Crashing an application: ===

printf (User_Input);

If we supply %x (hex unsigned int) as the input, the '''printf''' function shall expect to find an integer relating to that format string, but no argument exists. This can not be detected at compile time. At runtime this issue shall surface.

===Walking the stack: ===
For every % in the argument the printf function finds it assumes that there is an associated value on the stack. In this way the function walks the stack downwards reading the corresponding values from the stack and printing them to user

Using format strings we can execute some invalid pointer access by using a format string such as:

printf ("%s%s%s%s%s%s%s%s%s%s%s%s");

Worse again is using the '''%n''' directive in '''printf()'''. This directive takes an '''int*''' and '''writes''' the number of bytes so far to that location.

Where to look for this potential vulnerability. This issue is prevalent with the '''printf()''' family of functions, '''printf(),fprintf(), sprintf(), snprintf().''' Also '''syslog()''' (writes system log information) and setproctitle(''const char *fmt'', ''...''); (which sets the string used to display process identifier information).

===Integer overflows: ===

#include <stdio.h>

int main(void){
int val;
val = 0x7fffffff; /* 2147483647*/
printf("val = %d (0x%x)\n", val, val);
printf("val + 1 = %d (0x%x)\n", val + 1 , val + 1); /*Overflow the int*/
return 0;
}

The binary representation of 0x7fffffff is 1111111111111111111111111111111; this integer is initialised with the highest positive value a signed long integer can hold.

Here when we add 1 to the hex value of 0x7fffffff the value of the integer overflows and goes to a negative number (0x7fffffff + 1 = 80000000)
In decimal this is (-2147483648). Think of the problems this may cause!!
Compilers will not detect this and the application will not notice this issue.

We get these issues when we use signed integers in comparisons or in arithmetic and also comparing signed integers with unsigned integers

Example:

int myArray[100];

int fillArray(int v1, int v2){
if(v2 > sizeof(myArray) / sizeof(int)){
return -1; /* Too Big !! */
}
myArray [v2] = v1;
return 0;
}

Here if v2 is a massive negative number so the '''''if '''''condition shall pass. This condition checks to see if v2 is bigger than the array size.
The line '''myArray[v2] = v1''' assigns the value v1 to a location out of the bounds of the array causing unexpected results.

== Good Patterns & procedures to prevent buffer overflows: ==

Example:

void copyData(char *userId) {
char smallBuffer[10]; // size of 10
strncpy(smallBuffer, userId, 10); // only copy first 10 elements
}

int main(int argc, char *argv[]) {
char *userId = "01234567890"; // Payload of 11
copyData (userId); // this shall cause a buffer overload
}

The code above is not vulnerable to buffer overflow as the copy functionality uses a specified length, 10.

C library functions such as '''strcpy (), strcat (), sprintf ()''' and '''vsprintf ()''' operate on null terminated strings and perform no bounds checking. '''gets ()''' is another function that reads input (into a buffer) from stdin until a terminating newline or EOF (End of File) is found. The '''scanf ()''' family of functions also may result in buffer overflows.

Using strncpy(), strncat(), snprintf(), and fgets() all mitigate this problem by specifying the maximum string length.

Always check the bounds of an array before writing it to a buffer.

==.NET & Java ==

C# or C++ code in the .NET framework can be immune to buffer overflows if the code is ''managed''. Managed code is code executed by a .NET virtual machine, such as Microsoft's. Before the code is run, the Intermediate Language is compiled into native code. The managed execution environments own runtime-aware complier performs the compilation; therefore the managed execution environment can guarantee what the code is going to do. The Java development language also does not suffer from buffer overflows; as long as native methods or system calls are not invoked, buffer overflows are not an issue.

[[Category:OWASP Code Review Project]]

Talk:Reviewing Code for Buffer Overruns and Overflows

2007-01-17T23:25:44Z

TBeattie: Please remove statement about %n

Under "Walking the stack", the statement "the %n directive in printf()... takes an int* and writes the number of bytes so far to that location" is incorrect. "%n" is defined for the sscanf() function, but not for printf()... unless somebody knows of a non-standard implementation of C which does behave in this way, in which case that implementation should be identified.

Reviewing Code for Buffer Overruns and Overflows

2007-01-17T23:19:05Z

TBeattie: /* Crashing an application: */ fix the example

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

==The buffer ==

A Buffer is an amount of contiguous memory set aside for storing information. Example: A program has to remember certain things, like what your shopping cart contains or what data was inputted prior to the current operation this information is stored in memory in a buffer.

==How to locate the potentially vulnerable code==

In locating potentially vulnerable code from a buffer overflow standpoint one should look for particular signatures such as:

'''Arrays''':
int x[20];
int y[20][5];
int x[20][5][3];

'''Format Strings:'''
printf() ,fprintf(), sprintf(), snprintf().
%x, %s, %n, %d, %u, %c, %f

'''Over flows:'''

strcpy (), strcat (), sprintf (), vsprintf ()

==Vulnerable Patterns for buffer overflows==

===‘Vanilla’ buffer overflow: ===

Example: A program might want to keep track of the days of the week (7). The programmer tells the computer to store a space for 7 numbers. This is an example of a buffer. But what happens if an attempt to add 8 numbers is performed?
Languages such as C and C++ do not perform bounds checking and therefore if the program is written in such a language the 8th piece of data would overwrite the program space of the next program in memory would result in data corruption.
This can cause the program to crash at a minimum or a carefully crafted overflow can cause malicious code to be executed, as the overflow payload is actual code.

void copyData(char *userId) {
char smallBuffer['''10''']; // size of 10
'''strcpy'''(smallBuffer, userId);
}
int main(int argc, char *argv[]) {
char *userId = "'''01234567890'''"; // Payload of 11
copyData (userId); // this shall cause a buffer overload
}

Buffer overflows are the result of stuffing more code into a buffer than it is meant to hold.

===The Format String: ===
A format function is a function within the ANSI C specification. It can be used to tailor primitive C data types to human readable form. They are used in nearly all C programs to output information, print error messages, or process strings.

Some format parameters:

%x hexadecimal (unsigned int)
%s string ((const) (unsigned) char *)
%n number of bytes written so far, (* int)
%d decimal (int)
%u unsigned decimal (unsigned int)

Example:

printf ("Hello: %s\n", a273150);

The %s in this case ensures that the parameter (a273150) is printed as a string.

Through supplying the format string to the format function we are able
to control the behaviour of it. So supplying input as a format string makes our application do things its not meant to! What exactly are we able to make the application do?

===Crashing an application: ===

printf (User_Input);

If we supply %x (hex unsigned int) as the input, the '''printf''' function shall expect to find an integer relating to that format string, but no argument exists. This can not be detected at compile time. At runtime this issue shall surface.

===Walking the stack: ===
For every % in the argument the printf function finds it assumes that there is an associated value on the stack. In this way the function walks the stack downwards reading the corresponding values from the stack and printing them to user

Using format strings we can execute some invalid pointer access by using a format string such as:

printf ("%s%s%s%s%s%s%s%s%s%s%s%s");

Worse again is using the '''%n''' directive in '''printf()'''. This directive takes an '''int*''' and '''writes''' the number of bytes so far to that location.

Where to look for this potential vulnerability. This issue is prevalent with the '''printf()''' family of functions, '''printf(),fprintf(), sprintf(), snprintf().''' Also '''syslog()''' (writes system log information) and setproctitle(''const char *fmt'', ''...''); (which sets the string used to display process identifier information).

===Integer overflows: ===

#include <stdio.h>

int main(void){
int val;
val = 0x7fffffff; /* 2147483647*/
printf("val = %d (0x%x)\n", val, val);
printf("val + 1 = %d (0x%x)\n", val + 1 , val + 1); /*Overflow the int*/
return 0;
}

The binary representation of 0x7fffffff is 1111111111111111111111111111111; this integer is initialised with the highest positive value a signed long integer can hold.

Here when we add 1 to the hex value of 0x7fffffff the value of the integer overflows and goes to a negative number (0x7fffffff + 1 = 80000000)
In decimal this is (-2147483648). Think of the problems this may cause!!
Compilers will not detect this and the application will not notice this issue.

We get these issues when we use signed integers in comparisons or in arithmetic and also comparing signed integers with unsigned integers

Example:

int myArray[100];

int fillArray(int v1, int v2){
if(v2 > sizeof(myArray) / sizeof(int)){
return -1; /* Too Big !! */
}
myArray [v2] = v1;
return 0;
}

Here if v2 is a massive negative number so the '''''if '''''condition shall pass. This condition checks to see if v2 is bigger than the array size.
The line '''myArray[v2] = v1''' assigns the value v1 to a location out of the bounds of the array causing unexpected results.

== Good Patterns & procedures to prevent buffer overflows: ==

Example:

void copyData(char *userId) {
char smallBuffer[10]; // size of 10
strncpy(smallBuffer, userId, 10); // only copy first 10 elements
}

int main(int argc, char *argv[]) {
char *userId = "01234567890"; // Payload of 11
copyData (userId); // this shall cause a buffer overload
}

The code above is not vulnerable to buffer overflow as the copy functionality uses a specified length, 10.

C library functions such as '''strcpy (), strcat (), sprintf ()''' and '''vsprintf ()''' operate on null terminated strings and perform no bounds checking. '''gets ()''' is another function that reads input (into a buffer) from stdin until a terminating newline or EOF (End of File) is found. The '''scanf ()''' family of functions also may result in buffer overflows.
Using strncpy(), strncat(), snprintf(), and fgets() all mitigate this problem by specifying the expected input.

Always check the bounds of an array before writing it to a buffer.

==.NET & Java ==

C# or C++ code in the .NET framework can be immune to buffer overflows if the code is ''managed''. Managed code is code executed by a .NET virtual machine, such as Microsoft's. Before the code is run, the Intermediate Language is compiled into native code. The managed execution environments own runtime-aware complier performs the compilation; therefore the managed execution environment can guarantee what the code is going to do. The Java development language also does not suffer from buffer overflows; as long as native methods or system calls are not invoked, buffer overflows are not an issue.

[[Category:OWASP Code Review Project]]

Reviewing Code for Buffer Overruns and Overflows

2007-01-17T23:16:59Z

TBeattie: /* The Format String: */ typo

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

==The buffer ==

A Buffer is an amount of contiguous memory set aside for storing information. Example: A program has to remember certain things, like what your shopping cart contains or what data was inputted prior to the current operation this information is stored in memory in a buffer.

==How to locate the potentially vulnerable code==

In locating potentially vulnerable code from a buffer overflow standpoint one should look for particular signatures such as:

'''Arrays''':
int x[20];
int y[20][5];
int x[20][5][3];

'''Format Strings:'''
printf() ,fprintf(), sprintf(), snprintf().
%x, %s, %n, %d, %u, %c, %f

'''Over flows:'''

strcpy (), strcat (), sprintf (), vsprintf ()

==Vulnerable Patterns for buffer overflows==

===‘Vanilla’ buffer overflow: ===

Example: A program might want to keep track of the days of the week (7). The programmer tells the computer to store a space for 7 numbers. This is an example of a buffer. But what happens if an attempt to add 8 numbers is performed?
Languages such as C and C++ do not perform bounds checking and therefore if the program is written in such a language the 8th piece of data would overwrite the program space of the next program in memory would result in data corruption.
This can cause the program to crash at a minimum or a carefully crafted overflow can cause malicious code to be executed, as the overflow payload is actual code.

void copyData(char *userId) {
char smallBuffer['''10''']; // size of 10
'''strcpy'''(smallBuffer, userId);
}
int main(int argc, char *argv[]) {
char *userId = "'''01234567890'''"; // Payload of 11
copyData (userId); // this shall cause a buffer overload
}

Buffer overflows are the result of stuffing more code into a buffer than it is meant to hold.

===The Format String: ===
A format function is a function within the ANSI C specification. It can be used to tailor primitive C data types to human readable form. They are used in nearly all C programs to output information, print error messages, or process strings.

Some format parameters:

%x hexadecimal (unsigned int)
%s string ((const) (unsigned) char *)
%n number of bytes written so far, (* int)
%d decimal (int)
%u unsigned decimal (unsigned int)

Example:

printf ("Hello: %s\n", a273150);

The %s in this case ensures that the parameter (a273150) is printed as a string.

Through supplying the format string to the format function we are able
to control the behaviour of it. So supplying input as a format string makes our application do things its not meant to! What exactly are we able to make the application do?

===Crashing an application: ===

printf (“%s”, User_Input);

If we supply %x (hex unsigned int) as the input, the '''printf''' function shall expect to find an integer relating to that format string but no argument exists. This can not be detected at compile time. At runtime this issue shall surface.

===Walking the stack: ===
For every % in the argument the printf function finds it assumes that there is an associated value on the stack. In this way the function walks the stack downwards reading the corresponding values from the stack and printing them to user

Using format strings we can execute some invalid pointer access by using a format string such as:

printf ("%s%s%s%s%s%s%s%s%s%s%s%s");

Worse again is using the '''%n''' directive in '''printf()'''. This directive takes an '''int*''' and '''writes''' the number of bytes so far to that location.

Where to look for this potential vulnerability. This issue is prevalent with the '''printf()''' family of functions, '''printf(),fprintf(), sprintf(), snprintf().''' Also '''syslog()''' (writes system log information) and setproctitle(''const char *fmt'', ''...''); (which sets the string used to display process identifier information).

===Integer overflows: ===

#include <stdio.h>

int main(void){
int val;
val = 0x7fffffff; /* 2147483647*/
printf("val = %d (0x%x)\n", val, val);
printf("val + 1 = %d (0x%x)\n", val + 1 , val + 1); /*Overflow the int*/
return 0;
}

The binary representation of 0x7fffffff is 1111111111111111111111111111111; this integer is initialised with the highest positive value a signed long integer can hold.

Here when we add 1 to the hex value of 0x7fffffff the value of the integer overflows and goes to a negative number (0x7fffffff + 1 = 80000000)
In decimal this is (-2147483648). Think of the problems this may cause!!
Compilers will not detect this and the application will not notice this issue.

We get these issues when we use signed integers in comparisons or in arithmetic and also comparing signed integers with unsigned integers

Example:

int myArray[100];

int fillArray(int v1, int v2){
if(v2 > sizeof(myArray) / sizeof(int)){
return -1; /* Too Big !! */
}
myArray [v2] = v1;
return 0;
}

Here if v2 is a massive negative number so the '''''if '''''condition shall pass. This condition checks to see if v2 is bigger than the array size.
The line '''myArray[v2] = v1''' assigns the value v1 to a location out of the bounds of the array causing unexpected results.

== Good Patterns & procedures to prevent buffer overflows: ==

Example:

void copyData(char *userId) {
char smallBuffer[10]; // size of 10
strncpy(smallBuffer, userId, 10); // only copy first 10 elements
}

int main(int argc, char *argv[]) {
char *userId = "01234567890"; // Payload of 11
copyData (userId); // this shall cause a buffer overload
}

The code above is not vulnerable to buffer overflow as the copy functionality uses a specified length, 10.

C library functions such as '''strcpy (), strcat (), sprintf ()''' and '''vsprintf ()''' operate on null terminated strings and perform no bounds checking. '''gets ()''' is another function that reads input (into a buffer) from stdin until a terminating newline or EOF (End of File) is found. The '''scanf ()''' family of functions also may result in buffer overflows.
Using strncpy(), strncat(), snprintf(), and fgets() all mitigate this problem by specifying the expected input.

Always check the bounds of an array before writing it to a buffer.

==.NET & Java ==

C# or C++ code in the .NET framework can be immune to buffer overflows if the code is ''managed''. Managed code is code executed by a .NET virtual machine, such as Microsoft's. Before the code is run, the Intermediate Language is compiled into native code. The managed execution environments own runtime-aware complier performs the compilation; therefore the managed execution environment can guarantee what the code is going to do. The Java development language also does not suffer from buffer overflows; as long as native methods or system calls are not invoked, buffer overflows are not an issue.

[[Category:OWASP Code Review Project]]

Code Review Introduction

2007-01-17T23:07:20Z

TBeattie: /* Introduction */ typo

[[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 is 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 puristic point of view. Not everything you may agree with but from experience it is rare that we can have the luxury of being a purist 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. None have created a “silver bullet” at a reasonable cost. Vendor tools that are effective cost upwards around $60,000 USD per developer seat.

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 from 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]]