OWASP - User contributions [en]

Category:OWASP Code Review Project

2006-06-09T08:38:03Z

Eoin: /* Roadmap */

== Project Contributors ==

The OWASP Code Review project was concieved by Eoin Keary the OWASP Ireland Founder and Chapter Lead.
We are actively seeking techies to add new sections as new web technologies emerge.
If you are interested in volunteering for the project, or have a comment, question, or suggestion, please drop me a line mailto:eoin.keary@owasp.org

==Volunteers Needed==

Yes please, drop me a line.
Need help on this one, dont be shy, all help appreciated

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

==Roadmap==

View the [[OWASP Code Review Project Roadmap]]

[[Category:OWASP Project]]

Security Code Review Coverage

2006-06-09T08:37:07Z

Eoin:

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

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

==Transactional Analysis: ==

''“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.
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.

Transactional analysis is of paramount importance when performing code inspection. Any input stream that is overlooked may be a potential door for an attacker.

Transactional analysis includes any cookie or state information passed between the client and server and not just information inputted by the user, the payload.

Take into account any potential errors that can occur in the application for a given input, are the errors being caught?

Transactional Analysis includes dynamic and static data flow analysis:
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.

All transactions within the application need to be identified and analysed along with the relevant security functions they invoke.
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) ==

For each of the areas above a reviewer must look at the following principles in the enforcement of the requirement:

===Authentication: ===

* 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.

<?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 net 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, authorisation, 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 the 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>

OK so from this config file snippet we can see that:

'''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.

'''protection: '''Sepcifies 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.

[[Category:OWASP Code Review Project]]

Reviewing Code for SQL Injection

2006-06-09T08:36:32Z

Eoin:

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

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL Injection Example: ==

String DRIVER = "com.ora.jdbc.Driver";

String DataURL = "jdbc:db://localhost:5112/users";

String LOGIN = "admin";

String PASSWORD = "admin123";

Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request

String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;

String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {

iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}

PrintWriter writer = response.getWriter ();

if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {

writer.println ("Access Denied!")
}

When SQL statements are dynamically created as software executes, there is an opportunity for a
security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" Username + "' AND Password = '" + Password + "'";

== .NET ==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;

using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();

SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);

sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;

//specify param type

sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);

sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc

}

'''Stored procedures don’t always protect against SQL injection:'''

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™

Lets pass it.

DROP TABLE ORDERS;

Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Security Code Review Coverage

2006-06-09T08:35:38Z

Eoin:

[[OWASP Code Review Guide Table of Contents]]

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

==Transactional Analysis: ==

''“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.
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.

Transactional analysis is of paramount importance when performing code inspection. Any input stream that is overlooked may be a potential door for an attacker.

Transactional analysis includes any cookie or state information passed between the client and server and not just information inputted by the user, the payload.

Take into account any potential errors that can occur in the application for a given input, are the errors being caught?

Transactional Analysis includes dynamic and static data flow analysis:
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.

All transactions within the application need to be identified and analysed along with the relevant security functions they invoke.
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) ==

For each of the areas above a reviewer must look at the following principles in the enforcement of the requirement:

===Authentication: ===

* 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.

<?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 net 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, authorisation, 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 the 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>

OK so from this config file snippet we can see that:

'''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.

'''protection: '''Sepcifies 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.

[[Category:OWASP Code Review Project]]

The Secure Code Environment

2006-06-09T08:35:11Z

Eoin:

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

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

==Secure Code Environment ==

Another important thing to be aware of is when you receive the code make sure it is identical in deployment layout to what would go to production. Having great code but it being deployed in unprotected folders on the application server is not a great idea.
Attackers do code reviews also and what better than to code review the potential target application.
For example: try in “'''''Google'''''”:
<u>http://www.google.com/search?q=%0D%0Aintitle%3Aindex.of+WEB-INF</u>

This lists exposed “''Web-Inf''” directories on WebSphere®, Tomcat and other app servers.

''The WEB-INF directory tree contains web application classes, pre-compiled JSP files, server side libraries, session information and files such as '''web.xml''' and '''webapp.properties'''. ''

So be sure the code base is identical to production. Ensuring that we have a “''secure code environment''” is also an important part of an application secure code inspection.

The code may be “bullet proof” but if it is accessible to a user this may cause other problems. Remember the developer is not the only one to perform code reviews, attackers also do this. The only visible surface that a user should see are the “suggestions” rendered by the browser upon receiving the HTML from the backend server. Any request to the backend server outside the strict context of the application should be refused and not be visible. Generally think of ''“That which is not explicitly granted is denied”''.

Example of the Tomcat web.xml to prevent directory indexing:

<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>readonly</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

So to deny access to all directories we put:

<Directory />
Order Deny,Allow
Deny from All
</Directory>

And then override this for the directories we require access to:

Also in Apache HTTP server to ensure directories like WEB-INF and META-INF are protected the following should be added to the ''httpd.conf'', the main configuration file for the Apache web server

<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>

On Apache servers, if we wish to specify permissions for a directory and subdirectories we add a '''''.htaccess''''' file.

To protect the .htaccess file itself we palce:

<Files .htaccess>
order allow,deny
deny from all
</Files>

To stop directory indexing we place the following directive into the .htaccess file:
'''IndexIgnore *'''
The * is a wildcard to prevent all files from being indexed.

== Protecting JSP pages ==

If using the Struts framework we do not want users access any JSP page directly. Accessing the JSP directly without going through the request processor can enable the attacker to view any server-side code in the JSP.
Lets say initial page can is a HTML document. So the HTTP GET from the browser retrieves this page. Any subsequent page must go through the framework.
Add the following lines to the '''web.xml''' file to prevent users from accessing any JSP page directly:

<web-app>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>no_access</web-resource-name>
<url-pattern>*.jsp</url-pattern>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
...
</web-app>

With this directive in '''web.xml''' a HTTP request for a JSP page directly will fail.

== A clean environment ==

When reviewing the environment we must see if the directories contain any artefacts from development. These files may not be referenced in any way and hence the application server gives no protection to them. Files such as .'''bak, .old, .tmp''' etc should be removed as they contain source code.

Source code should not go into production directories. The complied class files are all that is required in most cases. All source code should be removed and only the “executables” should remain.

No development tools should be present on a production environment. For example a java application should only need a JRE (Java Runtime Environment) and not a JDK (Java Development Kit) to function.

Test and debug code should be removed from all source code and configuration files. Even commented out code should be removed as a precaution. Test code can contain backdoors that circumvent the workflow in the application and at worst contain valid authentication credentials or account details.

Comments on code and Meta tags pertaining to the IDE used or technology used to develop the application should be removed. Some comments can divulge important information regarding bugs in code or pointers to functionality. This is particularly important with client side code such as JSP’s and ASP files.

A copyright and confidentiality statement should be at the top of every file. This mitigates any confusion regarding who owns the code. This may seem trivial but it is important to state who owns the code.

To sum up, code review includes looking at the configuration of the application server and not just the code. Knowledge of the server in question is important and information is easily available on the web.

[[Category:OWASP Code Review Project]]

OS Injection

2006-06-09T08:34:17Z

Eoin:

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

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

== Introduction ==

Injection flaws allow attackers to pass malicious code through a web application to another sub system.
Depending on the subsystem different types of injection attack can be performed:
RDBMS: SQL Injection
WebBrowser/Appserver: SQL Injection
OS-shell: Operating system commands Calling external applications from your application.

==How to locate the potentially vulnerable code ==

Many developers believe text fields are the only areas for data validation. This is an incorrect assumption. Any external input must be data validated:

Text fields, List boxes, radio buttons, check boxes, cookies, HTTP header data, HTTP post data, hidden fields, parameter names and parameter values.
… This is not an exhaustive list.

“Process to process” or “entity-to-entity” communication must be investigated also. Any code that communicates with an upstream or downstream process and accepts input from said entity must be reviewed.

All injection flaws are input validation errors. The presence if an injection flaw is an indication of incorrect data validation on the input received from an external source our outside the boundary of trust, which gets more blurred every year.

Basically for this type of vulnerability we need to find all input streams into the application. This can be from a users browser, CLI or fat client but also from upstream processes that “feed” our application.

An example would be to search the code base for the use of API’s or packages that are normally used for communication purposes.

The '''java.io''', '''java.sql''', '''java.net''', '''java.rmi''', '''java.xml''' packages are all used for application communication. Searching for methods from those packages in the code base can yield results. A less “scientific” method is to search for common keywords such as “UserID”, “LoginID” or “Password”.

== Vulnerable Patterns for OS injection ==
What we should be looking for is relationships between the application and the operating system. The application utilising functions of the underlying operating system.

In java using the Runtime object, '''java.lang.Runtime''' does this.
In .NET calls such as '''System.Diagnostics.Process.Start '''are used to call underlying OS functions.
In PHP we may look for calls such as '''exec()''' or '''passthru()'''.

'''Example''':

We have a class that eventually gets input from the user via a HTTP request.
This class is used to execute some native exe on the application server and return a result.

public class DoStuff {
public string executeCommand(String userName)
{ try {
String myUid = userName;
Runtime rt = Runtime.getRuntime();
rt.exec("doStuff.exe " +”-“ +myUid); // Call exe with userID
}catch(Exception e)
{
e.printStackTrace();
}
}
}

Ok, so the method executeCommand calls '''''doStuff.exe''''' via the '''''java.lang.runtime''''' static method '''''getRuntime()'''''. The parameter passed is not validated in any way in this class. We are assuming that the data has not been data validated prior to calling this method. ''Transactional analysis should have encountered any data validation prior to this point.''
Inputting “Joe69” would result in the following MS DOS command:
'''''doStuff.exe –Joe69'''''
Lets say we input '''''Joe69 & netstat –a''''' we would get the following response:
The exe doStuff would execute passing in the User Id Joe69, but then the dos command '''''netstat''''' would be called. How this works is the passing of the parameter “&” into the application, which in turn is used as a command appender in MS DOS and hence the command after the & character is executed.

UNIX:
An attacker might insert the string '''“; cat /etc/hosts”''' the contents of the UNIX hosts file might be exposed to the attacker.

.NET Example:
namespace ExternalExecution
{
class CallExternal
{
static void Main(string[] args)
{
String arg1=args[0];
System.Diagnostics.Process.Start("doStuff.exe", arg1);
}
}
}

Yet again there is no data validation to speak of here. Assuming no upstream validation occurring in another class.

These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Complete scripts written in perl, python, shell, bat and other languages can be injected into poorly designed web applications and executed.

==Good Patterns & procedures to prevent OS injection==

See the Data Validation section.

==Related Articles==
[[Interpreter Injection]]

[[Category:OWASP Code Review Project]]
[[Category:Attack]]
[[Category:Input Validation]]

Error Handling

2006-06-09T08:33:11Z

Eoin:

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

