The server-side issue appears to be pretty Zope-specific. From the description on Zope.org:
Under the current Zope security model, a DTMLMethod author can create a method containing code that attempts to
perform actions above the author's level of privilege. If the author attempts to run this method, he will get an error
because he is not sufficiently privileged to perform the actions. However, if the author can arrange for a more privileged
user to view his content, the code will run, possibly performing actions without the higher-privileged user even knowing
about it. This hole results from the fact that DTMLMethods execute with the privileges of the user executing the
They state that the issue will be fixed in Zope 2.2, by creating an ownership scheme for server-side objects.
The client-side issue is much more far-reaching and potentially damaging. At the risk of making myself look dumb, I'll give an example of the problem using Scoop itself.
Imagine that there is a form button to delete a story, and when an administrator presses it, the resultant URL, expressed as a GET, looks like:
(not the actual form string, but something like that). Now, whether or not I have permission to perform that action is determined by my local session cookie. If my browser provides a session cookie, and that session is found to contain, in the database, a UID, and that UID is granted a certain level of privilege, then the action goes through without further prompting.
"So what's the problem?" you ask, "Surely an admin wouldn't click on such a link without knowing what he was going to do!"
But that's not the end. Now imagine that someone creates a page consisting of the following HTML:
and emails me the link to this page, with a description such as "Please consider this article for posting to kuro5hin.org". I click the link to see the page. Uh-oh.
As we've seen, I have the admin cookie stored on locally, so they have just tricked me into sending the destructive URL to my server, along with full admin privileges. There won't be any warning that I'm about to do this, and I won't know until it's too late.
The example covers Scoop, but the problem extends to almost all web-administered applications. Very few have any kind of checks in place to prevent this kind of problem. Ways to fix it, as listed on the Zope site, include curtailing logged-in time, providing "Undo" capabilities, or performing referrer checks before performing certain actions. Developers of web-administered applications, and admins of such applications need to take note of this problem immediately, and be very careful what they do while logged in as an admin. Fixes will likely be slightly slower in coming than for most problems, due to the subtle nature of the issue. Until then, admins, stay logged out until you have to do something administrative!