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

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

I think this should be rewritten.  I find the language harsh,
stereotyping, and needs to be run through a spell-checker.
(BTW, neither "moreso," nor "reckognize" are words in the English
language.) I think the part about educating the user is flat-out
incorrect. Education is beyond the scope of this project.  The
OWASP project as a whole is trying to do that, not this API.
Data-type validation is not even mentioned.  This is, overall,
an inaccurate description of the project.


Nathan




On Tue, 18 Jun 2002, Alex Russell wrote:

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