[OWASP-LEADERS] Filters / dyn vs. static

David Raphael david.raphael at ceterum.net
Sun Nov 10 00:51:35 EST 2002


I am definitely not proposing two filter stages.  However, there are 
times when we
want to use the Servlet Filter API, but we don't want to use it for 
security.  We can
use this API to transform output - i.e. If we want to spit out PDF or 
EXCEL format,
we can create the transforms without any coding.  Similar to 
xml.apache.org Cocoon.

I am still working on my design documentation.  I am sorry they are not 
ready.  I
am pressing as hard as I can to finish them.

thanks for the clarification on this one :)

Q for Ingo:  What is the reason to combine HTTPD (apache) and AS 
(tomcat)?  And
have the DB standalone? Why not vice versa?

Cheers,
Dave

On Friday, November 8, 2002, at 11:20 AM, Ingo Struck wrote:

> 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
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Owasp-leaders mailing list
> Owasp-leaders at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-leaders
>
>





More information about the OWASP-Leaders mailing list