owasp-input-api-developers — Developers for OWASP Input API's

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

[Steven J. S. <sj...@Ju...>]

On 18 Jun 2002, Gabriel Lawrence wrote:
 
> So, I see the first step of this process being developing some simple
> api's that allow developers to start incorporating this stuff into their
> applications. I think at this level it would be key to make this stuff
> as generic as possible as the code will need to be ported to multiple
> environments: Python, Java, PHP, Perl, C/C++, ColdFusion and so on... 

(Apologies for not making it to irc yesterday)

I don't know how "generic" we'll be able to make the code...

> And finally, we need to incorporate technology specific solutions into
> the api so that we can become a layer of protection wrapped around the
> technology supporting it where those technologies are weak or create
> holes.

Is our goal to make this stuff transparent to John Q. Webappdeveloper?
 

-- 
Steve Sobol, CTO  JustThe.net LLC, Mentor On The Lake, OH  888.480.4NET
- I do my best work with one of my cockatiels sitting on each shoulder -
6/4/02:A USA TODAY poll found that 80% of Catholics advocated a zero-tolerance 
stance towards abusive priests. The fact that 20% didn't, scares me...

[Owasp-input-api-developers] turning the problem inside out

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

Ok, so I had a thought this evening. Perhaps we're looking at things in a 
way that's not helping us figure out what works best from an applied 
standpoint.

My thought is that perhaps we should think a bit more about how we might 
filter at _every_ input/output in a system. Seems to me like I have been 
trying to solve the problem of accounting (or filtering) for every possible 
abuse scenario as soon as I get the data, and the more I think about it the 
more I realize that this eventually works against us. I forces me (and end 
developers) to think about every use of their data further down the road 
than is necessaray, breaking the "don't make me think" principle.

So perhaps we can do better by only addressing the immediate threats. Let 
me expand on that before you flame me into oblivion. Consider the following 
scenarios:

	1.) taking form input
	2.) insert a string into my database
	3.) pulling a peice of data out of a database
	4.) displaying data to a client

Were I to consider these data flows through the system as a whole (as they 
could easily be the same piece of data), then I've got some thorny 
questions, and it's my instinct to handle them all up front (which is what 
I've been tempted to design for thus far). But what happens when I get data 
from another input (say a file) and I don't KNOW where it's going to end up 
(as I often may not at various stages in a project)? Well, I have to filter 
for everything and hope I don't loose what I need. Strongly sub-optimal. I 
(at least) have been considering how I'm going to protect the entire system 
from from between items 1 and 2, kinda like:

	(1) -> filter(for everything) -> (2) -> (3) -> (4) 

at which point I'm just left praying that I've thought of everything at 1. 
I also realized this evening that if we design a system that is _capable_ 
of this (easily), that's exactly how it's going to be used.

What might work better from a strictly security-related perspective would 
be to consider boundaries as the important parts of the system, and not 
necessarialy think beyond them. So, for instance, consider getting intput 
from a form. My intput is from the server, my output is to the runtime. If 
I concern myself only with the threats exposed at this boundary, my job 
gets a lot more managable. I only have to filter at this boundary for 
things that adversely affect me in the runtime.

Now consider (2). If I do boundary-centric filtering, I concern myself with 
the input from the runtime environment (which I can call a "dirty" input 
from the persepctive of the DB) and only worry about the class of things 
that can go wrong with the boundary I'm crossing: SQL injection, SQL type 
mismatches, etc. I've strictly defined what the types are on either side 
(because one side enforces them) and so I don't have ot worry about 
cross-language problems: I'm talking SQL, it has requirements that my 
filter at this boundary MUST be conscious of. We filter the malicious 
inputs to my subsystem here and move on.

