Jamie Heilman wrote:
Since February I've been railing on about the importance of protecting your Zope installations and their Products with rewrite rules and URI filters.
And let me thank you for that, IMO you do a very important service for the zope community. Unfortunately it seems that unless there is a major flaw found, there's not much interest in this kind of security analysis.
[snip]
So where do we go from here? Its becoming evident to me that while I can probably finagle a rewrite rule that looks for certain tainted names in the GET and POST query variables, Zope has more avenues of control than your typical web application. There's still things like WebDAV, XML-RPC, etc. to worry about, any of which may contain additional hooks which allow frobbing the traversal stack. Writing filters for all those is going to be seriously trying.
I'll postulate that the path of least resistance is simply giving up any hope of filtering requests for sanity, and instead focusing on replacing the problem Products and establishing new, secure, paths of configuration. HelpSys should not allow non-authenticated access. VirtualHostMonsters should not obtain their rewriting information from the traversal stack, indeed the traversal stack should not be viewed as a source of trusted information, much like the the request URIs can't be viewed as trusted[4]. ... and so on. This should be fun.
At least with VHM, I think the solution is straightforward. Abandon the path for forwarding information to zope, and use custom http-headers instead. VHM then would delete these headers on traversal (to hide that information from not-so-trusted code inside zope). This solution would not only be more secure, it would also simplify the VHM code alot, and it would certainly be faster. cheers, oliver