Thread: [Owasp-input-api-developers] spell checked version.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

INTRODUCTION:
------------------------------------------------------------------------------

On June 17th, the development team from the Open Web Application Security
Project (OWASP) filters project met to discuss the goals of the project and 
to lay out general design principles that will be followed in the course of 
their development effort. What follows is a summary of the primary points of
agreement that resulted from this meeting.

Those who attended the meeting were:
	Nathan Groupp, ve...@pa...
	Gabriel Lawrence, ga...@bu...
	Alex Russell, al...@Se..., al...@ne...
	Matt Wirges, wi...@ce...
	Nik Cubrilovic, ni...@ni...

PROJECT GOALS:
------------------------------------------------------------------------------

The chief goal of the OWASP filters project will be to develop a set of 
"drop in" functions/objects/methods that provide web application developers 
with a powerful and effective way of managing inputs to their applications. 
These filters will be designed in such a way as to minimize the amount of 
syntax needed to filter content for a range of possible malicious inputs.

PROBLEM STATEMENT:
------------------------------------------------------------------------------

The current state of web application security (in the large) is a mess, in 
some cases even more so than that of traditional applications. Few web 
application developers are familiar with even basic security design 
principles and even fewer understand the options available to them with 
regards to securing their applications. While structural solutions to the 
large security problems facing web applications are strongly preferred, we 
recognize the need for tools that will allow developers harden their 
applications with a minimum of effort and security-domain knowledge.

Through use of our tools, developers should become educated about the issues
involved with input validation to their applications, and it is our hope 
that they will also make use of the other tools and document that OWASP 
produces in their efforts to improve security. Yet we are also realistic. 
We understand that the path of least resistance is that which lazy 
developers will follow, and security tools must be presented in a way that 
decrease resistance to their adoption. The OWASP Filters Team accepts this 
challenge and is committed to providing simple yet powerful tools for 
developers that enhance security.

DESIGN GOALS:
------------------------------------------------------------------------------

Filters MUST be developed in many languages to allow end developers to use a
similar framework for filtering input regardless of their development
environment. Language specific idioms for sanity checking MAY be supported
where they make sense, but never at the expense of simplicity.

The default policy for filter rules MUST be "reject all not explicitly
allowed", forcing developers to consider what they want to allow instead of
attempting to cover all corner cases for input that may be malicious.

Filtering will be addressed in 3 discrete steps:

	1.) canonicalization
	2.) threat specific filtering
	3.) output specific filtering

Note that each of these steps SHOULD be addressed both on information 
inbound
to the system from external sources and for information originating from
internal sources destined for output to end users. 

1.) Canonicalization

	Canonicalization is the process of putting data into a common format.
	This step is critical to the effectiveness of input filtering, as it
	guards against entire classes of attacks that make use of character
	set conversion to bypass attempts at intput filtering. While multiple
	character sets SHOULD be supported, a sane default SHOULD be assumed
	(UTF-8 restricted?).

2.) Threat Specific Filtering

	A default "reject" rule MUST be in place for input passed to OWASP
	filters, however users MAY be given the ability to specifically
	allow types of input that my in some contexts be harmful. Examples of
	these types of input may be HTML, JavaScript, SQL, etc...

	There are instances where a developer may wish to allow punctuation
	that may have syntactic significance, and so an interface MAY be
	exposed to allow developers to explicitly define such syntax
	exceptions.

	Language specific filtering capability SHOULD be available to deal
	with threats such as interpreted command insertion. Where possible the
	OWASP filters team will discourage use of eval() type functions on
	the part of developers, yet should realize that the job of a filter
	can only cover so much ground. Protecting developers from misuse of
	system and language features is better dealt with via a source code
	scanner.

3.) Output Specific Filtering

	Output formats MAY have special formatting considerations, and the
	filters API MAY choose to provide simple methods for converting to
	"storage safe" escaped versions of content (and back again).

CONCLUSION:
------------------------------------------------------------------------------

This is only a draft of this document and MAY be subject to change as the
requirements of the project become more clearly defined and iterative
development and developer feedback more tightly define the scope of the
problem.

Thread: [Owasp-input-api-developers] spell checked version.

owasp-input-api-developers