O.k., I've been mulling over the topic of protecting users from lots of potentially hostile authors. I've got some ideas that could go a little way toward solving the problem.
When writing a method that is going to do something *really* privileged (like "drop class"), there should be a second "Are you sure you want to...?" step.
In order to enforce the desired use of this step, there must be a way to determine that the method is being called directly from the Zope Publisher(???) - not through an intermediate method. I have worked with such problems extensively under Apache, and the most secure solution I developed was not pretty. I'm hoping for better in Zope.
This is IMO equivalent to the problem of determining if the manage_-method has been called by "legitimate" means, i.e. creating some kind of state - otherwise the attacker would just target the same methods as the "are you sure?" screen you propose. Btw. I wouldn't want to be asked for everything I do in the ZMI - and everything you can do there is potentially dangerous.
Is there a good un-fakeable way in Zope to determine the caller of a method?
I fear that's impossible when we look at what happens. (1)Hostile html-page -> (2)client -> (3)manage_method Between (1) and (3) there's always the client and looking at modern browsers I find it very unlikely that we can always trust (2).
(Another piece that is required for the "extra step" solution I mention is the generation of some cryptographic key to the second step. I think I understand how to do that.)
If you know how to solve that, you can also stuff that key directly into the ZMI as we have them now, can't you? OTH, looking at techniques discussed here recently, like IIRC http://www.ashleyit.com/rs/ we see there are various possibilites to GET/POST pages on the users behalf in order to get at your cryptographic key.
Some other things to consider...if you have a "Referer" header, you could use it to insure that the user got to your method through the "proper" path. Using the "Accept" header *should* give a clue if the request is coming as a result of a tag like "img". These are not dependable solutions, though. Some browsers do not send the Referer, and MS browsers have a long history of sending bogus Accept values. Also, frames could be used instead of images for "invisible" calls.
I see no chance to defeat an attack against a browser which is to "open" w.r.t. scripting. But, without javascript, there's IMO an easy and compatible way to defeat almost any attack. I posted this also to the wicki, just make sure that possibly destructive methods can only be called from the web via POST. The http/1.1 rfc says about that: 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. cheers, oliver