==Error, Exception handling & Logging. ==

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

An important aspect of secure application development is to prevent information leakage. Error messages give an attacker great insight into the inner workings of an application.

The purpose of reviewing the Error Handling code is to assure the application fails safely under all possible error conditions, expected and unexpected. No sensitive information is presented to the user when an error occurs.

For example SQL injection is much tougher to successfully pull off without some healthy error messages. It lessens the attack footprint and our attacker would have to resort to use “blind SQL injection” which is more difficult and time consuming.

A well-planned error/exception handling strategy is important for three reasons:

# Good error handling does not give an attacker any information which is a means to an end, attacking the application
# A proper centralised error strategy is easier to maintain and reduces the chance of any uncaught errors “Bubbling up” to the front end of an application.
# Information leakage can lead to social engineering exploits.

Some development languages provide checked exceptions which mean that the compiler shall complain if an exception for a particular API call is not caught Java and C# are good examples of this.
Languages like C++ and C do not provide this safety net. Languages with checked exception handling still are prone to information leakage as not all types of error are checked for.

When an exception or error is thrown we also need to log this occurrence. Sometimes this is due to bad development, but it can be the result of an attack or some other service your application relies on failing.

All code paths that can cause an exception to be thrown should check for success in order for the exception not to be thrown.

To avoid a NullPointerException we should check is the object being accessed is not null.

==Generic error messages==

We should use a localized description string in every exception, a friendly error reason such as “System Error – Please try again later”. When the user sees an error message, it will be derived from this description string of the exception that was thrown, and never from the exception class which may contain a stack trace, line number where the error occurred, class name or method name.

Do not expose sensitive information in exception messages. Information such as paths on the local file system is considered privileged information; any system internal information should be hidden from the user. As mentioned before an attacker could use this information to gather private user information from the application or components that make up the app.

Don’t put people’s names or any internal contact information in error messages. Don’t put any “human” information, which would lead to a level of familiarity and a social engineering exploit.

==How to locate the potentially vulnerable code==

===JAVA===

In java we have the concept of an error object, the Exception object.
This lives in the java package java.lang and is derived from the Throwable object
Exceptions are thrown when an abnormal occurrence has occurred. Another object derived from Throwable is the Error object, which is thrown when something more serious occurs.

Information leakage can occur when developers use some exception methods, which ‘bubble’ to the user UI due to a poor error handling strategy.
The methods are as follows:
printStackTrace()
getStackTrace()

Also another object to look at is the java.lang.system package:

setErr() and the System.err field.

===.NET===

In .NET a System.Exception object exists. Commonly used child objects such as ApplicationException and SystemException are used.
It is not recommended that you throw or catch a SystemException this is thrown by runtime.

When an error occurs, either the system or the currently executing application reports it by throwing an exception containing information about the error, similar to java. Once thrown, an exception is handled by the application or by the default exception handler.
This Exception object contains similar methods to the java implementation such as:

StackTrace
Source
Message
HelpLink

In .NET we need to look at the error handling strategy from the point of view of global error handling and the handling of unexpected errors. This can be done in many ways and this article is not an exhaustive list.
Firstly an Error Event is thrown when an unhandled exception is thrown. This is part of the TemplateControl class.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWebUITemplateControlClassErrorTopic.asp

==Error handling can be done in three ways in .NET==

*In the web.config file's customErrors section.
*In the global.asax file's Application_Error sub.
*On the aspx or associated codebehind page in the Page_Error sub

The order of error handling events in .NET is as follows:
# On the Page in the Page_Error sub.
# The global.asax Application_Error sub
# The web.config file

It is recommended to look in these areas to understand the error strategy of the application.

==Vulnerable Patterns for Error Handling==

===Page_Error===

Page_Error is page level handling which is run on the server side.
Below is an example but the error information is a little too informative and hence bad practice.

'''FIXME: code formatting'''

<nowiki>

<script language="C#" runat="server">

Sub Page_Error(Source As Object, E As EventArgs)

Dim message As String = "<font face=verdana color=red><h1>" & Request.Url.ToString()& "</h1>" &

"<pre><font color='red'>" & Server.GetLastError().ToString()& "</pre></font>"

Response.Write(message) // display message

End Sub

</script>

</nowiki>

The red text in the example above has a number of issues:
Firstly it redisplays the HTTP request to the user in the form of Request.Url.ToString() Assuming there has been no data validation prior to this point we are vulnerable to cross site scripting attacks!! Secondly the error message and stack trace is displayed to the user using Server.GetLastError().ToString() which divulges internal information regarding the application.

After the Page_Error is called, the Application_Error sub is called:

===Global.asax===

When an error occurs, the Application_Error sub is called. In this method we can
log the error and redirect to another page.

<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(Object sender, EventArgs e) {
String Message = "\n\nURL: http://localhost/" + Request.Path
+ "\n\nMESSAGE:\n " + Server.GetLastError().Message
+ "\n\nSTACK TRACE:\n" + Server.GetLastError().StackTrace;
// Insert into Event Log
EventLog Log = new EventLog();
Log.Source = LogName;
Log.WriteEntry(Message, EventLogEntryType.Error);
Server.Redirect(Error.htm) // this shall also clear the error
}
</script>

Above is an example of code in Global.asax and the Application_Error method.
The error is logged and then the user is redirected. Unvalidated parameters are being
logged here in the form of Request.Path. Care must be taken not to log or redisplay
unvalidated input from any external source.

===Web.config===
Web.config has a custom errors tag which can be used to handle errors. This is called last and if Page_error or Application_error called and has functionality that functionality shall be executed first. As long as the previous two handling mechanisms do not redirect or clear (Response.Redirect or a Server.ClearError) this shall be called. And you shall be forwarded to the page defined in web.config

<customErrors defaultRedirect="error.html" mode="On|Off|RemoteOnly">
<error statusCode="statuscode" redirect="url"/>
</customErrors>

The “On" directive means that custom errors are enabled. If no defaultRedirect is specified, users see a generic error.
"Off" directive means that custom errors are disabled. This allows display of detailed errors.
"RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.

<customErrors mode="On" defaultRedirect="error.html">
<error statusCode="500" redirect="err500.aspx"/>
<error statusCode="404" redirect="notHere.aspx"/>
<error statusCode="403" redirect="notAuthz.aspx"/>
</customErrors>

==Try & Catch (Java/ .NET)==

Code that might throw exceptions should be in a try block and code that handles exceptions in a catch block.
The catch block is a series of statements beginning with the keyword catch, followed by an exception type and an action to be taken. These are very similar in Java and .NET

Example:

Java Try-Catch:

