On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Tue, May 01, 2007 at 08:02:01PM -0400, The Editor wrote: > > I suggested one possible (probably easy) fix off-list that could > > provide that back door. Allowing a simple string replacement array to > > be processed before doing markup processing on an imposed page. > > I'm not sure exactly what you mean by "imposed page", but > it sounds as though you mean "any page where the markup is > coming from somewhere other than the current one." If that's > correct, then essentially you're saying that recipes should be > able to disable certain markups if they're coming from an > included page or section, a pagelist template, GroupHeader, > GroupFooter, page text variable, SideBar, or any other feature > where we're doing any sort of "templating".
I'm not even talking about disabling markup. Only a way to run some kind of escape function. Like define a configurable str_replace (zap, zaap) or whatever that is run just before the markup--perhaps only when a user doesn't have write permission to the page that markup is imposed on. This would not have any effect except when deliberately used by a recipe author, and there, it would be used specifically to block just these kind of attacks. > I think that many admins and authors would find such limitations > to also be confusing and overly constraining -- i.e., I can't > generate a page containing a ZAP form and then just (:include:) > it on multiple other pages? Or certain directives aren't > allowed to be used in pagelist templates? Or I can't use > form processing directives in a SideBar? It would only be implemented by a recipe author if needed. I'm just saying there should be a mechanism for this available for people wanting to do anything like this (any kind of forms processing in PmWiki is vulnerable to this). And of course I'm not saying these other features cannot be used. It's just PmWiki should offer at least some kind mechanism to block these kinds of malicious attacks! Currently it's about impossible... > So, while this might be a fix, I think it comes with its own > set of negative issues and confusion for authors/admins that > are probably best avoided. How would that be a problem when nothing is changed by default. You're just providing an opportunity for admins to escape certain markup to preven this kind of exploit. Nothing else would change... > All of this is just a way of saying that I think we need > a different overall solution to the problem here -- i.e., > being able to bypass edit to write to *any* page is too > blunt an instrument for what we're trying to achieve. I'm open to whatever suggestion you have, but you haven't been very forthcoming with recommendations . ZAP has many useful features and PmWiki should make it possible for something like it to be available. It seems your current position is, there's no way to do what you want--so forget about it. I'll be happy to pull the recipe--there are other engines it might work more safely with (Personally I use it on edit protected sites for all user interaction so it's not a problem for me). But I think finding a solution for PmWiki users is the better approach. In short, as far as I can see, since wiki markup can be imposed on page authors don't have edit permissions with 1) no way to escape it, 2) no way to flag it, 3) not even a POST or GET value to indicate it's imposed (these seem to somehow be cleared by PmWiki), unless PmWiki makes some kind of core change to allow recipe authors to block these kinds of attacks, it's impossible. Apart from manually having to set target pages in config files for evey single ZAP form. But Pm that's unacceptable. Looking forward to your suggestions... Cheers, Dan _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