But you say "what about XSS?!?, you're ignoring it!!". Yes, I am. But not 
for long. Consider the SELECT from the DB into a variable in my runtime: if 
I consider the input from the SQL "dirty", I can strongly filter all my 
inputs to the environment and not have to worry about "where" the data came 
from (which is really "what boundary did it pass from to get into the 
DB?"). All I have to worry about are my current boundaries.

Likewise when I output from the runtime to an external listener (whatever 
it may be). I have NO CLUE how my data is going to really be used between 
(1) and (2), but at the outbound from the environment to the end client, I 
know a LOT more about who I have to protect and how.

So here's what I'm proposing: we define "boundary" filters, not 
necessarialy filters for one type of attack or another. We could implement 
these using a common signature backend or whatever (although I think that's 
way too much overhead, personally). By implementing the toolkit this way, 
we will "force" developers to think of their data as "tainted" as it 
crosses each boundary (which is a sane assumption, actually), while at the 
same time breaking up the load of filtering and the mental load of tracing 
data through the system explicitly.

As an added benefit, large projects that may be developed by many 
developers often NEVER know where data REALLY comes from or goes to, or for 
that matter what touches it in between. By breaking up our task into 
boundary based segments, we can enable large projects like this to become 
hardened in a sysetmic way that doesn't require the kinds of complex 
context that can easily become mishmashed in the minds of developers.

Possible downsides: filtering at the boundary is drop dead simple in terms 
of what an implementer has to know how to use at each step, but it does 
mean that security has to be "added" at each step. This creates more raw 
locations in code where the API has to be applied, and that might be a 
significant detractor. A "scanner" that looks for I/O calls might be one 
way to address this issue. Grouping of boundary checkers (providing 
combinations of the most common boundaries?) might also be a way to 
decrease this problem, but overall I feel that once a developer is "used 
to" applying filters everywhere, this might become less of a concern.

The more I consider the sheer number of permeutations that we would have to 
provide for when doing "monolithic" filtering, the less approachable the 
problem seems. By breaking it up into situations where we filter at every 
boundary crossing, we can provide much simpler syntax that directly 
addresses the problems presented at each "place" in the system.

Thoughts?

-- 
Alex Russell
al...@Se...
al...@ne...

Re: [Owasp-input-api-developers] OO, Dumb Programmes, and Strongly-Typed Languages

[Matt W. <wi...@ce...>]

On Tuesday 18 June 2002 15:51, vertigo wrote:
>    I am uncertain of the experience with and opinions toward OO
> that the group may have. =20

There's nothing really wrong with OO.  I believe the bulk of our target l=
anguages=20
support it (perl,python,asp,C++, Java, PHP, ruby) albeit Perl's OOP is di=
rty -- its pretty
much "stapled on", but it does work (though, if Perl6 ever becomes non-va=
porware, this'll change).

> The word "function" seemed to pervade
> the conversation, as in "wrap _EVERYTHING_ with one of our fun-
> ctions." The design I had in mind involved adding unfiltered
> parameters to a filter object, calling the filter() method, then
> retrieving filtered parameters from it, as in the following
> lines of code:

Here's where I begin to disagree.   The bulk of your web app developers (=
commercial or personal)
are not going to want tons of object instantiations and umpteen method in=
vocations just to get one lousy
stinking "cleaned" piece of data.

>
> public class myServlet extends HTTPServlet {
>
> =09Filter f =3D new Filter("/usr/local/filters/etc/filters.xml");
>
> =09public void doGet(HttpServletRequest req,
> =09=09=09  HttpServletResponse res) throws
> ServletException,
> =09=09=09=09=09=09=09  IOException
> =09{
> =09=09Integer userID;
> =09=09String userName;
>
1 > =09=09f.addParameter("username", req.getParameter("username"),
 > "java.lang.String");
2 > =09=09f.addParameter("userID", req.getParameter("userID"),
> "java.lang.Integer");
3 > =09=09f.addScanner(new
4 > OwaspScanner("/usr/local/filters/etc/signatures.xml.gz"));
>
5 > =09=09f.filter();
6 > =09=09f.scanParameter("username");
7 > =09=09userName =3D f.getFilteredParameter("username");
8 > =09=09userID =3D f.getFilteredParameter("userID");
> =09=09(....)
> =09}
> }
>

8 bloody lines for two pieces of data!!  At this point, I'd say "to hell =
with it", and do one of two things:

1) I'm ignorant or I don't care.  I just don't do anything.
2)  Write up a simple function for each type of data I'm handling and cal=
l it when I need it.
     Or, use simple constructs my language provides.
     E.g., PHP provides a mysql_escape_string() function to escape out th=
