Friday, May 29, 2009

Preparing For a Third Party Application Assessment

Organizations often contract with third party consulting companies to perform application assessments. These companies usually have a predefined window for assessing applications and may charge by the hour. These characteristics make it important for development groups to ensure the application and staff are adequately prepared for the assessment.

For this discussion, we will assume an application assessment has already been scoped and scheduled. Before the consulting company begins any testing, the development group should use a checklist to ensure the following items have been covered:
  • Appoint a technical contact to handle any questions about code, functionality, or security controls.
  • Appoint a contact to handle account lockouts or other technical difficulties with the environment or application.
  • Send contact information to the consulting company or consultants.
  • Identify and configure a test environment that closely mirrors production.
  • Create appropriate credentials for a range of organizations and privileged levels.
  • Populate the environment with adequate data to allow for testing of all functionality and features.
  • Provide a demonstration of the application and answer technical questions.
Identify and Configure a Test Environment

The test environment should mirror production as closely as possible including the configuration of the operating systems, application servers, back-end components, and the application itself. However, the environment should not persist any transactions or changes in the real world. For example, stock trades, money transfers, etc should appear to complete, but the transaction should not be persisted to any banks.

Create Appropriate Credentials

Each consultant assigned to assess the application needs a range of accounts that allow for testing of horizontal and vertical access controls. This means if the application separates data by organization, company, institution, or some other group, the consultants will need accounts in two or three of these organizational units.

Additionally, within each of these organizational units, consultants require accounts that span several roles, permission, or entitlements. If there are a small set of roles within the application, it may be possible to create test accounts for each role. Otherwise, it may be sufficient to create a sample of accounts, one with no entitlements, one with all entitlements, and a handful of other accounts with varying permission-levels.

Populate the Environment with Adequate Data

In most applications, consultants cannot test functionality without having data associated with their user account. Before consultants begin testing, the application should be populated with test data that allows users to interact with all functionality.

Tuesday, May 19, 2009

Microsoft SDL Process Template

Microsoft has released a Visual Studio module that helps developers adhere to Microsoft's SDL process. This tool has a whole lot of things right such as:
  • Ensuring developers complete security activities before checking in code
  • Providing a workflow for developers to follow
  • Providing SDL process steps, instructions, descriptions, and resources to developers
Tools, such a the SDL Process Template released by Microsoft, can greatly increase the success rate of an organization's migration towards a secure software development process. Once organizations define their own custom secure development process, a similar approach should be used to help make adherence easier.

Check out the video on the following page for more information:

Secure Development Jump Start

Creating a secure development process for an organization is a huge undertaking. There is a tremendous array of options for getting started and no certain metric for determining how long it should take to adopt the process. Some of those options include:
There are some components that all of these processes agree on. Executive level support is a must and security training is required (each process differs on the amount of training, however).

In companies with a small number of developers that have been there for a long period of time, it may make sense to dedicate a large amount of time and money to make them both developers and security experts. For organizations with a large number of developers or high developer turn over rate, it may be more cost efficient to simply provide security awareness training and a set of policies and coding standards to follow.

In any of these situations, several steps you can take to jump start a secure development process for your organization are listed below. It is assumed that your organization values and desires to develop secure code.
  1. Create a policy document addressing application security.
  2. Create a secure coding standard stating the organization's established, secure method for carrying out specific functions.
  3. Provide security awareness training.
  4. Provide training that specifically aims to introduce developers to the application security policies and secure coding standards for the organization.
These steps should fit in to any future secure development process and do not require organizations to spend any security budget dollars on tools. These steps are a starting point and should be joined with a larger, strategic process once the appropriate research and planning is performed.

Application Security Policies

An application security policy document should provide statements or policies that are as specific as possible. A statement such as "All applications should use sufficiently strong cryptographic algorithms" does not provide a developer with enough information to select a secure algorithm. Instead, a statement such as "ACME Bank Corp standardizes on the use of SHA256 as a secure symmetric cryptographic algorithm" should be used.

Other examples include:
"ACME Bank Corp requires all database queries to use parameterized queries or prepared statements. Dynamic or concatenated SQL is prohibited. The ACME Bank Corp secure coding standard provides examples of parameterized queries or prepared statements."

"Untrusted data should be properly output encoded before being included within a web browser page. The appropriate encoding method should be selected based on the context in which the data is being included. The secure coding standard provides example contexts and methods."

