goal and direction WAS: RE: [Owasp-input-api-developers] Status?

[Christopher T. <ch...@ch...>]

Steve,

Well, I guess that would be a reasonable question for debate.  Are we trying
to help people write more secure web applications, or are we trying to help
make web applications more secure?  There is a subtle difference that gets
back to the difference between declarative vs. programmatic security.  From
one perspective, it doesn't matter which approach you take, so long as the
result is a more secure web application.  And as mentioned in my previous
post, there are advantages and disadvantages to each approach.

For the purposes of the Input Filters API project, it seems obvious that
implementing an API for each language will be the easiest and quickest way
to produce something useful to the community, so long as we can agree on an
interface that will be common across all the languages (or at least as
common as the syntaxes of the languages will allow).  For example, once
we've decided that the methods

public String removeParentheses(String input)
public String removeSemicolons(String input)
public String sanitizeInput(String input, Regex exclusionPattern)

(to put up a few hypothetical examples in Java syntax) are methods we need
in the API, then it is up to the individual language implementors to figure
out how to implement them.  That can be done pretty quickly.

Implementing web server plugins obviously is a much more complicated task.
However, I would point out that the beautiful thing about a webserver plugin
is that it intercepts HTTP requests before the webapp engine sees them, and
the webapp engine is none the wiser - it just knows that it has received an
HTTP request, along with headers and maybe GET or POST data, that it needs
to process.  If those headers or that GET or POST data has already been
sanitized by a webserver plugin, what does the webapp engine care?  Unless,
of course, the sanitizing process completely mangles the user input... :-)
(Potential gotcha there - need to figure out how to handle that).

I would point out that for servlet containers that are compliant with the
Servlet 2.3 spec, the new javax.servlet.Filter interface is a perfect
mechanism for implementing a servlet container-independent "plugin" that can
be used declaratively.  In the 2.3 spec, a Filter is configured to intercept
HTTP requests destined for servlets, JSPs, or even static HTML content, and
can take any of a number of actions, including modifying the original
request, redirecting the request to a different destination, etc.  When the
filter is done with its work, it passes the ServletRequest and
ServletResponse objects on to the next Filter in the filter chain (more than
one Filter can protect a given resource, and a given Filter can protect
several resources), or if it is the last Filter in the chain, it passes them
on to the target servlet or JSP.  Sorry for the ramble, but I'm a servlet
geek, and I've been thinking about how to use the new Filter interface to
provide authentication checks for a webapp I'm currently building.  :-)

So to summarize, basically I agree with you, but in the long term, I think
we should at least consider the potential usefulness of creating web server
plugins.

Regards,
Chris

-----Original Message-----
From: Steven J. Sobol [mailto:sj...@Ju...]
Sent: Tuesday, April 02, 2002 9:48 PM
To: Christopher Todd
Cc: owa...@li...
Subject: RE: [Owasp-input-api-developers] Status?


On Tue, 2 Apr 2002, Christopher Todd wrote:

> Has there been any discussion of writing an Apache module (for the
webserver
> plugin approach)?  That would cover a lot of web app engine ground,
> including PHP, PERL, ChiliASP, and even Java (with JServ/Tomcat apache
> plugins).

I'm not sure how we'd manage that. With a $LANGUAGE plugin or module you
can use $LANGUAGE-specific functions to manipulate data. With an Apache
API/NSAPI/ISAPI server module you'd have to do everything before the
scripting engine - whether it be PHP, JSP, ASP or anything else - would
have a chance to touch the data, and it would allow MUCH less flexibility.
My vision for this project is that we want to empower people to write more
secure web applications. I don't think a server module is the best way to
do that. I know it'll be more work, but my opinion is that the best thing
to do is to create modules for the most popular scripting platforms.

Just my $0.02...

--
Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek)
JustThe.net LLC, Mentor On The Lake, OH  888.480.4NET   http://JustThe.net
Need a programmer? Resume going up at
http://sourceforge.net/users/webdude216