public class DoStuff {
public static void Main() {
try {
StreamReader sr = File.OpenText("stuff.txt");
Console.WriteLine("Reading line {0}", sr.ReadLine());
}
catch(Exception e) {
Console.WriteLine("An error occurred. Please leave to room”);
logerror(“Error: “, e);
}
}
}

.NET try – catch

public void run() {
while (!stop) {
try {

// Perform work here

} catch (Throwable t) {
// Log the exception and continue
WriteToUser(“An Error has occurred, put the kettle on”);
logger.log(Level.SEVERE, "Unexception exception", t);
}
}
}

In general, it is best practice to catch a specific type of exception rather than use the basic catch(Exception) or catch(Throwable) statement in the case of Java.

==Releasing resources and good housekeeping==

If the language in question has a finally method use it. The finally method is guaranteed to always be called. The finally method can be used to release resources referenced by the method that threw the exception. This is very important. An example would be if a method gained a database connection from a pool of connections and an exception occurred without finally the connection object shall not be returned to the pool for some time (until the timeout). This can lead to pool exhaustion. finally() is called even if no exception is thrown.

try {
System.out.println("Entering try statement");
out = new PrintWriter(new FileWriter("OutFile.txt"));
//Do Stuff….

} catch (Exception e) {
System.err.println("Error occurred!”);

} catch (IOException e) {
System.err.println("Input exception ");

} finally {

if (out != null) {
out.close(); // RELEASE RESOURCES
}
}

A Java example showing finally() being used to release system resources.

==Centralised exception handling (Struts Example)==

Building an infrastructure for consistent error reporting proves more difficult than error handling.
Struts provides the ActionMessages & ActionErrors classes for maintaining a stack of error messages to be reported, which can be used with JSP tags like <html: error> to display these error messages to the user.

To report a different severity of a message in a different manner (like error, warning, or information) the following tasks are required:

* Register, instantiate the errors under the appropriate severity
* Identify these messages and show them in a constant manner.

Struts ActionErrors class makes error handling quite easy:

ActionErrors errors = new ActionErrors()
errors.add("fatal", new ActionError("...."));
errors.add("error", new ActionError("...."));
errors.add("warning", new ActionError("...."));
errors.add("information", new ActionError("...."));
saveErrors(request,errors); // Important to do this

Now we have added the errors we display them by using tags in the HTML page.

<logic:messagePresent property="error">
<html:messages property="error" id="errMsg" >
<bean:write name="errMsg"/>
</html:messages>
</logic:messagePresent >

==Logging==

Logging is the recording of information into storage that details who performed what and when they did it (like an audit trail) This can also cover debug messages implemented during development as well as any messages reflecting problems or states within the application. It should be an audit of everything that the business deems important to track about the applications use. Logging provides a detective method to ensure that the other security mechanisms being used are performing correctly.

Logging should be at least done at the following events:

Authentication: Successful & unsuccessful attempts.
Authorization requests.
Data manipulation: Any (CUD) Create, Update, Delete actions performed on the application.
Session activity: Termination/Logout events.

A good logging strategy should include the recording of any errors that occur in the application.
The application should have the ability to detect and record possible malicious use such as events that cause unexpected errors or defy the state model of the application. Users who attempt to get access to data that they shouldn’t, and incoming data that does not meet validation rules or has been tampered with. In general any error condition which could not occur without an attempt by the user to circumvent the application logic.

Logging should give us the information required to form a proper audit trail of a users actions.
Leading from this the date/time the actions were performed would be useful.
Logging functionality should not log a any personal or sensitive data pertaining to the user of function at hand that is being recorded; An example of this if your application is accepting HTTP GET the payload is in the URL and the GET shall be loged. This may result in logging sensitive data.

Logging should follow best practice regarding data validation; maximum length of information, malicious characters….
We should ensure that logging functionality only log’s messages of a reasonable length and that this length is enforced.

Common open source logging solutions:
Log4J: http://logging.apache.org/log4j/docs/index.html

Log4net: http://logging.apache.org/log4net/

Commons Logging: http://jakarta.apache.org/commons/logging/index.html

In Tomcat(5.5), if no custom logger is defined (log4J) then everything is logged via Commons Logging and ultimately ends up in catalina.out.
catalina.out grows endlessly and does not recycle/rollover. Log4J provides “Rollover” functionality, which limits the size of the log. Log4J also gives the option to specify “appenders” which can redirect the log data to other destinations such as a port, syslog or even a database or JMS.

The parts of log4J which should be considered apart from the actual data being logged by the application are contained in the log4j.properties file:

#
# Configures Log4j as the Tomcat system logger
#

#
# Configure the logger to output info level messages into a rolling log file.
#
log4j.rootLogger=INFO, R

#
# To continue using the "catalina.out" file (which grows forever),
# comment out the above line and uncomment the next.
#
#log4j.rootLogger=ERROR, A1

#
# Configuration for standard output ("catalina.out").
#
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
#
# Print the date in ISO 8601 format
#
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

#
# Configuration for a rolling log file ("tomcat.log").
#
log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
log4j.appender.R.DatePattern='.'yyyy-MM-dd
#
# Edit the next line to point to your logs directory.
# The last part of the name is the log file name.
#
log4j.appender.R.File=/usr/local/tomcat/logs/tomcat.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
#
# Print the date in ISO 8601 format
#
log4j.appender.R.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

#
# Application logging options
#
#log4j.logger.org.apache=DEBUG
#log4j.logger.org.apache=INFO
#log4j.logger.org.apache.struts=DEBUG
#log4j.logger.org.apache.struts=INFO

[[Category:OWASP Code Review Project]]

Data Validation (Code Review)

2006-06-09T08:32:01Z

Eoin:

[[OWASP Code Review Guide Table of Contents]]__TOC__
Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

==Canoncalization of input. ==

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>

''(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).''

URL encoded: %3C%73%63%72%69%70%74%3E

Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.1 delves much more into this subject.

==Data validation strategy ==

A general rule is to accept only “'''Known Good'''” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “'''Known bad'''”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

There are a number of models to think about when designing a data validation strategy, which are listed from the strongest to the weakest as follows.

# '''Exact Match''' (Constrain)
# '''Known Good''' (Accept)
# '''Reject Known bad''' (Reject)
# '''Encode Known bad''' (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.

'''Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.'''

* '''Exact Match''': (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

* '''Known Good''': If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

* '''Reject Known bad''': We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

* '''Encode Known Bad''': This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

'''HTML-encoding and URL-encoding user input when writing back to the client'''. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

==Good Patterns for Data validation ==

===Data Validation examples ===

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
'''preg_grep()''' could also be used for a '''''True''''' or '''''False''''' result. This would enable us to let “'''''only known good'''''” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

<u>http://www.regxlib.com/CheatSheet.aspx</u>

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

===Framework Example:(Struts 1.2) ===
In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

# Enables us to have a central area for data validation.
# Provides us with a data validation framework.

What to look for when examining struts is as follows:

The struts-config.xml file must contain the following:


<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/technology/WEB-INF/
validator-rules.xml, /WEB-INF/validation.xml"/>
</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {
private String username;
private String password;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}

Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm"
type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="'''username'''"
depends="'''required'''">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.

The “depends” directive dictates that the parameter is required. If this is blank the error defined in '''Application.properties'''. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.
The developer would need to take this a step further by validating the input via regular expression:
<field property="username"
depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>
Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true" staticJavascript="true" />

===Framework example:(.NET)===
The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past.
The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).
What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

'''''"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."'''''

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:
* RequiredFieldValidator – Makes the associated input control a required field.
* CompareValidator – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.
* RangeValidator – Checks if the value of an input control is within a defined range of values.
* RegularExpressionValidator – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server
ControlToValidate=Name ErrorMessage="User ID is required."> *
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>
<asp:RegularExpressionValidator runat=server display=dynamic
controltovalidate="Name"
errormessage="ID must be 6-8 letters."
validationexpression="[a-zA-Z0-9]{6,8}" />
</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

==Length Checking==

Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.

Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.
If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.
If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

==Never Rely on Client-Side Data Validation ==

''Client-side validation can always be bypassed.''
''Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript? ''
''Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.''
'''Remember: Data validation must be always done on the server side.'''
'''A code review focuses on server side code. Any client side security code is not and cannot be considered security.'''

Data validation of parameter names:

When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as
'' UserId =3o1nk395y''
'' password=letMeIn123''

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (''UserId'',''password'' from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

==Web services data validation==

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:complexType name="AddressIn">
<xsd:sequence>
<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>
<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>
<xsd:element name="county" type="TenANumeric" nillable="false"/>
<xsd:element name="town" type="TenANumeric" nillable="true"/>
<xsd:element name="userId" type="TenANumeric" nillable="false"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="HundredANumeric">
'''<xsd:restriction base="xsd:string">'''
<xsd:minLength value="1"/>
<xsd:maxLength value="100"/>
<xsd:pattern value="[a-zA-Z0-9]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TenANumeric">
'''<xsd:restriction base="xsd:string">'''
<xsd:minLength value="1"/>
<xsd:maxLength value="10"/>
<xsd:pattern value="[a-zA-Z0-9]"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.
What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as '''xsd:string'''.
This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

[[Category:OWASP Code Review Project]]

Data Validation (Code Review)

2006-06-09T08:31:41Z

Eoin:

[[OWASP Code Review Guide Table of Contents]]__TOC__
Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]
One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

==Canoncalization of input. ==

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>

''(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).''

URL encoded: %3C%73%63%72%69%70%74%3E

Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.1 delves much more into this subject.

==Data validation strategy ==

A general rule is to accept only “'''Known Good'''” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “'''Known bad'''”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

There are a number of models to think about when designing a data validation strategy, which are listed from the strongest to the weakest as follows.

# '''Exact Match''' (Constrain)
# '''Known Good''' (Accept)
# '''Reject Known bad''' (Reject)
# '''Encode Known bad''' (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.

'''Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.'''

* '''Exact Match''': (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

* '''Known Good''': If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

* '''Reject Known bad''': We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

* '''Encode Known Bad''': This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

'''HTML-encoding and URL-encoding user input when writing back to the client'''. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

==Good Patterns for Data validation ==

===Data Validation examples ===

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
'''preg_grep()''' could also be used for a '''''True''''' or '''''False''''' result. This would enable us to let “'''''only known good'''''” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

<u>http://www.regxlib.com/CheatSheet.aspx</u>

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

===Framework Example:(Struts 1.2) ===
In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

# Enables us to have a central area for data validation.
# Provides us with a data validation framework.

What to look for when examining struts is as follows:

The struts-config.xml file must contain the following:


<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/technology/WEB-INF/
validator-rules.xml, /WEB-INF/validation.xml"/>
</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {
private String username;
private String password;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}

Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm"
type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="'''username'''"
depends="'''required'''">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.

The “depends” directive dictates that the parameter is required. If this is blank the error defined in '''Application.properties'''. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.
The developer would need to take this a step further by validating the input via regular expression:
<field property="username"
depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>
Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true" staticJavascript="true" />

===Framework example:(.NET)===
The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past.
The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).
What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

'''''"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."'''''

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:
* RequiredFieldValidator – Makes the associated input control a required field.
* CompareValidator – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.
* RangeValidator – Checks if the value of an input control is within a defined range of values.
* RegularExpressionValidator – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server
ControlToValidate=Name ErrorMessage="User ID is required."> *
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>
<asp:RegularExpressionValidator runat=server display=dynamic
controltovalidate="Name"
errormessage="ID must be 6-8 letters."
validationexpression="[a-zA-Z0-9]{6,8}" />
</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

==Length Checking==

Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.

Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.
If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.
If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

==Never Rely on Client-Side Data Validation ==

''Client-side validation can always be bypassed.''
''Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript? ''
''Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.''
'''Remember: Data validation must be always done on the server side.'''
'''A code review focuses on server side code. Any client side security code is not and cannot be considered security.'''

Data validation of parameter names:

When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as
'' UserId =3o1nk395y''
'' password=letMeIn123''

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (''UserId'',''password'' from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

==Web services data validation==

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:complexType name="AddressIn">
<xsd:sequence>
<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>
<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>
<xsd:element name="county" type="TenANumeric" nillable="false"/>
<xsd:element name="town" type="TenANumeric" nillable="true"/>
<xsd:element name="userId" type="TenANumeric" nillable="false"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="HundredANumeric">
'''<xsd:restriction base="xsd:string">'''
<xsd:minLength value="1"/>
<xsd:maxLength value="100"/>
<xsd:pattern value="[a-zA-Z0-9]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TenANumeric">
'''<xsd:restriction base="xsd:string">'''
<xsd:minLength value="1"/>
<xsd:maxLength value="10"/>
<xsd:pattern value="[a-zA-Z0-9]"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.
What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as '''xsd:string'''.
This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

[[Category:OWASP Code Review Project]]

Reviewing Code for SQL Injection

2006-06-09T08:29:55Z

Eoin:

[[OWASP Code Review Guide Table of Contents]]__TOC__
== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL Injection Example: ==

String DRIVER = "com.ora.jdbc.Driver";

String DataURL = "jdbc:db://localhost:5112/users";

String LOGIN = "admin";

String PASSWORD = "admin123";

Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request

String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;

String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {

iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}

PrintWriter writer = response.getWriter ();

if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {

writer.println ("Access Denied!")
}

When SQL statements are dynamically created as software executes, there is an opportunity for a
security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" Username + "' AND Password = '" + Password + "'";

== .NET ==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;

using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();

SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);

sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;

//specify param type

sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);

sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc

}

'''Stored procedures don’t always protect against SQL injection:'''

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™

Lets pass it.

DROP TABLE ORDERS;

Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Buffer Overruns and Overflows

2006-06-09T08:27:55Z

Eoin:

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

Contact author: [mailto:eoinkeary@owasp.org Eoin Keary]

==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 printer 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 ment 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 expext 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.

OWASP Code Review Guide Table of Contents

2006-06-09T08:27:11Z

Eoin: /* Introduction */

==[[Code Review Introduction|Introduction]] ==

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==
[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==

[[Category:OWASP Code Review Project]]

==[[Error Handling]]==

==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[SQL Injection]] ==

OWASP Code Review Guide Table of Contents

2006-06-09T08:26:32Z

Eoin: /* Error Handling */

OWASP Code Review Guide Table of Contents

2006-06-09T08:25:44Z

Eoin: /* Data Validation */

OWASP Code Review Guide Table of Contents

2006-06-09T08:24:52Z

Eoin: /* Error Handling */

OWASP Code Review Guide Table of Contents

2006-06-09T08:24:28Z

Eoin: /* Data Validation */

Reviewing Code for SQL Injection

2006-06-09T08:22:39Z

Eoin: /* SQL Injection Example: */

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL Injection Example: ==

String DRIVER = "com.ora.jdbc.Driver";

String DataURL = "jdbc:db://localhost:5112/users";

String LOGIN = "admin";

String PASSWORD = "admin123";

Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request

String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;

String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {

iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}

PrintWriter writer = response.getWriter ();

if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {

writer.println ("Access Denied!")
}