e nasties.
     Or, I'll use the "?" syntax in my perl or python apps.. if some mist=
yped data gets in there,=20
=09my db will catch it, error out, and I'll just die() the script.

What I'd like to be able with this toolkit is this:
(And shucks folks, we'll even do it with OO in  my own whacked out pseudo=
 code)

--begin myIncludeFile.inc --
=09myFilterRuleset =3D new FilterRuleSetObject( some_data )
=09=09// I don't know what we'll use, to me XML is just a PITA
=09myFilter =3D new Filter(myFilterRuleSet)
--end myIncludeFile.inc--

--begin myapp--
require myIncludeFile.inc

//say we want to retrieve and store some data in a database
user_id =3D (int) myFilter(request.param('user_id'), __SQL_FILTER__)
message =3D myFilter(request.param('message'), __SQL_FILTER__)

/* store this data */
(...)

//say we want to retrieve and display some data to the user
/* grab data from database */

print myFilter(db_result['message'], __XSS_FILTER__, __HTML_FILTER__)

--end myapp--

There, very simple to use in the app.  I'll only define my filter ruleset=
 once (since it may be complicated), or as needed.
I quickly get my cleaned data and let the filter object handle all the sc=
anning and cleaning based upon the filter ruleset object.


>
>
>    The filter class is fairly complicated, and this is a sim-
> plification.  I think, however, it shows the basics.

Sure, it may be complicated but it shouldn't be complicated or a hassle t=
o use.
 =20
> This being said, I have tried to
> look at this application from the perspective of what __I__
> would like to see in it, and not necessarily what the average
> user would like to see. =20

Sure, we all do that. =20

> I want to avoid the lowest-common-
> denominator approach to development.=20
> We are not making a tool
> for checking one's eBay auctions.  We are developing a tool for
> programmers who are interested in and dedicated to the security
> of their applications

Yes,  to hell with all of the people who may be new to this and are looki=
ng
for something helpful to start.
Seriously, it should be easy to use.  Good documentation will then make i=
t
easy to at least understand the concepts involved with filtering the data=
=2E
Hopefully this will lead to a more learned individual, at least wrt data =
filtering.

>    One of the capabilities that Mark Curphey expressed interest
> in is range checking.  This implies data-types.  A good article
> on the subject of data-type validation (please excuse the Java
> focus) can be found at:
>
> http://www.javaworld.com/javaworld/jw-09-2000/jw-0908-validation.html
>
> I would like this product to have the capability of fine-grained
> and course-grained data-type validation, and I have already
> assured him that it will. =20

I 100% disagree..  By allowing range checking, if I understand what you m=
ean correctly,=20
 we are beginning to write the developer's project for=20
him/her.  We can't predict what the user wants.  There would have to be a=
 lot of flexibility to
do this right.  It just makes it more complicated.

If my usernames should be between 8 to 20 characters, then I should check=
 that myself, not
tell the filter to do it for me.   =20

> Data-type validation does not mean an
> all-inclusive class for checking data-types.  It involves
> creating a collection of validation classes, each intended to
> validate a well-defined set of types (e.g. the set of SQL Server
> 6.5 types, and the set of SQL Server 7 types, and the set of ANSI
> C types).  This may seem too language- or platform-specific to
> some, but I believe data-type validation is at the heart of this
> application, and signature scanning secondary.