The authors of the application security policy document can get policy ideas from resources such as:
OWASP Top 10
2009 CWE/SANS Top 25 Most Dangerous Programming Errors
OWASP Guide Project
ASP.NET 2.0 Check List
ADO.NET 2.0 Check List
.NET 2.0 Check List

Secure Coding Standard

Developers should be able to use the secure coding standard document as a reference guide for writing secure code. The standard should provide the developer with enough information to know when and how to apply a particular code example. An entry such as the following is a good starting point:

Parameterized Queries and Prepared Statements

Addressed Application Security Policy: Parameterized Queries or Stored Procedures, Section 2.1.3
Prevents: SQL Injection
References OWASP Top 10, CWE/SANS Top 25, Security Guidelines: ADO.NET 2.0, OWASP Guide
When to Apply: Anytime an application queries an SQL database
Code Examples:

.NET Parameterized Query, SELECT Statement (example taken from
using System.Data;
using System.Data.SqlClient;

using (SqlConnection connection = new SqlConnection(connectionString))
DataSet userDataset = new DataSet();
SqlDataAdapter myDataAdapter = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id",
myDataAdapter.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myDataAdapter.SelectCommand.Parameters["@au_id"].Value = SSN.Text;

.NET Parameterized Query, UPDATE Statement


.NET Parameterized Query, INSERT Statement


Java Prepared Statement, SELECT
String sql = "SELECT * FROM movies WHERE year_made = ?";
prest = con.prepareStatement(sql);
ResultSet rs1 = prest.executeQuery();
Java Prepared Statement, UPDATE


Security Awareness Training

Security awareness classes are typically used to introduce developers and managers to the types of vulnerabilities found in applications as well as the impact of those issues. When a developer sees for the first time that an SQL injection attack on SQL Server can be used to read arbitrary files and execute DOS commands, a light bulb seems to come on inside their head and they realize they really do need to pay attention and prevent these vulnerabilities.

While these classes often do not arm developers with the proper tools and knowledge for preventing vulnerabilities, a well written application security policy and secure coding standards document should be a great start.

Application Security Policies and Secure Coding Standard Training

Following a security awareness class, it is beneficial to provide a more targeted training opportunity for developers. This course should be focused upon going through the organizations application security policies and coding standards to ensure all developers are aware of these resources and understand how to use and apply them. Following the course, developers can be held accountable for applying the examples in the secure coding standards to their projects.

Process Improvement

It is likely that an application security policy and secure coding standard document will not include all the possible vulnerabilities that could be introduced into a web application. As new issues are identified as part of an assessment, peer review process, or threat model (these steps are usually included within a complete secure development process), additions should be made to both documents. These additions should reflect the organization's recommended approach for developing code without introducing the newly identified flaw. The organization should also periodically review application security concepts and new additions to the policies and standards document with its developers.

Friday, May 8, 2009

ISSA Journal: Web Application Security Portfolios

My article "Web Application Security Portfolios" was published in the May ISSA Journal!

Check it out here (Must be an ISSA member):

Here is another version of the same information.

Monday, May 4, 2009

Light-weight Code Review as You Program (Not After You're Done)

I have been working on a project lately to perform (some) code review as code is written, rather than waiting until it is checked in to cvs/svn/etc. My solution was to create an IDE plug-in that leverages built in features to highlight insecure method calls and suggest alternate code.

When the IDE starts up, it gets an updated list of insecure methods and hints from a web service. Right now I am in the very early stages, so It isn't real pretty or refined yet. For now, I am calling the project Just-in-Time (JIT) Secure Code.

The video below demonstrates the concept in NetBeans.

OWASP ISWG: Struts 2/WebWork Gap Analysis

Arshan Dabirsiaghi recently published "A Gap Analysis of Application Security in Struts2/WebWork" for the OWASP Intrinsic Security Working Group. The paper evaluates the security controls/features that are either built into Struts 2 or can be added by extending the framework.

I had the opportunity to contribute research and code to this paper. The appendix section contains several code examples showing how one might:
  • Create an authentication interceptor
  • Create a roles interceptor (Enforced page-level access controls based on a user's privilege level)
  • Create a caching headers interceptor
  • Prevent CSRF vulnerabilities using the built in tokenSession Interceptor
  • Implement a custom error handler
  • Create an interceptor that enforces SSL
  • Regenerate session IDs when users cross an authentication boundary
The paper can be found here:

The code repository containing updated struts 2 modules can be found below:

Additionally, you can see discussion of these modules in my earlier blog posts: