Re: [Owasp-input-api-developers] Re: goal and direction

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

On Wed, 3 Apr 2002 Chr...@ey... wrote:

> Nik,
>
> >But, a large portion of web application developers are oblivious to the
> >risks that web applications pose.
> <snip/>
> >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.
>
> Right.  The point I was making is that both approaches are reasonable; I
> merely wanted to prod the list into discussing which approach this project
> should take, or whether both approaches should be pursued.

My opinion would be to focus on the API for developers first, since it is
easier to implement and the main aim of the project. Am i right in saying
that the API will be targetting ASP/PHP/Perl/Java?

> I think that would be an excellent starting point, using the ASAC material
> (and other suitable materials) as a guide.

Want to start by pasting some references? I am not sure how many people we
have on this list at the moment (ie. are all developers here) and if
Nathan wants to get the ball rolling.

> >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).
>
> Perhaps I am confused about some implementation details.  If we are going
> to create Filters that sit in front of web applications, and which
> intercept all HTTP requests before they ever reach the web app, how would
> we do that if not in something like an Apache module or IIS ISAPI module?

As a front end proxy even before the web server.

==> [proxy] ==> [webserver] ==> [application]

there might obviously be SSL problems, and the webserver would see all
request's coming in from the proxy (which would mess up ACL's). There is
no reason why the 'proxy' cant be on the same machine as the webserver
(webserver listening on localhost, proxy forwards requests). A model for
the proxy might be (again, not much to do with filter's API, just
discussion) as follows, request coming in from the top and passing
through.

[REQUEST]
[FILTER USER INPUT]
[BLOCK BAD INPUT]
[LOG BAD INPUT/IDS]
[CHECK SANITY OF HEADERS (NORMALISE)]
[FORWARD REQUEST TO WEBSERVER]

And then back from the webserver to the client

[FILTER DB ERROR MESSAGES]	- prevent 'information leakage'
[FILTER UNEXPECTED SCRIPT (PAYLOADS)]

I would not be suprised if there are existing implementations of this
(cant recall any).

Regards,

-Nik