Nothing that  a simple cast, where applicable, can handle.
Doing otherwise will only suffice to make the project an albatross.

Most people aren't using strongly typed high level programming languages
to write web applications (anymore).  Although I would concede that Java =
is becoming more
popular, especially wrt JSP.

-matt

--=20
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce... -- [765]49-67707

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
>

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

[Gabriel L. <ga...@bu...>]

Thanx for putting this out so quick.

Sounds to me like there is still some disagreement on what and where
this project should go. I'd like to try and facilitate a discussion on
this.

So, up to now I've been more of a facilitator then a participant... Let
me participate a little.

First, I kind of feel like we've been setting our sites a little low -
and have been oversimplifying what we need to do. 

What I think we should be trying to do is to build a multi-layered
multi-language set of tools to make developing secure web applications
simple and easy. What I think this goal implies is that we need to look
at tools to help in most of the situations web applications developers
find themselves in trouble. From the simple side of things which is data
validation/cleaning to the more complex side which includes things like
helping detect parameter tampering and such (basically where critical
information is foolishly encoded into hidden values in forms) and such.

So, I see the first step of this process being developing some simple
api's that allow developers to start incorporating this stuff into their
applications. I think at this level it would be key to make this stuff
as generic as possible as the code will need to be ported to multiple
environments: Python, Java, PHP, Perl, C/C++, ColdFusion and so on... 

Then once this basic layer is built, we need to start looking at how to
incorporate this stuff into the general flow of things to make it
somewhat easy and automatic for developers to incorporate it.

And finally, we need to incorporate technology specific solutions into
the api so that we can become a layer of protection wrapped around the
technology supporting it where those technologies are weak or create
holes.

So, I actually think that alex's document describes the foundation of
what my vision is for at least the first phase of what I think we should
do... 

-gabe

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
>

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

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

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.

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

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

On Tuesday 18 June 2002 04:10 pm, vertigo wrote:
> 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.) 

um, I'm pretty sure the word "draft" appears on there at least once...no, I 
cant spell (or type, apparently), but I figured we should at least get it 
out for discussion before picking every nit. I'll send out a spell checked 
version ASAP.

> I think the part about educating the user is flat-out
> incorrect. Education is beyond the scope of this project. 

then we fail our target audience by not providing them with the biggest 
tool in improving security: an understanding of the problems at hand.

> The OWASP project as a whole is trying to do that, not this API.

yes, and we should use those tools as part of our effort. No, we can't make 
the developer read, but we can provide good docs that address the issues up 
front and provide links etc to help them understand them. Half the value of 
good security tools is that they inform while they lock things down, and we 
should aspire to that. Security tools that we don't understand are mostly 
useless since they'll get missapplied and missunderstood as silver bullets. 
As a security engineer, I humbly suggest we not go down that road.

> Data-type validation is not even mentioned. 

