"ClientSideTrojan" bug

[kragen () POBOX COM (Kragen Sitaker)]

Apparently Zope and many other web-based systems suffer from a
confused-deputy problem: browsers are willing to visit URLs and submit
forms based on untrusted web page contents, and servers are willing to
trust browsers that submit forms and web page requests when they
include Basic Authentication or authentication cookies with those
requests.

The Zope page describing the problem is at
http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan.

This is sort of a variant of the "cross-site scripting" thing (CERT
Advisory CA-2000-02), in that it involves some of the same mistaken
trust relationships.  The browser trusts random servers to give it
URLs; the URLs tell the browser to go to other servers; the other
servers trust the browser.  In CA-2000-02, the browser then has some
trust relationship with the server, which doesn't figure here.

The Zope page doesn't include a lot of detail on how this could be
used, but I think there are essentially three cases:

a- server X sends you an evil form and JavaScript that automatically
   POSTs the form --- to server Y, which trusts your browser.
b- server X sends you a 30[12] Redirect or a Refresh that tells you to
   GET a page from server Y; GETting the page has some kind of evil side
   effect.
c- server Z, who might be totally innocent or might be server X, sends
   you an innocent-looking form that gets POSTed to server X.  Server X
   30[12] redirects to server Y; the innocent-looking form does
   something evil.
d- server Z sends you an innocent-looking, but evil, form that gets
   POSTed to server Y.

The solution to case (a) is simple; turn off JavaScript.  If you run a
web site that might be impacted by this, force your users to turn off
JavaScript; don't let them into the site in the first place if they
have it turned on.  This can be very simple --- a one-line onLoad
script on every page that redirects their browser to a page that
explains they must turn off JavaScript and why.

(Or it can be elaborate and annoying --- see
http://www.pobox.com/~kragen/annoy.html for an unfinished example.)

The solution to case (b) is just as simple; don't allow GET to have an
evil side effect, even if the user does have authorization.  This is
usually a good idea anyway.  GET requests should be idempotent, and
destructive operations usually aren't.  If there are GET requests that
can do evil, someone could just as easily link to them.

The solution to case (c) is already in place, and has been for years:
when following redirects on POSTs, the browser should use GET on the
resource it's redirected to, not POST.

The solution to case (d) is not clear to me.

The Zope page describes a number of mitigating measures:
- not viewing untrusted content when using a trusted browser (!)
- turning off JavaScript (of course)
- log out of sessions when you can (the Zope guys apparently don't know
  that sending a 403 response to a query will cause most browsers to
  ask for a username and password again; if you can persuade the user
  to refuse, the browser will generally have forgotten the username and
  password)
- Referer checks, which unfortunately don't work universally

It seems likely to me that the ultimate solution to problems like this
is capability-based security --- "if you can name it, you can do it".
This solves the problem by defining it away --- if someone knows an
evil URL, they can just as easily access it themselves as fool you into
doing it.

Unfortunately, today's web leaks resource names --- URLs --- like
sieves, and so it's impossible to safely use URLs as authenticators.
Specifically, proxies save URLs, so the proxy owners know them; httpd
logs save URLs, so everybody at your ISP knows them; and browsers send
URLs in Referer: headers, so everybody you link to knows them.

--
<kragen () pobox com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)