When SQL statements are dynamically created as software executes, there is an opportunity for a
security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" Username + "' AND Password = '" + Password + "'";

== .NET ==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;

using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();

SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);

sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;

//specify param type

sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);

sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc

}

'''Stored procedures don’t always protect against SQL injection:'''

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™

Lets pass it.

DROP TABLE ORDERS;

Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Reviewing Code for SQL Injection

2006-06-09T08:18:47Z

Eoin: /* SQL Injection Example: */

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL Injection Example: ==

String DRIVER = "com.ora.jdbc.Driver";

String DataURL = "jdbc:db://localhost:5112/users";

String LOGIN = "admin";

String PASSWORD = "admin123";

Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request

String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;

String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();

ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {

iUserID = resultSet.getInt(1);

sLoggedUser = resultSet.getString(2);

}

PrintWriter writer = response.getWriter ();

if (iUserID >= 0) {

writer.println ("User logged in: " + sLoggedUser);

} else {

writer.println ("Access Denied!")

}

When SQL statements are dynamically created as software executes, there is an opportunity for a
security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" Username + "' AND Password = '" + Password + "'";

== .NET
==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;
using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();
SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);
sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;
//specify param type
sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc
}

Stored procedures don’t always protect against SQL injection:

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™
Lets pass it.

DROP TABLE ORDERS;
Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Reviewing Code for SQL Injection

2006-06-09T08:17:04Z

Eoin: /* SQL Injection Example: */

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL Injection Example: ==

String DRIVER = "com.ora.jdbc.Driver";

String DataURL = "jdbc:db://localhost:5112/users";

String LOGIN = "admin";

String PASSWORD = "admin123";

Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request

String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;
String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {
iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}
PrintWriter writer = response.getWriter ();
if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {
writer.println ("Access Denied!");
}

When SQL statements are dynamically created as software executes, there is an opportunity for a security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '"
Username + "' AND Password = '" + Password + "'";

== .NET
==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;
using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();
SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);
sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;
//specify param type
sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc
}

Stored procedures don’t always protect against SQL injection:

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™
Lets pass it.

DROP TABLE ORDERS;
Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Reviewing Code for SQL Injection

2006-06-09T08:16:36Z

Eoin: /* SQL Injection Example: */

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL Injection Example: ==

String DRIVER = "com.ora.jdbc.Driver";
String DataURL = "jdbc:db://localhost:5112/users";
String LOGIN = "admin";
String PASSWORD = "admin123";
Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request

String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;
String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {
iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}
PrintWriter writer = response.getWriter ();
if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {
writer.println ("Access Denied!");
}

When SQL statements are dynamically created as software executes, there is an opportunity for a security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '"
Username + "' AND Password = '" + Password + "'";

== .NET
==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;
using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();
SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);
sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;
//specify param type
sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc
}

Stored procedures don’t always protect against SQL injection:

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™
Lets pass it.

DROP TABLE ORDERS;
Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Reviewing Code for SQL Injection

2006-06-09T08:16:11Z

Eoin: /* SQL INJECTION EXAMPLE: */

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL Injection Example: ==

String DRIVER = "com.ora.jdbc.Driver";
String DataURL = "jdbc:db://localhost:5112/users";
String LOGIN = "admin";
String PASSWORD = "admin123";
Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request
String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;
String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {
iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}
PrintWriter writer = response.getWriter ();
if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {
writer.println ("Access Denied!");
}

When SQL statements are dynamically created as software executes, there is an opportunity for a security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '"
Username + "' AND Password = '" + Password + "'";

== .NET
==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;
using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();
SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);
sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;
//specify param type
sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc
}

Stored procedures don’t always protect against SQL injection:

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™
Lets pass it.

DROP TABLE ORDERS;
Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Reviewing Code for SQL Injection

2006-06-09T08:14:50Z

Eoin:

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL INJECTION EXAMPLE: ==

String DRIVER = "com.ora.jdbc.Driver";
String DataURL = "jdbc:db://localhost:5112/users";
String LOGIN = "admin";
String PASSWORD = "admin123";
Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request
String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;
String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {
iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}
PrintWriter writer = response.getWriter ();
if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {
writer.println ("Access Denied!");
}

When SQL statements are dynamically created as software executes, there is an opportunity for a security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '"
Username + "' AND Password = '" + Password + "'";

== .NET
==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;
using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();
SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);
sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;
//specify param type
sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc
}

Stored procedures don’t always protect against SQL injection:

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™
Lets pass it.

DROP TABLE ORDERS;
Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

Reviewing Code for SQL Injection

2006-06-09T08:13:34Z

Eoin:

== What SQL injection is: ==

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.
This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

== How to Locate potentially vulnerable code ==

A secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures.
Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement.

The account used to make the database connection must have “Least privilege” If the application only requires read access then the account must be given read access only.

Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks. Uncaught SQL errors normally give too much information to the user and contain things like table names and procedure names.

== Best practices when dealing with DB’s ==

Use Database stored procedures, but even stored procedures can be vulnerable.
Use parametrized queries instead of dynamic SQL statements.
Data validate all external input:
Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables in Java.

== SQL INJECTION EXAMPLE: ==

String DRIVER = "com.ora.jdbc.Driver";
String DataURL = "jdbc:db://localhost:5112/users";
String LOGIN = "admin";
String PASSWORD = "admin123";
Class.forName(DRIVER);

//Make connection to DB
Connection connection = DriverManager.getConnection(DataURL, LOGIN, PASSWORD);

String Username = request.getParameter("USER"); // From HTTP request
String Password = request.getParameter("PASSWORD"); // From HTTP request

int iUserID = -1;
String sLoggedUser = "";

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '" +Username + "' AND Password = '" + Password + "'";

Statement selectStatement = connection.createStatement ();
ResultSet resultSet = selectStatement.executeQuery(sel);

if (resultSet.next()) {
iUserID = resultSet.getInt(1);
sLoggedUser = resultSet.getString(2);
}
PrintWriter writer = response.getWriter ();
if (iUserID >= 0) {
writer.println ("User logged in: " + sLoggedUser);
} else {
writer.println ("Access Denied!");
}

When SQL statements are dynamically created as software executes, there is an opportunity for a security breach as the input data can truncate or malform or even expand the original SQL query!

Firstly the request.getParameter retrieves the data for the SQL query directly from the HTTP request without any Data validation (Min/Max length, Permitted characters, malicious characters). This error gives rise to the ability to input SQL as the payload and alter the functionality in the statement.

The application places the payload directly into the statement causing the SQL vulnerability:

String sel = "SELECT User_id, Username FROM USERS WHERE Username = '"
Username + "' AND Password = '" + Password + "'";

== .NET
==

Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code and therefore the payload can not be injected. Using a parameters collection lets you enforce type and length checks. Values outside of the range trigger an exception. Make sure you handle the exception correctly.
Example of the SqlParameterCollection:

using System.Data;
using System.Data.SqlClient;

using (SqlConnection conn = new SqlConnection(connectionString))
{
DataSet dataObj = new DataSet();
SqlDataAdapter sqlAdapter = new SqlDataAdapter( "StoredProc", conn);
sqlAdapter.SelectCommand.CommandType = CommandType.StoredProcedure;
//specify param type
sqlAdapter.SelectCommand.Parameters.Add("@usrId", SqlDbType.VarChar, 15);
sqlAdapter.SelectCommand.Parameters["@usrId "].Value = UID.Text; // Add data from user

sqlAdapter.Fill(dataObj); // populate and execute proc
}

Stored procedures don’t always protect against SQL injection:

CREATE PROCEDURE dbo.RunAnyQuery
@parameter NVARCHAR(50)

AS
EXEC sp_executesql @parameter
GO

The above procedure shall execute any SQL you pass to it. The directive sp_executesql is a system stored procedure in Microsoft® SQL Server™
Lets pass it.

DROP TABLE ORDERS;
Guess what happens? So we must be careful of not falling into the “We’re secure, we are using stored procedures” trap!

OWASP Code Review Guide Table of Contents

2006-06-09T08:11:12Z

Eoin: /* SQL Injection */

OWASP Code Review Guide Table of Contents

2006-06-09T08:09:40Z

Eoin: /* XSS Attacks */

XSS Attacks

2006-06-09T08:07:01Z

Eoin:

[[OWASP Code Review Guide Table of Contents]]

XSS attacks
Bad code example:
If the text inputted by the user is reflected back and has not been data validated the browser shall interpret the inputted script as part of the mark up and execute the code accordingly.
To mitigate this type of vulnerability we need to perform a number of security tasks in our code:

# Data validate.
# Encode Unsafe output.

import org.apache.struts.action.*;
import org.apache.commons.beanutils.BeanUtils;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public final class InsertEmployeeAction extends Action {

public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception{

// Setting up objects and vairables.

Obj1 service = new Obj1();
ObjForm objForm = (ObjForm) form;
InfoADT adt = new InfoADT ();
BeanUtils.copyProperties(adt, objForm);

String searchQuery = objForm.getqueryString();
String payload = objForm.getPayLoad();
try {
service.doWork(adt); / /do something with the data
ActionMessages messages = new ActionMessages();
ActionMessage message = new ActionMessage("success", adt.getName() );
messages.add( ActionMessages.GLOBAL_MESSAGE, message );
saveMessages( request, messages );
request.setAttribute("Record", adt);
return (mapping.findForward("success"));
}
catch( DatabaseException de )
{
ActionErrors errors = new ActionErrors();
ActionError error = new ActionError("error.employee.databaseException" + “Payload: “+payload);
errors.add( ActionErrors.GLOBAL_ERROR, error );
saveErrors( request, errors ); return (mapping.findForward("error: "+ searchQuery));
}
}
}

The red text above shows some common mistakes in the development of this struts action class.
Firstly the data passed in the HttpServletRequest is placed into a parameter without being data validated.

Focusing on XSS we can see that this action class returns either a message, ActionMessage in the case of the function being successful.
In the case of an error the code in the Try/Catch block is executed and we can see here that the data inputted by the user, the data contained in the HttpServletRequest is returned to the user, unvalidated and exactly in the format in which the user inputted it.

import java.io.*;
import javax.servlet.http.*;
import javax.servlet.*;

public class HelloServlet extends HttpServlet
{
public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException
{

String input = req.getHeader(“USERINPUT”);

PrintWriter out = res.getWriter();
out.println(input); // echo User input.
out.close();
}
}

A second example of an XSS vulnerable function. Echoing un-validated user input back to the browser would give a nice large vulnerability footprint.

.NET Example (ASP.NET version 1.1 ASP.NET version 2.0):

The server side code for a VB.NET application may have similar functionality

' SearchResult.aspx.vb
Imports System
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls

Public Class SearchPage Inherits System.Web.UI.Page

Protected txtInput As TextBox
Protected cmdSearch As Button
Protected lblResult As Label Protected

