owasp-input-api-developers

Re: [Owasp-input-api-developers] My thoughts on requirements

[<Chr...@ey...>]

Gabe,

Hehe, maybe I have an incorrect understanding of what is meant by 
requirements (a distinct possibility), but what you have below is what 
imagined the Vision statement would be.  I guess I always imagined 
requirements as being specific statements of things a program must do, 
e.g. "the program must core dump and cause the blue screen of death when 
the user clicks the save button."  Nonetheless, I like what you have 
below, regardless of whether it is a set of requirements or a vision 
statement. 

While I like some of the things you are saying in point #5, I have 
concerns about some of the wording.  For example, I thought the focus of 
this project was writing an API for scrubbing user input, not creating "tools and design patterns to help me build a totally secure web 
application".  No application is totally secure, or ever has been, or ever will be.

If what you are suggesting is that the API be extensible, that sounds like 
a good idea on the surface, except that it is in direct conflict with 
"simple".  If we do not trust developers to use the API correctly unless 
we make it simple, then what makes us think that they will extend the 
framework without making it insecure in the process?

Just my 2 cents, for whatever they're worth.

Chris





owa...@li...
06/27/2002 12:34 AM

 
        To:     Owasp Filter <owa...@li...>
        cc: 
        Subject:        [Owasp-input-api-developers] My thoughts on requirements


Here's some thoughts on high level requirements for the filters project.
I hope this can serve somewhat as an example, but also as a diving off
place...

1. Support for all major web application development platforms
                 This is really critical to be the security standard for 
web
applications and also to be very complete. But, I think its also pretty
important to highlight at a high level so that when we do designs we can
do designs that facilitate development for the different platforms. By
platforms I'm thinking J2EE/JSP/Servlets, ColdFusion, ASP, PHP, .Net,
Perl, ...

2. Simple to use
                 Security is hard to begin with, but forcing developers to 
jump through
hoops isn't realistic given schedule needs, developers experience and
knowlege, developer acceptance of the api, and such. Because of this, it
really needs to be something that the developer can easily integrate
into their application, and has some clear easy to follow steps to put
it in in the right places to offer real security.

3. Flexible
                 This one is somewhat in conflict with the one above, but 
I think we can
remedy this in the design process by building mutliple layers that allow
interaction in different ways. So, while I may want to just have
something that will slide into to the development platform I'm using, I
think I'd also like something I can put into a novel application that
could be built from scratch or something that can be used with an
application that is using http to do new and exiting things. Along the
lines of the diff between http proper and http extended to handle
WebDAV.

4. Safe
                 This api should do what it says it should do and should 
be very clear
about where it stops, so that I understand what I'm protected from and
what I'm left to do on my own. When it says it protects from something,
there shouldn't be a sneaky way around it. (in lot of ways this is
really where I think canonicalization fits in...)

5. Complete
                 It should offer tools and design patterns to help me 
build a totally
secure web application. Where building generic tools to accomplish the
job doesn't really fit, this api should allow me to enhance or extend it
and in fact encourage me to so that my specific needs are met for
enhancing security. For instance, in the case of data type validation.
Suppose I have an ID parameter that is used to determine what document
we are downloading from a dynamic web application. Some ids are allowed
for some users and others are not... This is really a very common design
pattern for web applications and a poplular spot for security problems.
While its good for us to be able to validate at least that we are
getting a numeric value, it would be really nice to be able to plug in
acceptable values to custom code, a collection in the platforms session
store, a (potentially cached) database query and so forth... 

I kind of feel like these things might be a little bit higher level then
they should be, but maybe they will serve as a tool to get the ball
rolling.

-gabe





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



________________________________________________________________________
The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  Ernst & Young LLP

Re: [Owasp-input-api-developers] My thoughts on requirements

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

On Thu, 2002-06-27 at 07:08, Chr...@ey... wrote:
> Gabe,
> 
> Hehe, maybe I have an incorrect understanding of what is meant by 
> requirements (a distinct possibility), but what you have below is what 
> imagined the Vision statement would be.  I guess I always imagined 
> requirements as being specific statements of things a program must do, 
> e.g. "the program must core dump and cause the blue screen of death when 
> the user clicks the save button."  Nonetheless, I like what you have 
> below, regardless of whether it is a set of requirements or a vision 
> statement. 

Yes you are totally correct. But after I wrote it and realized it was
off topic, I still decided to send it ;-) Show no fear.


> While I like some of the things you are saying in point #5, I have 
> concerns about some of the wording.  For example, I thought the focus of 
> this project was writing an API for scrubbing user input, not creating "tools and design patterns to help me build a totally secure web 
> application".  No application is totally secure, or ever has been, or ever will be.
Sorry marketing speak. Some folks have actually accused me of being a
marketing person in the past. I still claim I'm an engineer, but every
once in a while things get flubbed up.

What I'm really trying to get at is that using our api should be easy,
but if designed well can also lead the developer to think about security
as part of the development process. Not really a goal of the project,
but I think a side benefit.

 
> If what you are suggesting is that the API be extensible, that sounds like 
> a good idea on the surface, except that it is in direct conflict with 
> "simple".  If we do not trust developers to use the API correctly unless 
> we make it simple, then what makes us think that they will extend the 
> framework without making it insecure in the process?

Ahhh... Yes, I am aware the flexibility/extendability is often in
conflict with simplicity. So I think two things are important. First, I
like to set high goals and get as close as possible. I'm sure some
amount of flexibility will be lost for simplicity and some amount of
simplicity will be lost for flexibility - but lets not give up at the
beginning. Lets shoot for something powerful. Also, if we take a layered
approach to developing this we may be able to set it up so that there is
a simple layer the most folks use and then a flexible layer that people
who need/want to enahnce or extend what we are doing can use as well.
Can we avoid the making it insecure in the process problem? I don't
know. But what if they can make it more secure by doing something? Do we
want to kill the ability to do that on the worry that someone will
bungle things? Good questions that I don't know the answer to. 

I'm going to keep saying this, but I think layers are the secret. Layers
that allow people to interact with what we are doing in different ways.
From totally plug and chug to well integrated and totally
interdependant...

It does sound like this one is a bone of contention and I am willing to
back off on the idea of flexibility/extendability for the first round at
least :-)

-gabe