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

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

Ok, I'll be nicer this time.  I apologize for sounding harsh.  (A little
payback for the comment regarding buzzword compliant I guess.) I'm sure
you worked hard on that.  I propose the following changes:

1) "drop in functions/object/methods"
change to:

"drop in functions or classes."
(objects are, traditionally, instantiated classes, though this terminology
was challenged in the book "Object Oriented Methods.")



2) "The current state of web application security . . . a mess."

change to:
"The current state of web-application security is disastrous, and in some
cases weaker than the security of traditional applications."

(a __little__ hyperbole helps sometimes)


3) "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."

change to:

"The Filters API will be designed to provide the greatest effect with the
least effort--filtering a large number of attacks by making only minor
modifications to existing code."


4) "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."

change to:
"Few web application developers are familiar with even basic security
design principles.  Fewer still are aware of the security solutions
available to them.  While the preferred method of securing a
web-application is a complete redesign incorporating secure design
principles, we are aware of the time, effort, and money involved in
undertaking such a project.  This API will allow developers to harden
their applications with a minimum of effort and security-domain
knowledge."




5) "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."

change to:
"We understand that budget constraints and deadlines are often more
important than security.  Security tools must be presented in a
way that will allow rapid integration with existing applications.
The OWASP Filters Team accepts this challenge and is committed to
providing simple yet powerful tools for developers that enhance
security."

(I am not a big fan of the "lazy developer" stereotype.)

I think we also need to fill-out the section on
request.allow/request.deny.  The policy section is a little unclear.  I
think once we make some decisions regarding a policy framework, we can
include this in another document.  For now, we might try saying something
like:

"Filters will be skeptical by default, denying application access to all
requests except those that match well-defined criteria."

Or something similar.


That's all for now.  I apologize again for being harsh.  I've been a
little stressed.

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
>