[Zope] protecting users from hostile authors

[Oliver Bleutgen]

> 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