Since February I've been railing on about the importance of protecting your Zope installations and their Products with rewrite rules and URI filters. Well, unfortunately I was overlooking something rather obvious--Zope's built in magical type coercion gets around most URI matches entirely. The rewrite rules I've suggested in the past aren't enough. If this style of filtering is to be continued it must be augmented with filters that are capable of examining the request resource, the query parameters, and basically anything that can externally control Zope's traversal stack. Couple of brief examples; whereas before you may have desired to filter access to the HelpSys mechanism (a notorious leak of information[1] about what products your zope service has installed as well as a potential vector for other badness) by doing something like RewriteCond %{REQUEST_URI} /(Control_Panel|HelpSys)(/|$) RewriteRule .* - [F] in your Apache configuration, now I realize its not enough. Getting around that restriction is as easy as http://examplehost/?HelpSys:method= The type coercion hooks, :method, :action, :default_method, etc. evidently alter the traversal stack. Even stuff like http://examplehost/?_vh_foo:method= will work, bypassing the URI filters I've been extolling[2] for protecting Virtual Host Monsters. Dylan had good reason to voice suspicion about type coercion back in March[3], but the issue was skirted and ended up focusing on tainting application data (which, of course, is also important). 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. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz [1] http://marc.theaimsgroup.com/?l=zope-dev&m=103893600209090&w=2 [2] http://marc.theaimsgroup.com/?l=zope&m=104426779414836&w=2 [3] http://marc.theaimsgroup.com/?l=zope&m=104718222616059&w=2 [4] http://collector.zope.org/Zope/813 I should point out the VHM workarounds for bug 813 I mentioned are made moot by this latest realization, the only sane thing to do now is to patch, patch, and patch some more.