Sub cmdSearch _Click(Source As Object, _ e As EventArgs)

// Do Search…..
// …………

lblResult.Text="You Searched for: " & txtInput.Text

// Display Search Results…..
// …………

End Sub
End Class

This is a VB.NET example of a Cross Site Script vulnerable piece of search functionality which echoes back the data inputted by the user. To mitigate against this we need proper data validation and in the case of stored XSS attacks we need to encode known bad (as mentioned before).

In the .NET framework there are some in-built security functions which can assist in data validation and HTML encoding, namley, ASP.NET 1.1 '''request validation '''feature and '''HttpUtility.HtmlEncode'''.

Microsoft in their wisdom state that you should not rely solely on ASP.NET request validation
and that it should be used in conjunction with your own data validation, such as regular expressions (mentioned below).

The request validation feature is disabled on an individual page by specifying in the page directive

'''<%@ Page validateRequest="false" %>'''

or by setting '''ValidateRequest="false"''' on the '''@ Pages''' element.

or in the '''web.config''' file:

You can disable request validation by adding a

<'''pages'''> element with '''validateRequest="false"'''

So when reviewing code make sure the validateRequest directive is enabled an if not, investigate what method of DV is being used, if any.
Check that ASP.NET Request validation Is enabled in '''Machine.config'''
Request validation is enabled by ASP.NET by default. You can see the following default setting in the '''Machine.config''' file.

'''<pages validateRequest="true" ... /> '''

HTML Encoding:

Content to be displayed can easily be encoded using the HtmlEncode function. This is done by calling:

'''Server.HtmlEncode(string)'''

Using the html encoder example for a form:

Text Box: <%@ Page Language="C#" ValidateRequest="false" %>

<script runat="server">
void searchBtn _Click(object sender, EventArgs e) {
Response.Write(HttpUtility.HtmlEncode(inputTxt.Text)); }
</script>
<html>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="inputTxt" Runat="server" TextMode="MultiLine" Width="382px" Height="152px">
</asp:TextBox>
<asp:Button ID="searchBtn" Runat="server" Text="Submit" OnClick=" searchBtn _Click" />
</div>
</form>
</body>
</html>

'''Stored Cross Site Script:'''
Using Html encoding to encode potentially unsafe output.:

Malicious script can be stored/persisted in a database and shall not execute until retrieved by a user. This can also be the case in bulletin boards and some early web email clients. This incubated attack can sit dormant for a long period of time until a user decides to view the page where the injected script is present. At this point the script shall execute on the users browser:

The original source of input for the injected script may be from another vulnerable application, which is common in enterprise architectures. Therefore the application at hand may have good input data validation but the data persisted may not have been entered via this application per se, but via another application.

In this case we cannot be 100% sure the data to be displayed to the user is 100% safe (as it could of found its way in via another path in the enterprise).
The approach to mitigate against this si to ensure the data sent to the browser is not going to be interpreted by the browser as mark-up and should be treated as user data.

We encode known bad to mitigate against this “enemy within”. This in effect assures the browser interprets any special characters as data and markup.
How is this done?
HTML encoding usually means '''<''' becomes '''&lt;''', '''>''' becomes '''&gt;''', '''&''' becomes '''&amp;''', and '''"''' becomes '''&quot;'''.

From To

<      &lt;

>      &gt;

(      &#40;

)      &#41;

#      &#35;

&      &amp;

"      &quot;

So for example the text <script> would be displayed as <script> but on viewing the markup it would be represented by &lt;script&gt;

[[Alternate XSS Syntax]]

[[Category:OWASP Code Review Project]]
[[Category:Attack]]

OWASP Code Review Guide Table of Contents

2006-06-09T08:05:19Z

Eoin: /* Buffer Overruns and Overflows */

OWASP Code Review Guide Table of Contents

2006-06-09T08:04:28Z

Eoin: /* Data Validation */

OWASP Code Review Guide Table of Contents

2006-06-09T08:03:16Z

Eoin: /* Data Validation */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true"
staticJavascript="true" />

'''Framework example(.NET):'''

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past. The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).

What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:

'''RequiredFieldValidator''' – Makes the associated input control a required field.

'''CompareValidator''' – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.

'''RangeValidator''' – Checks if the value of an input control is within a defined range of values.

'''RegularExpressionValidator''' – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<math><html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server ControlToValidate=Name ErrorMessage="User ID is required.">
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>
<asp:RegularExpressionValidator runat=server display=dynamic controltovalidate="Name" errormessage="ID must be 6-8 letters." validationexpression="[a-zA-Z0-9]{6,8}" />
</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

</math>
Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

'''Length Checking:'''
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an xternal request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.

If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.

If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

''''Never Rely on Client-Side Data Validation'''' Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

'''Remember''': Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

'''Data validation of parameter names'''
When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as

UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

OWASP Code Review Guide Table of Contents

2006-06-09T08:01:14Z

Eoin: /* OS Injection */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true"
staticJavascript="true" />

'''Framework example(.NET):'''

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past. The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).

What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:

'''RequiredFieldValidator''' – Makes the associated input control a required field.

'''CompareValidator''' – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.

'''RangeValidator''' – Checks if the value of an input control is within a defined range of values.

'''RegularExpressionValidator''' – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<math><html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server ControlToValidate=Name ErrorMessage="User ID is required.">
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>
<asp:RegularExpressionValidator runat=server display=dynamic controltovalidate="Name" errormessage="ID must be 6-8 letters." validationexpression="[a-zA-Z0-9]{6,8}" />
</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

</math>
Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

'''Length Checking:'''
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an xternal request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.

If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.

If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

''''Never Rely on Client-Side Data Validation'''' Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

'''Remember''': Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

'''Data validation of parameter names'''
When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as

UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
[[OWASP Code Review Guide Table of Contents]]__TOC__

Injection flaws allow attackers to pass malicious code through a web application to another sub system.
Depending on the subsystem different types of injection attack can be performed:
RDBMS: SQL Injection
WebBrowser/Appserver: SQL Injection
OS-shell: Operating system commands Calling external applications from your application.

==How to locate the potentially vulnerable code ==

Many developers believe text fields are the only areas for data validation. This is an incorrect assumption. Any external input must be data validated:

Text fields, List boxes, radio buttons, check boxes, cookies, HTTP header data, HTTP post data, hidden fields, parameter names and parameter values.
… This is not an exhaustive list.

“Process to process” or “entity-to-entity” communication must be investigated also. Any code that communicates with an upstream or downstream process and accepts input from said entity must be reviewed.

All injection flaws are input validation errors. The presence if an injection flaw is an indication of incorrect data validation on the input received from an external source our outside the boundary of trust, which gets more blurred every year.

Basically for this type of vulnerability we need to find all input streams into the application. This can be from a users browser, CLI or fat client but also from upstream processes that “feed” our application.

An example would be to search the code base for the use of API’s or packages that are normally used for communication purposes.

The '''java.io''', '''java.sql''', '''java.net''', '''java.rmi''', '''java.xml''' packages are all used for application communication. Searching for methods from those packages in the code base can yield results. A less “scientific” method is to search for common keywords such as “UserID”, “LoginID” or “Password”.

== Vulnerable Patterns for OS injection ==
What we should be looking for is relationships between the application and the operating system. The application utilising functions of the underlying operating system.

In java using the Runtime object, '''java.lang.Runtime''' does this.
In .NET calls such as '''System.Diagnostics.Process.Start '''are used to call underlying OS functions.
In PHP we may look for calls such as '''exec()''' or '''passthru()'''.

'''Example''':

We have a class that eventually gets input from the user via a HTTP request.
This class is used to execute some native exe on the application server and return a result.

public class DoStuff {
public string executeCommand(String userName)
{ try {
String myUid = userName;
Runtime rt = Runtime.getRuntime();
rt.exec("doStuff.exe " +”-“ +myUid); // Call exe with userID
}catch(Exception e)
{
e.printStackTrace();
}
}
}

Ok, so the method executeCommand calls '''''doStuff.exe''''' via the '''''java.lang.runtime''''' static method '''''getRuntime()'''''. The parameter passed is not validated in any way in this class. We are assuming that the data has not been data validated prior to calling this method. ''Transactional analysis should have encountered any data validation prior to this point.''
Inputting “Joe69” would result in the following MS DOS command:
'''''doStuff.exe –Joe69'''''
Lets say we input '''''Joe69 & netstat –a''''' we would get the following response:
The exe doStuff would execute passing in the User Id Joe69, but then the dos command '''''netstat''''' would be called. How this works is the passing of the parameter “&” into the application, which in turn is used as a command appender in MS DOS and hence the command after the & character is executed.

UNIX:
An attacker might insert the string '''“; cat /etc/hosts”''' the contents of the UNIX hosts file might be exposed to the attacker.

.NET Example:
namespace ExternalExecution
{
class CallExternal
{
static void Main(string[] args)
{
String arg1=args[0];
System.Diagnostics.Process.Start("doStuff.exe", arg1);
}
}
}

Yet again there is no data validation to speak of here. Assuming no upstream validation occurring in another class.

These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Complete scripts written in perl, python, shell, bat and other languages can be injected into poorly designed web applications and executed.

==Good Patterns & procedures to prevent OS injection==

See the Data Validation section.

==Related Articles==
[[Interpreter Injection]]

[[Category:OWASP Code Review Project]]
[[Category:Attack]]
[[Category:Input Validation]]

==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

Category:OWASP Code Review Project

2006-06-09T07:58:21Z

Eoin: /* Downloads */

OWASP Code Review Guide Table of Contents

2006-06-09T07:55:03Z

Eoin: /* OS Injection */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true"
staticJavascript="true" />

'''Framework example(.NET):'''

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past. The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).

What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:

'''RequiredFieldValidator''' – Makes the associated input control a required field.

'''CompareValidator''' – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.

'''RangeValidator''' – Checks if the value of an input control is within a defined range of values.

'''RegularExpressionValidator''' – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<math><html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server ControlToValidate=Name ErrorMessage="User ID is required.">
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>
<asp:RegularExpressionValidator runat=server display=dynamic controltovalidate="Name" errormessage="ID must be 6-8 letters." validationexpression="[a-zA-Z0-9]{6,8}" />
</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

</math>
Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

'''Length Checking:'''
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an xternal request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.

If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.

If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

''''Never Rely on Client-Side Data Validation'''' Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

'''Remember''': Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

'''Data validation of parameter names'''
When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as

UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
OS Injection

Injection flaws allow attackers to pass malicious code through a web application to another sub system.
Depending on the subsystem different types of injection attack can be performed:
RDBMS: SQL Injection
WebBrowser/Appserver: SQL Injection
OS-shell: Operating system commands Calling external applications from your application.

How to locate the potentially vulnerable code:

Many developers believe text fields are the only areas for data validation. This is an incorrect assumption. Any external input must be data validated:

