owasp-input-api-developers

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

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

[Nik C. <ni...@ni...>]

On Tue, 2 Apr 2002, Christopher Todd wrote:

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

Hi Chris,

In terms of 'helping people write more secure web applications', I think
that is the main aim of OWASP, and the filters project is one part of the
overall goal.

But, a large portion of web application developers are oblivious to the
risks that web applications pose. While it is hoped that OWASP will raise
awarness in the field, it still leaves a lot of potentially insecure sites
out there, with lazy (or unknowing) developers unwilling to implement a
filtering API (besides, there are already simple methods native to each
language to test/sanatize user input). Developers are often under time
constraints, or have many other reasons to overlook security whilst
developing a web application (pick up a book on web app development and
note how much of it is devoted to security issues).

This obviously leaves a large 'market' for server (ie. pre
web-application) filtering and intrusion detection, which is where i see a
small split within this project and two trajectories.

1. Filtering API's for developers
2. Webserver/scripting engine patches or modules for webmaster's and
server administrators.

Combined, they are obviously a powerful combination (combined with
application level intrusion detection that could be integrated within a
webserver filtering tool). Developers can take responsobility for
implementing the filtering API, and/or server administrator(s) can take
responsability for web server based filtering (these roles can often be
split widely, ie. in an outsorcing situation).

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

yes, this would be simple to implement across PHP, ASP, Perl and Java.
Should we start developing a function framework and specification for
each of functions?

Perhaps a good starting point would be to firstly identify all threats
(cross site scripting, SQL injection), and then come up with relative
functions to sanatize. This will still not solve a lot of common problems
in web applications.. how many times have you seen something like:

http://www.server.com/store/account_info.php?id=12

then being able to increment id to pick up somebody else's account? I
guess this is outside of the scope of this project. There are also other
vulnerabilities such as script?include=/etc/passwd trickiness (see:
http://www.securereality.com.au/studyinscarlet.txt) that can not be easily
solved, since if the developer has not accounted for the possibility of
that variable being passed to the script, then how can they defend against
it?

An ideal option would be for the developer to explicitly allow certain
variables to a page, and all other user passed variables to be cropped
out/ignored by the web application (hard to implement in php, easy in
ASP), and then the variables that have been explicitly allowed to progress
into the web application, for the filters to be applied.

perhaps i am getting ahead of myself.

> Implementing web server plugins obviously is a much more complicated task.
> <snip>
> 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.
>

Yes, web server plugins would be something more likely to fit into 'the
big picture' at a later date, they would have to be written in C and be
very specific to the target webserver (Apache1/Apache2/IIS).


enough ranting :)

Nik Cubrilovic
www.nik.com.au