[Zope-dev] Addressing client-side trojan problem

[Ken Manheimer]

Shane Hathaway <shane@zope.com> wrote:

> sean.upton@uniontrib.com wrote:
>
> > Personally, I think this really should be an integration issue instead of a
> > Zope issue: use a front-end proxy server (i.e. Squid) and set up ACLs to
> > prevent this...
>
>
> This hasn't been fixed because it's not well understood.  Javascript can
> POST an invisible form, AFAIK.  The problem occurs on the browsers of
> users who are *already authenticated*.  It has nothing to do with Zope
> or any server software, really.

I recently saw a _very_ interesting description of how capability-based
distributed computing (and the Principle of Least Authority) is used to
address vulnerabilities to client side trojans, viruses, etc.  I think the
approach may apply to the web situation.

"Capabilities" are a signficant, fairly established idea in the realm of
distributed operating systems, but are not very familiar more generally.
This description is by far the most approachable i've seen (and perhaps,
the first i've understood:) - i highly recommend looking it over.  It's
in a substantial overview of the very nifty looking scripting language, E,
which is specifically designed to provide secure, reliable, manageable
distributed computing scripting.  The relevant bits are at:

  http://www.skyhunter.com/marcs/ewalnut.html#SEC41

A page or two down it describes the ramifications for things like computer
viruses, if you want to skip straight to the punch.  That part doesn't
quite capture the way i expect we would use it to address the client-side
trojan problem.  Offhand, i suspect we could use these principles with
Zope cookies and capability-specific roles.  This approach provides a
means for implementing something along the lines that chris petrilli was
suggesting a while back, with incremental, rather than either/or, role
privileges.

Ken
klm@zope.com