Text fields, List boxes, radio buttons, check boxes, cookies, HTTP header data, HTTP post data, hidden fields, parameter names and parameter values.
… This is not an exhaustive list.

“Process to process” or “entity-to-entity” communication must be investigated also. Any code that communicates with an upstream or downstream process and accepts input from said entity must be reviewed.

All injection flaws are input validation errors. The presence if an injection flaw is an indication of incorrect data validation on the input received from an external source our outside the boundary of trust, which gets more blurred every year.

Basically for this type of vulnerability we need to find all input streams into the application. This can be from a users browser, CLI or fat client but also from upstream processes that “feed” our application.

An example would be to search the code base for the use of API’s or packages that are normally used for communication purposes.

The java.io, java.sql, java.net, java.rmi, java.xml packages are all used for application communication. Searching for methods from those packages in the code base can yield results. A less “scientific” method is to search for common keywords such as “UserID”, “LoginID” or “Password”.

'''Vulnerable Patterns for OS injection:'''
What we should be looking for is relationships between the application and the operating system. The application utilising functions of the underlying operating system.

In java using the Runtime object, java.lang.Runtime does this.
In .NET calls such as System.Diagnostics.Process.Start are used to call underlying OS functions.
In PHP we may look for calls such as exec() or passthru().

'''Example:'''

We have a class that eventually gets input from the user via a HTTP request.
This class is used to execute some native exe on the application server and return a result.

public class DoStuff {
public string executeCommand(String userName)
{ try {
String myUid = userName;
Runtime rt = Runtime.getRuntime();
rt.exec("doStuff.exe " +”-“ +myUid); // Call exe with userID
}catch(Exception e)
{
e.printStackTrace();
}
}
}

Ok, so the method executeCommand calls doStuff.exe via the java.lang.runtime static method getRuntime(). The parameter passed is not validated in any way in this class. We are assuming that the data has not been data validated prior to calling this method. Transactional analysis should have encountered any data validation prior to this point.
Inputting “Joe69” would result in the following MS DOS command:
doStuff.exe –Joe69
Lets say we input Joe69 & netstat –a we would get the following response:
The exe doStuff would execute passing in the User Id Joe69, but then the dos command netstat would be called. How this works is the passing of the parameter “&” into the application, which in turn is used as a command appender in MS DOS and hence the command after the & character is executed.

'''UNIX:'''
An attacker might insert the string “; cat /etc/hosts” the contents of the UNIX hosts file might be exposed to the attacker.

'''.NET Example:'''
namespace ExternalExecution{class CallExternal{static void Main(string[] args){String arg1=args[0];System.Diagnostics.Process.Start("doStuff.exe", arg1);}}}

Yet again there is no data validation to speak of here. Assuming no upstream validation occurring in another class.

These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Complete scripts written in perl, python, shell, bat and other languages can be injected into poorly designed web applications and executed.

'''Good Patterns & procedures to prevent OS injection:'''

See the Data Validation section.
[[Category:OWASP Code Review Project]]

==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

OWASP Code Review Guide Table of Contents

2006-06-09T07:50:48Z

Eoin: /* Data Validation */

OWASP Code Review Guide Table of Contents

2006-06-09T07:42:21Z

Eoin: /* Data Validation */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true"
staticJavascript="true" />

'''Framework example(.NET):'''

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past. The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).

What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:

'''RequiredFieldValidator''' – Makes the associated input control a required field.

'''CompareValidator''' – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.

'''RangeValidator''' – Checks if the value of an input control is within a defined range of values.

'''RegularExpressionValidator''' – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server ControlToValidate=Name ErrorMessage="User ID is required.">
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>
<asp:RegularExpressionValidator runat=server display=dynamic controltovalidate="Name" errormessage="ID must be 6-8 letters." validationexpression="[a-zA-Z0-9]{6,8}" />
</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

'''Length Checking:'''
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an xternal request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.

If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.

If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

''''Never Rely on Client-Side Data Validation'''' Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

'''Remember''': Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

'''Data validation of parameter names'''
When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as

UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

OWASP Code Review Guide Table of Contents

2006-06-09T07:41:20Z

Eoin: /* Data Validation */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true"
staticJavascript="true" />

'''Framework example(.NET):'''

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past. The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).

What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:

'''RequiredFieldValidator''' – Makes the associated input control a required field.

'''CompareValidator''' – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.

'''RangeValidator''' – Checks if the value of an input control is within a defined range of values.

'''RegularExpressionValidator''' – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<nowiki><html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server ControlToValidate=Name ErrorMessage="User ID is required.">
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>
<asp:RegularExpressionValidator runat=server display=dynamic controltovalidate="Name" errormessage="ID must be 6-8 letters." validationexpression="[a-zA-Z0-9]{6,8}" />
</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html></nowiki>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

'''Length Checking:'''
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an xternal request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.

If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.

If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

''''Never Rely on Client-Side Data Validation'''' Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

'''Remember''': Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

'''Data validation of parameter names'''
When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as

UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

OWASP Code Review Guide Table of Contents

2006-06-08T09:41:56Z

Eoin: /* Data Validation */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true" staticJavascript="true" />

Framework example(.NET):

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past.

The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).
What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:
· RequiredFieldValidator – Makes the associated input control a required field.
· CompareValidator – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.
· RangeValidator – Checks if the value of an input control is within a defined range of values.
· RegularExpressionValidator – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />

<form runat=server>

<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server ControlToValidate=Name ErrorMessage="User ID is required."> *
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>

<asp:RegularExpressionValidator runat=server display=dynamic controltovalidate="Name" errormessage="ID must be 6-8 letters." validationexpression="[a-zA-Z0-9]{6,8}" />

</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

'''Length Checking:'''
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.

If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.

If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

''''Never Rely on Client-Side Data Validation'''' Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

'''Remember''': Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

'''Data validation of parameter names'''
When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as

UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

OWASP Code Review Guide Table of Contents

2006-06-08T09:37:08Z

Eoin: /* Data Validation */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true" staticJavascript="true" />

Framework example(.NET):

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past.

The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).
What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:
· RequiredFieldValidator – Makes the associated input control a required field.
· CompareValidator – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.
· RangeValidator – Checks if the value of an input control is within a defined range of values.
· RegularExpressionValidator – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<html>
<head>
<title>Validate me baby!</title>
</head>
<body>
<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />

<form runat=server>

<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server ControlToValidate=Name ErrorMessage="User ID is required."> *
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>

<asp:RegularExpressionValidator runat=server display=dynamic controltovalidate="Name" errormessage="ID must be 6-8 letters." validationexpression="[a-zA-Z0-9]{6,8}" />

</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

'''Length Checking:'''
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.

If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.

If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

''''Never Rely on Client-Side Data Validation'''' Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

'''Remember''': Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

'''Data validation of parameter names'''
When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as

UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

File:DV Strength.GIF

2006-06-08T09:31:16Z

Eoin:

OWASP Code Review Guide Table of Contents

2006-06-08T09:29:56Z

Eoin: /* Data Validation */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example(Struts 1.2)

In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:



<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

<set-property property="pathnames" value="/technology/WEB-INF/

validator-rules.xml, /WEB-INF/validation.xml"/>

</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {

private String username;
private String password;

public String getUsername() {

return username;

}

public void setUsername(String username) {

this.username = username;

}

public String getPassword() {

return password;

}

public void setPassword(String password) {

this.password = password;

}

}
Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm" type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username" depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.
The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0.
errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.

The developer would need to take this a step further by validating the input via regular expression:
<field property="username" depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true" staticJavascript="true" />

Framework example(.NET):

The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past.

The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).
What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:
· RequiredFieldValidator – Makes the associated input control a required field.
· CompareValidator – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.
· RangeValidator – Checks if the value of an input control is within a defined range of values.
· RegularExpressionValidator – Checks user input against a regular expression.

The following is an example web page (.aspx) containing validation:

<html>
<head>
<title>Validate me baby!</title>
</head>
<body>

<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />

<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server
ControlToValidate=Name ErrorMessage="User ID is required."> *
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>

<asp:RegularExpressionValidator runat=server display=dynamic
controltovalidate="Name"
errormessage="ID must be 6-8 letters."
validationexpression="[a-zA-Z0-9]{6,8}" />

</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

Length Checking:
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.
If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.
If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

Never Rely on Client-Side Data Validation Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

Remember: Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

Data validation of parameter names

When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as
UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

OWASP Code Review Guide Table of Contents

2006-06-08T09:19:37Z

Eoin: /* Data Validation */

==[[Code Review Introduction|Introduction]] ==
'''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 is a selling point. 30% to 35% of Microsoft’s budget for “Longhorn”
is earmarked for security, a sign of the times. http://news.bbc.co.uk/2/hi/business/4516269.stm

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.
It is in effect a look under the hood of an application (whitebox).

[[Category:OWASP Code Review Project]]

==[[Buffer Overruns and Overflows|Buffer Overruns and Overflows]] ==

'''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 printer 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 ment 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 expext 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.

TO DO – Unsafe methods which cause arithmetic overflows.

[[Category:OWASP Code Review Project]]

==[[Data Validation (Code Review)|Data Validation]] ==
[[Category:OWASP Code Review Project]]
Data Validation

One key area in web application security is the validation of data inputted from an external source. Many application exploits a derived from weak input validation on behalf of the application. Weak data validation gives the attacked the opportunity to make the application perform some functionality which it is not meant to do.

Canoncalization of input.

Input can be encoded to a format that can still be interpreted correctly by the application but may not be an obvious avenue of attack.

The encoding of ASCI to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.

The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

Example:

The ASCII: <script>
(If we simply block “<” and “>” characters the other representations below shall pass data validation and execute).

URL encoded: %3C%73%63%72%69%70%74%3E
Unicode Encoded: &#60&#115&#99&#114&#105&#112&#116&#62

The OWASP Guide 2.x delves much more into this subject.
Data validation strategy

A general rule is to accept only “Known Good” characters, i.e. the characters that are to be expected. If this cannot be done the next strongest strategy is “Known bad”, where we reject all known bad characters. The issue with this is that today’s known bad list may expand tomorrow as new technologies are added to the enterprise infrastructure.

Data Validation Strategy
There are a number of models to think about when designing a data validation strategy.

1. Exact Match (Constrain)
2. Known Good (Accept)
3. Reject Known bad (Reject)
4. Encode Known bad (Sanitise)

In addition there must be a check for maximum length of any input received from an external source, such as a downstream service/computer or a user at a web browser.
Rejected Data must not be persisted to the data store unless it is sanitised. This is a common mistake to log erroneous data but that may be what the attacker wishes your application to do.

· Exact Match: (preferred method) Only accept values from a finite list of known values.
E.g.: A Radio button component on a Web page has 3 settings (A, B, C). Only one of those three settings must be accepted (A or B or C). Any other value must be rejected.

· Known Good: If we do not have a finite list of all the possible values that can be entered into the system we uses known good approach.
E.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.

