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

[vertigo <ve...@pa...>]

Better.  Thanks.  Believe it or not, I was a lit major, not
C.S.


Nathan





On Tue, 18 Jun 2002, Alex Russell wrote:

> 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.
>
> ----------------------------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
>
> _______________________________________________
> Owasp-input-api-developers mailing list
> Owa...@li...
> https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers
>