Sorry everyone, but it would appear that I sent the email below to
owa...@li... instead of the main
list. Sorry for any confusion that may have caused.
Sincerest Regards,
Chris Todd
Ernst & Young LLP
Security and Technology Solutions (STS)
chr...@ey...
May I assume from the description of this project on the webpage, and from
this thread, that the goal of the project is to provide, in essence, web
server plugins that filter data before they ever hit the web applications?
That's a pretty cool idea, I have to admit.
However, when I first heard the description of this project, I imagined
that the product would be a set of APIs that developers could use in their
applications to scrub user input. Essentially, method or function calls
that would take a String of user input, and return the sanitized String.
(This is radically simplified, of course, but I think you get the idea)
The distinction between these approaches, to borrow a phrase from J2EE, is
that the former is "Declarative Security", whereas the latter is
"Programmatic Security". Obviously, there is a place for both approaches
in the world of web application security, and each approach has its
advantages and disadvantages. For example, many large corporations are
not going to want to modify their production webservers, particularly
given the problems with CodeRed et al. Conversely, in organizations that
have security-knowledge systems administrators (not too uncommon), but
security-ignorant web developers (unfortunately, way too common), the web
server plugin is an excellent solution.
I was wondering if you all thought there is room in this project for, in
essence, two products - a web/app server plugin, and a programming API? Of
course, the web server plugins themselves can and probably will use the
input-scrubbing API, so it's not like the two products will be completely
disassociated.
Regards,
Chris Todd
Ernst & Young LLP
Security and Technology Solutions (STS)
chr...@ey...
|
