From: Gabriel L. <ga...@bu...> - 2002-06-27 04:35:16
|
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 |
From: Alex R. <al...@se...> - 2002-06-27 15:00:27
|
Gabriel Lawrence wrote: > 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... > I'm in total agreement with points one and two, but the next one concerns me. > 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. So, to clarify this, are we saying that the toolkit itself should be flexible (allowing an arbitrarialy complex input syntax, etc) or are we specifying that it should be atomic enough to be used in flexible ways? I believe that the answer to this question lies a the heart at some of our current dissagreement. So what do you guys think? -- Alex Russell al...@Se... al...@ne... |
From: Gabriel L. <ga...@bu...> - 2002-06-27 18:44:15
|
On Thu, 2002-06-27 at 08:00, Alex Russell wrote: > So, to clarify this, are we saying that the toolkit itself should be > flexible (allowing an arbitrarialy complex input syntax, etc) or are we > specifying that it should be atomic enough to be used in flexible ways? > I believe that the answer to this question lies a the heart at some of > our current dissagreement. > > So what do you guys think? Uhhh, am I too demanding to say how 'bout both? Darn, now I really sound like a marketing guy ;-) -gabe |
From: Alex R. <al...@se...> - 2002-06-28 18:35:58
|
Gabriel Lawrence wrote: > Uhhh, am I too demanding to say how 'bout both? Darn, now I really sound > like a marketing guy ;-) I think that shooting for both is a poor idea for a first release because it will allow simply too many degrees of freedom, which we previously identified as a significant source of security failure. Building security software (espically when you are on the defense) is necessarialy _very_ different from building "regular" applications, and we need to modify our goals and evaluation criteria accordingly. -- Alex Russell al...@Se... al...@ne... |