[OWASP-LEADERS] Filters / dyn vs. static

Ingo Struck ingo at ingostruck.de
Fri Nov 8 12:20:21 EST 2002


Hi...

Regarding the dynamic vs. static stuff, I have made very good experiences with 
the following setup (which is already in use by the vulnxml app):

httpd listens on 80 and spits out any static resource directly (images, pdf, 
static html and the like). It may listen on 443 for ssl'ed dynamic resources.
Since static resources do not rely on any input parameters,
that should be no problem, even with "malicious" input.
My httpd is configured such that it can do absolutely nothing but:
  - serving static resources
  - rewriting some urls
  - proxying to the app server (tomcat in this case)
All apache dyn is turned off (cgi, dav and other crap).
Httpd sets a location match that allows access to the dynamic content
from localhost only.
All incoming requests that have a valid path are rewritten and proxied
to the app-server (usually via 8080). All other pathes will be rejected (404). 
The app server in turn only allows access from localhost, i.e. through the
httpd proxy module (I still have to work out how to tell tomcat to do so).

If the FWs are well-done, I see absolutely no problem to run httpd and webapp 
server on one machine. The db should have a dedicated server anyway that
is only accessible via intranet. So IMHO the two-machine setup will be 
perfectly alright for the start (only if we encounter performance problems 
some day we have to scale up then).

To answer David's filter question, here's my proposal:

> 1.  Dynamic Content:
> REQUEST:  HTTP(CLIENT) -> FILTER(FILTERS PROJECT) -> WEB SERVER ->
> JK2(TOMCAT) -> FILTER(SERVLET API) -> SERVLET
I don't see why we should include two different filter stages.
The filtering should be powerful enough to perform any needed filtering on one 
stage. The only thing that has to be protected against malicious requests is 
the web server. Most of the necessary filtering can be done by httpd itself.
Anything that passes through to the webserver should be in a form that does no 
harm to the app server.

> RESPONSE: SERVLET -> FILTER(SERVLET API) -> JK2(TOMCAT) -> WEB SERVER ->
> HTTP(CLIENT)
There is absolutely no need to filter the response, since our servlets will 
not produce malicious responses.

> 2.  Static Content:
> REQUEST:  HTTP(CLIENT) -> FILTER(FILTERS PROJECT) -> WEB SERVER
>
> RESPONSE: WEB SERVER -> HTTP(CLIENT)
As for static resources we only have to cut any parameter. The web server 
should be able to ignore any malformed http request. Cutting all parameters 
from static resources can be performed by a single rewrite rule.

> Are we comfortable with Apache 2 being the most secure?  I am not a
> Linux security specialist, but I don't believe that Apache 2 has had
> the same exposure as 1.3.xx ...What does everybody think?
Regarding the httpd version I have no preferences, I only think that 2 could 
be better optimized for high performance. 

I will add the vulnxml CVS module in an hour or something such that you can 
have a look at the configuration I use for the vulnxml db app.

Kind regards

Ingo







More information about the OWASP-Leaders mailing list