For good reason, it's not relevant in the macroscopic sense. Note the 
section about "language specific idioms". data-type validation qualifies as 
a language specific idiom. We also agreed that casting was the application 
developers problem (not that we shouldn't educate them about it).

> This is, overall, an inaccurate description of the project.

Well, that's for the consensus to decide.
Feel free to jump in guys.

PS, please trim replies.

-- 
Alex Russell
al...@Se...
al...@ne...

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
>

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

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

I disagree completely with the "drop in functions" descriptions.

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
>

[Owasp-input-api-developers] OO, Dumb Programmes, and Strongly-Typed Languages

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

Group,

   Yesterday's meeting was very helpful, but I would like to
address a few concerns before we continue.  These are: object
orientation, our target audience, and data-types.  As a Java
programmer and proponent of object-oriented development I would
like development to be as object-oriented as possible.  I also
disagree with the assumption that the programmers we are
targetting as potential users of this API are ignorant of fun-
damental persistence issues like not being able to fit a 4000
character string into a 255 character VARCHAR field.  This leads
to my third concern--data types.  This may seem too "language-
dependent" to most people, but even when I use Perl, I filter my
fields to make sure they match the types in the database.

   I am uncertain of the experience with and opinions toward OO
that the group may have.  The word "function" seemed to pervade
the conversation, as in "wrap _EVERYTHING_ with one of our fun-
ctions." The design I had in mind involved adding unfiltered
parameters to a filter object, calling the filter() method, then
retrieving filtered parameters from it, as in the following
lines of code:

public class myServlet extends HTTPServlet {

	Filter f = new Filter("/usr/local/filters/etc/filters.xml");

	public void doGet(HttpServletRequest req,
			  HttpServletResponse res) throws
ServletException,
							  IOException
	{
		Integer userID;
		String userName;

		f.addParameter("username", req.getParameter("username"),
"java.lang.String");
		f.addParameter("userID", req.getParameter("userID"),
"java.lang.Integer");
		f.addScanner(new
OwaspScanner("/usr/local/filters/etc/signatures.xml.gz"));

		f.filter();
		f.scanParameter("username");
		userName = f.getFilteredParameter("username");
		userID = f.getFilteredParameter("userID");
		(....)
	}
}


A UML representation would look something like:

|-------------------|                       |--------------|
|      Filter       |			    |  Parameter   |
|-------------------|			    |--------------|
|#parameters[]      |1		       0..* |              |
|#filteredparams[]  |---------------------->|              |
|-------------------|                       |--------------|
|+addParameter()    |
|+filter()          |
|+getFilteredParam()|
---------------------


   The filter class is fairly complicated, and this is a sim-
plification.  I think, however, it shows the basics.  From a
cross-platform perspective, the returned value does not have to
be strongly typed.  In a Perl implementation, the accessors
would just return a scalar.  It would, however, be a scalar that
has been filtered, and perhaps modified to fit into a field of
a certain type w/in the application's RDBMS.  On a side note, I
think we need to separate the concepts of validation and sig-
nature scanning, with systems dedicated to both processes.
   One of the more significant goals I believe we should set is
creating the public interface to the API (e.g. canonicalize(),
scan(), validate(), etc.).

   Having been a SQL Server developer previous to being a Java
developer, as well as having development experience with mySQL,
PostgreSQL, Oracle, and BerkeleyDB (it's simple, but useful in
a pinch) I have a decent understanding of persistence that not
all developers may posess.  This being said, I have tried to
look at this application from the perspective of what __I__
would like to see in it, and not necessarily what the average
user would like to see.  I want to avoid the lowest-common-
denominator approach to development.  We are not making a tool
for checking one's eBay auctions.  We are developing a tool for
programmers who are interested in and dedicated to the security
of their applications--and a tool that can be easily modified
without having to send the entire app back to QA for a week (or
longer) when one decides to scan for a new signature.

   One of the capabilities that Mark Curphey expressed interest
in is range checking.  This implies data-types.  A good article
on the subject of data-type validation (please excuse the Java
focus) can be found at:

http://www.javaworld.com/javaworld/jw-09-2000/jw-0908-validation.html

I would like this product to have the capability of fine-grained
and course-grained data-type validation, and I have already
assured him that it will.  Data-type validation does not mean an
all-inclusive class for checking data-types.  It involves
creating a collection of validation classes, each intended to
validate a well-defined set of types (e.g. the set of SQL Server
6.5 types, and the set of SQL Server 7 types, and the set of ANSI
C types).  This may seem too language- or platform-specific to
some, but I believe data-type validation is at the heart of this
application, and signature scanning secondary.

I hope this has clarified my concerns, and perhaps some of my own
design goals.


Nathan

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

[Owasp-input-api-developers] Unicode, canonicalization

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

http://online.securityfocus.com/infocus/1232

it's a discussion about NIDS systems, but the truth of the matter is that 
this is a discussion of exactly what I was talking about yesterday in terms 
of canonicalization.

-- 
Alex Russell
al...@Se...
al...@ne...

[Owasp-input-api-developers] Action Items From Meeting

[Gabriel L. <ga...@bu...>]

Attending (In order of intruduction):

Nathan Groupp, ve...@pa...
Gabriel Lawrence, ga...@bu...
Alex Russell, al...@Se..., al...@ne...
Matt Wirges, wi...@ce...
nik cubrilovic, ni...@ni...

Alex will be documenting the general set of problems we are attacking
our goals to solve them and the general principles we will use. That
will be ciculated on this list for comments/feedback and general
approval.

I've attached the transcript of the meeting to this email.

-gabe

[Owasp-input-api-developers] Bio, Nathan H. Groupp

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

Just trying to catch up after a long weekend with an unexpected lack of
internet access...

My name is Nathan Groupp and I am (ahem), the somewhat disorganized
technical lead.  Without making this sound too much like a cover-letter,
I am a Java developer, with a leaning toward security.  A late-comer
to the New York dot-com disaster, my professional security experience was
developed at a company called Phlair, Inc., who essentially man-in-the-
middled SSL (but not quite).

The bulk of my security experience, however, was developed outside of
institutional confines.  A long-time 2600 fan, I ran CAT5 at Notwork
(when it moved downstairs), sold Major Hacking cookies at Beyond Hope, and
have been generally involved with the NYC scene for some time.  My first
experience with security was when I saw my first telnet prompt, which
was, in a round-about way, discovered using Toneloc.

Nathan, a.k.a Vertigo
http://www.setec.org/lists/port0/

[Owasp-input-api-developers] An introduction...

[Matt W. <wi...@ce...>]

Hello all,=20
=09
=09I finally decided to introduce myself!  My name is Matt Wirges, I am a=
=20
developer on the CERIAS Incident Response Database under Dr. Pascal Meuni=
er=20
(that name might ring a bell if you are familiar with Cassandra). =20

=09I have had loads of PHP and Perl web programming experience along with=
 a=20
healthy dose of Python and Python/Zope experience.  I believe this projec=
t=20
could prove to be very helpful to "aware" web programmers, as well as tea=
ch=20
new and ignorant programmers the dangers that await their web application=
s=20
and how to avoid this malicious data and other such attacks.=20

=09Unfortunately (for my bank account ;>) I am doing this as an outside-o=
f-work=20
project, and being that 10pm London time is 4pm EST (assuming London is=20
GMT+1) I may be unable to make it because of current work commitments.. =20
Hopefully I can spare some time. :-)=20