· Reject Known bad: We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.

· Encode Known Bad: This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.

HTML-encoding and URL-encoding user input when writing back to the client. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.

Good Patterns for Data validation

A good example of a pattern for data validation to prevent OS injection in PHP applications would be as follows:

$string = preg_replace("/[^a-zA-Z0-9]/", "", $string);

This code above would replace any non alphanumeric characters with “”.
preg_grep() could also be used for a True or False result. This would enable us to let “only known good” characters into the application.

Using regular expressions is a common method of restricting input character types.
A common mistake in the development of regular expressions is not escaping characters, which are interpreted as control characters, or not validating all avenues of input.

Examples of regular expression are as follows:

http://www.regxlib.com/CheatSheet.htm

^[a-zA-Z]$ Alpha characters only, a to z and A to Z (RegEx is case sensitive).
^[0-9]$ Numeric only (0 to 9).
[abcde] Matches any single character specified in set
[^abcde] Matches any single character not specified in set

Framework Example
(Struts 1.2)
In the J2EE world the struts framework (1.1) contains a utility called the commons validator. This enables us to do two things.

Enables us to have a central area for data validation.
Provides us with a data validation framework.

1. What to look for when examining struts is as follows:

2. The struts-config.xml file must contain the following:


<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/technology/WEB-INF/
validator-rules.xml, /WEB-INF/validation.xml"/>
</plug-in>

This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.

Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form.
We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:

package com.pcs.necronomicon
import org.apache.struts.validator.ValidatorForm;

public class LogonForm extends ValidatorForm {
private String username;
private String password;

public String getUsername() {
return username;
}

public void setUsername(String username) {
this.username = username;
}

public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}

Note the LoginForm extends the ValidatorForm, this is a must as the parent class (ValidatorForm) has a validate method which is called automatically and calls the rules defined in validation.xml

Now to be assured that this form bean is being called we look at the struts-config.xml file:
It should have something like the following:

<form-beans>
<form-bean name="logonForm"
type=" com.pcs.necronomicon.LogonForm"/>
</form-beans>

Next we look at the validation.xml file. It should contain something similar to the following:

<form-validation>
<formset>
<form name="logonForm">
<field property="username"
depends="required">
<arg0 key="prompt.username"/>
</field>
</form>
</formset>
</form-validation>

Note the same name in the validation.xml, the struts-config.xml, this is an important relationship and is case sensitive.

The field “username” is also case sensitive and refers to the String username in the LoginForm class.

The “depends” directive dictates that the parameter is required. If this is blank the error defined in Application.properties. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0. errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.
prompt.username = User Name is required.

The error defined by arg0, prompt.username is displayed as an alert box by the struts framework to the user.
The developer would need to take this a step further by validating the input via regular expression:
<field property="username"
depends="required,mask">
<arg0 key="prompt.username"/>
<var>
<var-name>mask</var-name>
<var-value>^[0-9a-zA-Z]*$</var-value>
</var>
</field>
</form>
</formset>
</form-validation>
Here we have added the Mask directive, this specifies a variable <var>. and a regular expression. Any input into the username field which has anything other than A to Z, a to z or 0 to 9 shall cause an error to be thrown. The most common issue with this type of development is either the developer forgetting to validate all fields or a complete form. The other thing to look for is incorrect regular expressions, so learn those RegEx’s kids!!!

We also need to check if the jsp pages have been linked up to the validation.xml finctionaltiy. This is done by <html:javascript> custom tag being included in the JSP as follows:

<html:javascript formName="logonForm" dynamicJavascript="true" staticJavascript="true" />

Framework example:
(.NET)
The ASP .NET framework contains a validator framework, which has made input validation easier and less error prone than in the past.
The validation solution for .NET also has client and server side functionalty akin to Struts (J2EE).
What is a validator? According to the Miscosoft (MSDN) definition it is as follows:

"A validator is a control that checks one input control for a specific type of error condition and displays a description of that problem."

The main point to take out of this from a code review perspective is that one validator does one type of function. If we need to do a number of different checks on our input we need to use more than one validator.

The .NET solution contains a number of controls out of the box:
· RequiredFieldValidator – Makes the associated input control a required field.
· CompareValidator – Compares the value entered by the user into an input control with the value entered into another input control or a constant value.
· RangeValidator – Checks if the value of an input control is within a defined range of values.
· RegularExpressionValidator – Checks user input against a regular expression.
The following is an example web page (.aspx) containing validation:

<html>
<head>
<title>Validate me baby!</title>
</head>
<body>

<asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />

<form runat=server>
<p>Please enter your User Id</p>
<tr>
<td>
<asp:RequiredFieldValidator runat=server
ControlToValidate=Name ErrorMessage="User ID is required."> *
</asp:RequiredFieldValidator>
</td>
<td>User ID:</td>
<td><input type=text runat=server id=Name></td>

<asp:RegularExpressionValidator runat=server display=dynamic
controltovalidate="Name"
errormessage="ID must be 6-8 letters."
validationexpression="[a-zA-Z0-9]{6,8}" />

</tr>
<input type=submit runat=server id=SubmitMe value=Submit>
</form>
</body>
</html>

Remember to check to regular expressions so they are sufficient to protect the application. The “runat” directive means this code is executed at the server prior to being sent to client. When this is displayed to a users browser the code is simply HTML.

Length Checking:
Another issue to consider is input length validation. If the input is limited by length this reduces the size of the script that can be injected into the web app.
Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading, as legitimate information and the web application will blindly pass these on to the external system for execution.

Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

If a logging mechanism is employed to log all data used in a particular transaction we need to ensure that the payload received is not so big that it may affect the logging mechanism.
If the log file is sent a very large payload it may crash or if it is sent a very large payload repeatedly the hard disk of the app server may fill causing a denial of service. This type of attack can be used to recycle to log file, hence removing the audit trail.
If string parsing is performed on the payload received by the application and an extremely large string is sent repeatedly to the application the CPU cycles used by the application to parse the payload may cause service degradation or even denial of service.

Never Rely on Client-Side Data Validation Client-side validation can always be bypassed. Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?

Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.

Remember: Data validation must be always done on the server side.
A code review focuses on server side code. Any client side security code is not and cannot be considered security.

Data validation of parameter names

When data is passed to a method of a web application via HTTP the payload is passed in a “key-value” pair such as
UserId =3o1nk395y
password=letMeIn123

Previously we talked about input validation of the payload (parameter value) being passed to the application. But we also may need to check that the parameter name (UserId,password from above) have not been tampered with.
Invalid parameter names may cause the application to crash or act in an unexpected way.
The best approach is “Exact Match” as mentioned previously.

Web services data validation

The recommended input validation technique for web services is to use a schema. A schema is a “map” of all the allowable values that each parameter can take for a given web service method.
When a SOAP message is received by the web services handler the schema pertaining to the method being called is “run over” the message to validate the content of the soap message.
There are two types of web service communication methods; XML-IN/XML-OUT and REST (Representational State Transfer).
XML-IN/XML-OUT means that the request is in the form of a SOAP message and the reply is also SOAP. REST web services accept a URI request (Non XML) but return a XML reply. REST only supports a point-to-point solution wherein SOAP chain of communication may have multiple nodes prior to the final destination of the request.
Validating REST web services input it the same as validating a GET request. Validating an XML request is best done with a schema.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://server.test.com" targetNamespace="http://server.test.com" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:complexType name="AddressIn">

<xsd:sequence>

<xsd:element name="addressLine1" type="HundredANumeric" nillable="true"/>

<xsd:element name="addressLine2" type="HundredANumeric" nillable="true"/>

<xsd:element name="county" type="TenANumeric" nillable="false"/>

<xsd:element name="town" type="TenANumeric" nillable="true"/>

<xsd:element name="userId" type="TenANumeric" nillable="false"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="HundredANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="100"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="TenANumeric">

<xsd:restriction base="xsd:string">

<xsd:minLength value="1"/>

<xsd:maxLength value="10"/>

<xsd:pattern value="[a-zA-Z0-9]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Here we have a schema for an object called AddressIn. Each of the elements have restrictions applied to them and the restrictions (in red) define what valid characters can be inputted into each of the elements.

What we need to look for is that each of the elements have a restriction applied to the as opposed to the simple type definition such as xsd:string.

This schema also has the <xsd:sequence> tag applied to enforce the sequence of the data that is to be received.

==[[Error Handling]]==
==[[OS Injection]] ==
==[[The Secure Code Environment]] ==
==[[Transaction Analysis]] ==
==[[XSS Attacks]] ==

Dublin

2006-06-08T08:30:28Z

Eoin: /* Local News */

