[Owasp-input-api-developers] yesterday's meeting summary

[Alex R. <al...@se...>]

outline follows sig.
-- 
Alex Russell
al...@Se...
al...@ne...

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

On June 17th, the development team from the Open Web Appliation 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 ammount 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 pathetic
mess, in some cases even moreso 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 reckognize 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 adoptance. The OWASP Filters Team accepts this challenge and is 
comitted
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 inforamtion 
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 charachter
	set conversion to bypass attempts at intput filtering. While multiple
	charachter 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
reqiurements of the project become more clearly defined and iterative
development and developer feedback more tightly define the scope of the
problem.