I look forward to contributing to this project and to work with all of yo=
u!

-matt

--=20
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce... -- [765]49-67707

[Owasp-input-api-developers] vacation

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

I apologize for being out of contact.  I went away for a long weekend,
expecting to have internet access, but didn't.  I just returned and will
be catching upt this afternoon.

Nathan

Re: [Owasp-input-api-developers] Re: Filters Project

[Gabriel L. <ga...@bu...>]

Yep. Lets do it on EFNet. See you all then!

-gabe

On Mon, 2002-06-17 at 02:00, Nik Cubrilovic wrote:
> 
> 10PM Monday night London time is fine, are we just going to use EFNet?
> I am just idling in #owasp on efnet if anybody wants to join.
> 
> -Nik
> 
> On Sun, 16 Jun 2002, Steven J. Sobol wrote:
> 
> > On 15 Jun 2002, Gabriel Lawrence wrote:
> >
> > > Seems like people are wanting IRC for weekly meetings. As it appears we
> > > have people in Australia, England and USA I suspect we will have a hard
> > > time finding the best time where we are all awake to conduct them.
> > > Because of this its very important that whatever method we choose, we
> > > can get a full log to post to the site. I'll check and make sure my irc
> > > client can do this.
> > >
> > > I suspect we may want to do it at 10PM London Time, 7:00AM Sydney time,
> > > 2:00pm San Jose Time as this seems to put the folks on either side of
> > > the time spectrum at almost resonable daylight hours... Let me know if I
> > > messed up the time zone math. Not my strong point ;-)
> >
> > That's 5pm Eastern time, which is where I am (Great Lakes region of .us).
> >
> > I'll try to make it work :)
> >
> > --
> > Steve Sobol, CTO  JustThe.net LLC, Mentor On The Lake, OH  888.480.4NET
> > - I do my best work with one of my cockatiels sitting on each shoulder -
> > 6/4/02:A USA TODAY poll found that 80% of Catholics advocated a zero-tolerance
> > stance towards abusive priests. The fact that 20% didn't, scares me...
> >
> >
> >
> > _______________________________________________________________
> >
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Owasp-input-api-developers mailing list
> > Owa...@li...
> > https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers
> >
> 