{{Chapter Template|chaptername=Ireland|leaderemail=eoin.keary@owasp.org|leadername=Eoin Keary|mailinglistsite=http://lists.sourceforge.net/lists/listinfo/owasp-ireland}}

== Local News ==

'''OWASP Moves to MediaWiki Portal - 11:11, 20 May 2006 (EDT)'''

OWASP is pleased to announce the arrival of OWASP 2.0!

OWASP 2.0 utilizes the MediaWiki portal to manage and provide
the latest OWASP related information. Enjoy!

== NEXT MEETING==
We are taking a break for the summer.
Coming In September:

Live Pentest: Anatomy of a web application pentest.

OWASP Live CD: Preview of the OWASP Live CD "Pentest in your pocket".

OWASP Testing Guide: Testing Guide walkthrough.

The New "Top Ten": OWASP Top 10 V2 review.

OWASP Testing Project Roadmap

2006-06-01T13:19:09Z

Eoin:

The project's overall goal is to...

'''be a reference document for the purpose of performing penetration testing. This project shall provide examples of the most common web application vulnerabilities and attacks.'''

In the near term, we are focused on the following tactical goals...

1. '''Looking at each attack type and examine the method of testing to verify if the vulnerability exists.'''

2. '''Examining other technical and non technical methods to examing and find vulnerabilities in applications.'''

3. '''Discussing the OWASP testing framework and how it can help one to cover all the based when performing a pen test or risk assessment.'''

[[Category:OWASP Testing Project]]

OWASP Code Review Guide Table of Contents

2006-06-01T12:48:57Z

Eoin: /* Data Validation */

Category:OWASP Testing Project

2006-06-01T12:44:39Z

Eoin: /* Testing Guide DOWNLOAD */

==Overview==

This projects goal is to create a "best practices" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes how to find certain issues.

== Contributors ==
Currently there are many people helping out when they can.
The Project lead is Eoin Keary. There are still lots of areas to be covered.
To contribute please email [mailto:eoin.keary@owasp.org Eoin]

==Volunteers needed==

'''Phase Two call for volunteers'''
Wed Mar 15 12:30:28 EST 2006

Work is underway on the 2nd phase of the testing guide, and we would love to hear from volunteers who could offer their knowledge in creating this phase. If you have knowledge and experience in application testing, and can spare a few hours a week, please do get in [mailto:eoin.keary@owasp.org touch]

==Testing Guide Download==
[[OWASP Testing Guide]]

==Testing Checklist==
[[OWASP Testing Checklist]]

==Downloads and Materials==

You can [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=62285 download] project releases from the OWASP download center.

'''THE OWASP Testing Project Live CD'''

The OWASP testing project is currently implementing an Application security Live CD.

The aim of this CD is to have a complete testing suite on one Disk. The CD shall also contain the forthcoming OWASP Testing guide.

We also hope to include the OWASP.Net suite of tools by using mono.

The CD is being created in conjunction with Josh Perrrymon at [http://www.packetfocus.com/ Packetfocus].

He can be contacted on:
[mailto:josh.perrymon@packetfocus.com Josh Perrymon]

Also you can contact myself on [mailto:eoin.keary@owasp.org Eoin Keary]

==Newest Release==

December 13, 2004 - Phase One Released
We are glad to announce that The OWASP Testing Project Phase One has finally been released. This covers the processes involved in testing web applications:

* The scope of what to test
* Principles of testing
* Testing techniques explained
* The OWASP testing framework explained.

This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that they need to undertake to build and operate that testing program on their web application

You can now [https://sourceforge.net/project/showfiles.php?group_id=64424&package_id=62285 download] phase one from the OWASP download centre.

==Roadmap==

View the [[OWASP Testing Project Roadmap]]

==News==

'''OWASP Pen Test Checklist in Italian'''
Sun May 22 10:56:39 EDT 2005
I'm glad to announce we have released OWASP Pen Test Checklist in Italian. Thanks to the Italian Chapter, Massimiliano and Mateo for it's great effort to have this document translated. You can download this verion in[http://www.owasp.org/docroot/owasp/misc/OWASPWebAppPenTestList1.1_ITA.pdf PDF] or [http://www.owasp.org/docroot/owasp/misc/OWASPWebAppPenTestList1.1_ITA.doc Word]

'''Checklist ver 1.17 in Spanish'''
Mon Apr 04 15:37:24 EDT 2005
I'm glad to announce we have released OWASP Pen Test Checklist ver 1.17 in Spanish.Thanks to Pedro, Raul and Rogelio for it's great effort to have this document translated and to Christian by helping out with technical edition. You can download this verion [http://www.owasp.org/docroot/owasp/misc/testing_spanish.pdf PDF] or [http://www.owasp.org/docroot/owasp/misc/testing_spanish.doc Word]

==Project Contributors==

Contributors

==Feedback and Participation==

We hope you find the information in the OWASP Testing project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP Testing mailing list. Thanks!

To join the OWASP Testing mailing list or view the archives, please visit the [http://lists.sourceforge.net/lists/listinfo/owasp-testing subscription page].

{{Template:Stub}}

[[Category:OWASP Project]]

Category:OWASP Testing Project

2006-06-01T12:44:22Z

Eoin: /* Testing Guide */

==Overview==

This projects goal is to create a "best practices" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes how to find certain issues.

== Contributors ==
Currently there are many people helping out when they can.
The Project lead is Eoin Keary. There are still lots of areas to be covered.
To contribute please email [mailto:eoin.keary@owasp.org Eoin]

==Volunteers needed==

'''Phase Two call for volunteers'''
Wed Mar 15 12:30:28 EST 2006

Work is underway on the 2nd phase of the testing guide, and we would love to hear from volunteers who could offer their knowledge in creating this phase. If you have knowledge and experience in application testing, and can spare a few hours a week, please do get in [mailto:eoin.keary@owasp.org touch]

==Testing Guide DOWNLOAD==
[[OWASP Testing Guide]]

==Testing Checklist==
[[OWASP Testing Checklist]]

==Downloads and Materials==

You can [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=62285 download] project releases from the OWASP download center.

'''THE OWASP Testing Project Live CD'''

The OWASP testing project is currently implementing an Application security Live CD.

The aim of this CD is to have a complete testing suite on one Disk. The CD shall also contain the forthcoming OWASP Testing guide.

We also hope to include the OWASP.Net suite of tools by using mono.

The CD is being created in conjunction with Josh Perrrymon at [http://www.packetfocus.com/ Packetfocus].

He can be contacted on:
[mailto:josh.perrymon@packetfocus.com Josh Perrymon]

Also you can contact myself on [mailto:eoin.keary@owasp.org Eoin Keary]

==Newest Release==

December 13, 2004 - Phase One Released
We are glad to announce that The OWASP Testing Project Phase One has finally been released. This covers the processes involved in testing web applications:

* The scope of what to test
* Principles of testing
* Testing techniques explained
* The OWASP testing framework explained.

This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that they need to undertake to build and operate that testing program on their web application

You can now [https://sourceforge.net/project/showfiles.php?group_id=64424&package_id=62285 download] phase one from the OWASP download centre.

==Roadmap==

View the [[OWASP Testing Project Roadmap]]

==News==

'''OWASP Pen Test Checklist in Italian'''
Sun May 22 10:56:39 EDT 2005
I'm glad to announce we have released OWASP Pen Test Checklist in Italian. Thanks to the Italian Chapter, Massimiliano and Mateo for it's great effort to have this document translated. You can download this verion in[http://www.owasp.org/docroot/owasp/misc/OWASPWebAppPenTestList1.1_ITA.pdf PDF] or [http://www.owasp.org/docroot/owasp/misc/OWASPWebAppPenTestList1.1_ITA.doc Word]

'''Checklist ver 1.17 in Spanish'''
Mon Apr 04 15:37:24 EDT 2005
I'm glad to announce we have released OWASP Pen Test Checklist ver 1.17 in Spanish.Thanks to Pedro, Raul and Rogelio for it's great effort to have this document translated and to Christian by helping out with technical edition. You can download this verion [http://www.owasp.org/docroot/owasp/misc/testing_spanish.pdf PDF] or [http://www.owasp.org/docroot/owasp/misc/testing_spanish.doc Word]

==Project Contributors==

Contributors

==Feedback and Participation==

We hope you find the information in the OWASP Testing project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP Testing mailing list. Thanks!

To join the OWASP Testing mailing list or view the archives, please visit the [http://lists.sourceforge.net/lists/listinfo/owasp-testing subscription page].

{{Template:Stub}}

[[Category:OWASP Project]]

Category:OWASP Testing Project

2006-06-01T12:17:40Z

Eoin: /* Volunteers needed */

==Overview==

This projects goal is to create a "best practices" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes how to find certain issues.

== Contributors ==
Currently there are many people helping out when they can.
The Project lead is Eoin Keary. There are still lots of areas to be covered.
To contribute please email [mailto:eoin.keary@owasp.org Eoin]

==Volunteers needed==

'''Phase Two call for volunteers'''
Wed Mar 15 12:30:28 EST 2006

Work is underway on the 2nd phase of the testing guide, and we would love to hear from volunteers who could offer their knowledge in creating this phase. If you have knowledge and experience in application testing, and can spare a few hours a week, please do get in [mailto:eoin.keary@owasp.org touch]

==Testing Guide==
[[OWASP Testing Guide]]

==Testing Checklist==
[[OWASP Testing Checklist]]

==Downloads and Materials==

You can [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=62285 download] project releases from the OWASP download center.

'''THE OWASP Testing Project Live CD'''

The OWASP testing project is currently implementing an Application security Live CD.

The aim of this CD is to have a complete testing suite on one Disk. The CD shall also contain the forthcoming OWASP Testing guide.

We also hope to include the OWASP.Net suite of tools by using mono.

The CD is being created in conjunction with Josh Perrrymon at [http://www.packetfocus.com/ Packetfocus].

He can be contacted on:
[mailto:josh.perrymon@packetfocus.com Josh Perrymon]

Also you can contact myself on [mailto:eoin.keary@owasp.org Eoin Keary]

==Newest Release==

December 13, 2004 - Phase One Released
We are glad to announce that The OWASP Testing Project Phase One has finally been released. This covers the processes involved in testing web applications:

* The scope of what to test
* Principles of testing
* Testing techniques explained
* The OWASP testing framework explained.

This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that they need to undertake to build and operate that testing program on their web application

You can now [https://sourceforge.net/project/showfiles.php?group_id=64424&package_id=62285 download] phase one from the OWASP download centre.

==Roadmap==

View the [[OWASP Testing Project Roadmap]]

==News==

'''OWASP Pen Test Checklist in Italian'''
Sun May 22 10:56:39 EDT 2005
I'm glad to announce we have released OWASP Pen Test Checklist in Italian. Thanks to the Italian Chapter, Massimiliano and Mateo for it's great effort to have this document translated. You can download this verion in[http://www.owasp.org/docroot/owasp/misc/OWASPWebAppPenTestList1.1_ITA.pdf PDF] or [http://www.owasp.org/docroot/owasp/misc/OWASPWebAppPenTestList1.1_ITA.doc Word]

'''Checklist ver 1.17 in Spanish'''
Mon Apr 04 15:37:24 EDT 2005
I'm glad to announce we have released OWASP Pen Test Checklist ver 1.17 in Spanish.Thanks to Pedro, Raul and Rogelio for it's great effort to have this document translated and to Christian by helping out with technical edition. You can download this verion [http://www.owasp.org/docroot/owasp/misc/testing_spanish.pdf PDF] or [http://www.owasp.org/docroot/owasp/misc/testing_spanish.doc Word]

==Project Contributors==

Contributors

==Feedback and Participation==

We hope you find the information in the OWASP Testing project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP Testing mailing list. Thanks!

To join the OWASP Testing mailing list or view the archives, please visit the [http://lists.sourceforge.net/lists/listinfo/owasp-testing subscription page].

{{Template:Stub}}

[[Category:OWASP Project]]

Category:OWASP Code Review Project

2006-06-01T12:10:16Z

Eoin: /* Volunteers Needed */

== Project Contributors ==

The OWASP Code Review project was concieved by Eoin Keary the OWASP Ireland Founder and Chapter Lead.
We are actively seeking techies to add new sections as new web technologies emerge.
If you are interested in volunteering for the project, or have a comment, question, or suggestion, please drop me a line mailto:eoin.keary@owasp.org

==Volunteers Needed==

Yes please, drop me a line.
Need help on this one, dont be shy, all help appreciated

==Downloads==

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

==Roadmap==

View the [[OWASP Code Review Project Roadmap]]

{{Template:Stub}}

[[Category:OWASP Project]]

OWASP Code Review Guide Table of Contents

2006-06-01T12:07:36Z

Eoin: /* Buffer Overruns and Overflows */

OWASP Code Review Guide Table of Contents

2006-06-01T12:05:17Z

Eoin: /* Integer overflows: */

OWASP Code Review Guide Table of Contents

2006-06-01T12:04:47Z

Eoin: /* The Format String: */