[Zope] protecting users from hostile authors

Thomas B. Passin tpassin@mitretek.org
Mon, 27 Aug 2001 10:08:27 -0400


One other possibility is to restrict the authors' permissions to their
original logon domain.  You can do this by hand in the ZMI, so presumably
you could do it programatically.  Then the spoofer would be coming in from
the wrong domain, and would not be allowed permissions.

This would keep the author from logging in when he was travelling, but it
would otherwise seem pretty useful (unless the spoofer were in the same
domain, but you could restrict it down to the individual IP address).

Cheeers,

Tom P

[Dieter Maurer]

> Kyler B. Laird writes:
>  > O.k., I appreciate that (lots!).  However, I do not see
>  > what is stopping me from doing something nasty like...
>  >
>  > 1. Lure you to my page.
>  >
>  > 2. Check to see that you are authenticated.
>  > (My page wouldn't require it.)
>  >
>  > 3. If you are, grab your user name.
>  >
>  > 4. Create a URL for a Bad Thing (something with
>  > "manage_" in it pointed at your folder).
>  >
>  > 5. Generate a 1x1 (or whatever) <img> tag with
>  > that URL as the src value.
>  >
>  > I haven't tried this, but even if it does not work now,
>  > I wonder what policy prevents it (and insures it will
>  > not work in future versions).
> I fear, there is nothing that prevents it....
>
>   You need so little for this attack: only the name of the current
>   user (and some external knowledge what a normal user may do
>   to his own content and what his own content is).
>
> With Netscape 4.x, you would at least see a broken image,
> which may lead to the identification of the bad guy and
> allow to deal with him by non-technical, e.g. legal, means.
> It seems to me, that IE simply ignores broken images, though.
>
> Fortunately, Zope has "undo" support. Thus, at least in principle,
> there is a chance to undo the bad effect, provided the damage
> is recognized early enough...
>
>  > When I think of how to prevent this, use of the
>  > "Referer" header jumps out, but I don't send it from
>  > some of my browsers.
> Not so easy. Because, I often may want to call "manage_XXX"
> from somewhere different from "manage_XXXForm"....
>
>  > Other possibilities include use
>  > of cookies, but I don't even like the current
>  > dependency on them.
> Would it help?
>
> You would attack only when the necessary cookie is there.
>
>  > Any clever thoughts?
> Attack this problem by non-technical means.
>
> They are your authors, aren't they?