Re: [Owasp-input-api-developers] Re: Filters Project

[Tod H. <th...@ap...>]

On Saturday 15 June 2002 13:00, Gabriel Lawrence wrote:
> Seems like people are wanting IRC for weekly meetings. As it appears we
> have people in Australia, England and USA I suspect we will have a hard
> time finding the best time where we are all awake to conduct them.
> Because of this its very important that whatever method we choose, we
> can get a full log to post to the site. I'll check and make sure my irc
> client can do this.

Its Cheese to set up an IRC bot that can capture a transcript from a 
channel...

For that matter we can set up our own private IRC server. I've done it 
before, its pretty easy.

>
> I suspect we may want to do it at 10PM London Time, 7:00AM Sydney time,
> 2:00pm San Jose Time as this seems to put the folks on either side of
> the time spectrum at almost resonable daylight hours... Let me know if I
> messed up the time zone math. Not my strong point ;-)
>
> Do these times work for everyone?
>
> -gabe
>
> On Sat, 2002-06-15 at 07:12, Nik Cubrilovic wrote:
> > sounds good gabe.
> >
> > how about irc for weekly meetings?
> >
> > -nik
> >
> > On Fri, 14 Jun 2002, Mark Curphey wrote:
> > > Looks perfect !
> > >
> > > You know I hate AOL AIM as well but with the Linux and Trillian
> > > clients, webscarab team have been using it for weekly cats on Sunday.

Re: [Owasp-input-api-developers] Re: Filters Project

[Tod H. <th...@ap...>]

On Saturday 15 June 2002 10:12, Nik Cubrilovic wrote:
> sounds good gabe.
>
> how about irc for weekly meetings?

I'd definitely vote for IRC... My AIM access is via Jabber, and AOL has 
successfully porked their ability to do multi-way chat. For that matter, I'm 
just tired of proprietary instant messaging, those guys need to get their act 
together ;o).

>
> -nik
>
> On Fri, 14 Jun 2002, Mark Curphey wrote:
> > Looks perfect !
> >
> > You know I hate AOL AIM as well but with the Linux and Trillian clients,
> > webscarab team have been using it for weekly cats on Sunday.

Re: [Owasp-input-api-developers] Re: Filters Project

[Nik C. <ni...@ni...>]

10PM Monday night London time is fine, are we just going to use EFNet?
I am just idling in #owasp on efnet if anybody wants to join.

-Nik

On Sun, 16 Jun 2002, Steven J. Sobol wrote:

