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

[<Chr...@ey...>]

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.

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

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

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

A good idea, and also fairly easy to implement in servlets (particularly 
in the 2.3 spec - the javax.servlet.Filter class is designed to do exactly 
that sort of thing).

This approach could also be implemented in the webserver plugin approach, 
where a sysadmin defines the HTTP headers and form fields that will be 
accepted for a given resource (that is, a servlet/JSP/PHP/Perl 
script/page).  I have seen webapps where the developer simply loops 
through all the form fields in the HTTP request, and prints them to the 
page.  The developer may only be expecting the fields "name" and 
"address", but then a hacker can easily construct a POST request that also 
includes something sneaky like "password=Runtime.exec("cat /etc/passwd")".

<snip/>

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

Furthermore, if we create plugins for Apache and IIS, we have just nailed 
87.56% of the web server market (according to the most recent Netcraft 
survey).  That's pretty good coverage.

I'm not being dogmatic about any of this...the Input Filters API project 
will be a valuable contribution to the community whether it produces an 
API, a set of webserver plugins, or both.

Sincerest regards,
Chris Todd
Ernst & Young LLP
Security and Technology Solutions (STS)
chr...@ey...The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  Ernst & Young LLP