Please forward to the list if it doesn't make it though (not subscribed
and can't admin : raised support ticket)
1. I would be tempted to say something like "could be implemented by all
major languages". If you design it generic enough its a porting issue,
if you support them all then its an overhead ;-) yeah cop out I know but
you may thank me for being that devil in the future ;-)
3. Maybe this should read extensible ?
Other ideas ;
Be easy for people to hand back extensions to the community
Be well documented
Over and out...
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
|