> On 15 Jun 2002, Gabriel Lawrence wrote:
>
> > Seems like people are wanting IRC for weekly meetings. As it appears we
> > have people in Australia, England and USA I suspect we will have a hard
> > time finding the best time where we are all awake to conduct them.
> > Because of this its very important that whatever method we choose, we
> > can get a full log to post to the site. I'll check and make sure my irc
> > client can do this.
> >
> > I suspect we may want to do it at 10PM London Time, 7:00AM Sydney time,
> > 2:00pm San Jose Time as this seems to put the folks on either side of
> > the time spectrum at almost resonable daylight hours... Let me know if I
> > messed up the time zone math. Not my strong point ;-)
>
> That's 5pm Eastern time, which is where I am (Great Lakes region of .us).
>
> I'll try to make it work :)
>
> --
> Steve Sobol, CTO  JustThe.net LLC, Mentor On The Lake, OH  888.480.4NET
> - I do my best work with one of my cockatiels sitting on each shoulder -
> 6/4/02:A USA TODAY poll found that 80% of Catholics advocated a zero-tolerance
> stance towards abusive priests. The fact that 20% didn't, scares me...
>
>
>
> _______________________________________________________________
>
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Owasp-input-api-developers mailing list
> Owa...@li...
> https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers
>

Re: [Owasp-input-api-developers] Re: Filters Project

[Steven J. S. <sj...@Ju...>]

On 15 Jun 2002, Gabriel Lawrence wrote:

> Seems like people are wanting IRC for weekly meetings. As it appears we
> have people in Australia, England and USA I suspect we will have a hard
> time finding the best time where we are all awake to conduct them.
> Because of this its very important that whatever method we choose, we
> can get a full log to post to the site. I'll check and make sure my irc
> client can do this.
> 
> I suspect we may want to do it at 10PM London Time, 7:00AM Sydney time,
> 2:00pm San Jose Time as this seems to put the folks on either side of
> the time spectrum at almost resonable daylight hours... Let me know if I
> messed up the time zone math. Not my strong point ;-) 

That's 5pm Eastern time, which is where I am (Great Lakes region of .us).

I'll try to make it work :)

-- 
Steve Sobol, CTO  JustThe.net LLC, Mentor On The Lake, OH  888.480.4NET
- I do my best work with one of my cockatiels sitting on each shoulder -
6/4/02:A USA TODAY poll found that 80% of Catholics advocated a zero-tolerance 
stance towards abusive priests. The fact that 20% didn't, scares me...

Re: [Owasp-input-api-developers] Re: Filters Project

[Gabriel L. <ga...@bu...>]

Seems like people are wanting IRC for weekly meetings. As it appears we
have people in Australia, England and USA I suspect we will have a hard
time finding the best time where we are all awake to conduct them.
Because of this its very important that whatever method we choose, we
can get a full log to post to the site. I'll check and make sure my irc
client can do this.

I suspect we may want to do it at 10PM London Time, 7:00AM Sydney time,
2:00pm San Jose Time as this seems to put the folks on either side of
the time spectrum at almost resonable daylight hours... Let me know if I
messed up the time zone math. Not my strong point ;-) 

Do these times work for everyone?

-gabe


On Sat, 2002-06-15 at 07:12, Nik Cubrilovic wrote:
> 
> sounds good gabe.
> 
> how about irc for weekly meetings?
> 
> -nik
> 
> On Fri, 14 Jun 2002, Mark Curphey wrote:
> 
> > Looks perfect !
> >
> > You know I hate AOL AIM as well but with the Linux and Trillian clients,
> > webscarab team have been using it for weekly cats on Sunday.
> >
> 

Re: [Owasp-input-api-developers] Re: Filters Project

[Nik C. <ni...@ni...>]

sounds good gabe.

how about irc for weekly meetings?

-nik

On Fri, 14 Jun 2002, Mark Curphey wrote:

> Looks perfect !
>
> You know I hate AOL AIM as well but with the Linux and Trillian clients,
> webscarab team have been using it for weekly cats on Sunday.
>

[Owasp-input-api-developers] Just renamed the project...

[Gabriel L. <ga...@bu...>]

In order to get things to match closer to the OWASP project name, I've
changed the name on the sourceforge projec to "OWASP Filter Project."
Let me know if this screws anything up and I'll see if I can't undo the
change... As far as getting some of the other things to match such as
the email list that might be more trouble. It seems the email list
ownership has been foobar'd a little and we may have to create a new
list. I'm hoping to avoid that as loosing history is always a drag.

-gabe