History for ClientSideTrojan
??changed:
-
Client side trojan issue
Description
Imagine you have some kind of system that you administer through a
web GUI, such as HotMail, your Netscape Admin server or a site
like Zope.org. You get in to work and use this service for a while
(check your mail, manage your servers, whatever). For our example,
lets say you were using the netscape admin server.
Later in the day someone sends you an email asking you to look at
a web page. You go the page using the browser session where earlier
you had logged in to the admin server. However, the page does a
redirect to a url of your admin server that causes your main web
server to be deleted! The redirect will succeed, as you've already
logged in to the admin server earlier with sufficient privileges to
delete your server.
There are a few variations on this theme, involving JavaScript that
can silently submit a hidden form to do the same sort of thing. It
appears that most web applications involving authentication are
vulnerable to this sort of attack.
Web clients will cache your credentials and send them automatically
to a realm that you have visited earlier in the session, which in a
stateless system is a reasonable behavior. The problem is that the
client is also willing to let almost any page on the Web take actions
automatically on your behalf through the use of things like redirects
or javascript code.
An Example
Lets say I know that you run a web server that includes a through-
the-web management server on your site (such as NS Enterprise
Server). I can probably assume that you've used the default ports etc.
during installation.
If you've logged into the management server at some point during
the browser session and I can get you to view my HTML page during
that same session, then there is a very good chance that I can
force you to unwittingly delete your main web server installation
using a plain HTML form that submits itself (via javascript) as
soon as the document is loaded. That form is submitted to the
function of the management server that deletes the server.
Most browsers, when first installed, will pop up a dialog of some
sort warning you when you are submitting form information. Most
browsers also give you the option of selecting "never bother me with
this again" right on the dialog. How many reading this have turned
this off? A large number, I suspect (myself included). Because we
cannot be bothered with those silly dialogs, we will all be in the
same boat when our first clue that something is wrong will be
when we see the response from our management server (some variation
of "Congratulations! You have deleted your entire main web site
successfully!").
We have verified that this attack works with some real-world tests
involving NS enterprise server and some through-the-web mail services.
At this point, we highly suspect that almost any through-the-web
management system (including through-the-web management systems for
certain operating systems) is probably vulnerable to this sort of
trojan attack.
The amount of actual damage
that could be done and the difficulty of knowing enough about the
environment to pull off an attack vary depending on the service in
question, but at best that is security-by-obscurity. Note that CERT
has issued an advisory that touches on this in passing (noting the
possibility of using JavaScript or other scripting support to take
actions on the users behalf without him knowing it):
<a href="http://www.cert.org/advisories/CA-2000-02.html">
http://www.cert.org/advisories/CA-2000-02.html</a>.
Coming up with a workable technical solution to this is tricky - there
is nothing in the current Web infrastructure that deals with this
directly. Web clients and servers have a means of dealing with
authentication (are you really who you say you are?) and authorization
(the server says "no, you are not allowed to do that"), but they do
not have a way of verifying **intent** ("do you really mean to delete
your site, or has someone tricked you into this?").
Who is affected
Potentially any Web-accessible system is vulnerable to this type of
attack.
Operational measures
As noted below, we would very much like to come up with a solution
that either prevents or significantly reduces the risk of this type
of attack. This Wiki will serve as an ongoing discussion toward that
goal. In the meantime, managers of not only Zope sites but *any* Web-
managed system should should take some operational precautions to
reduce their risk.
o Do not view untrusted content in any browser session where you have
previously logged in to any web-based system with privileges that
could be abused.
o Turn off javascript! While it is not the only way, javascript is by
far the easiest way for an attacker to make a Web client take actions
on your behalf.
The stakes are high
There is a serious security problem here. Although it is not
Zope's *fault*, it is a *problem* that Zope should deal with.
Because one of the cornerstones of the Zope philosophy is the
ability to *safely* delegate responsibility, we don't feel that
relying on operational security alone is an adequate answer. Our
goal is to come up with a solution to prevent or significantly
mitigate the risk of such an attack against Zope sites.
Mitigation
First, there probably isn't a "solution" to this problem.
There are a variety of operational and technical strategies we can
investigate to mitigate the risks.
Mitigation 1, Curtail time logged in and activities
This is an operational mitigation technique.
**Never** view untrusted
content while logged in with privileges that could be abused and
**always** end your session with those privileges as soon as
your work is done.
Variations:
- Provide control over privileges so that users can lower
privileges and only raise them when necessary.
- Allow users to perform common and useful task as an
identified but unpriviledged user
Pros:
p1.1 -- Requires little or no software change.
p1.2 -- Works on non-Zope sites.
Issues
i1.1 -- By default, Zope doesn't provide a facility to log out,
other than re-booting your browser. :( This is true for any
system that relies on basic authentication.
i1.2 -- This is very hard for the user to manage, especially
web infrastucture. There aren't good ways to control
privilege. There are many degrees of priviledge and in many
applications, much useful functionality requires a level of
priviledge which can be exploited to do harm.
Mitigation 2, Undo
This is an operational mitigation technique.
Undo provides a certain level of protection.
Pros:
See p1.1.
p2.1 -- Provides a way to recover from damaging scripts
p2.2 -- Unique to Zope
Issues:
i2.1 -- Doesn't work if a site doesn't support or allow undo.
i2.2 -- Doesn't work with non-undoable transactions, such as
RDBMS transactions.
i2.3 -- Doesn't work if it involves objects that change often
(e.g. the catalog). This can and should be mitigated
by efforts to mitigate hot spots.
i2.4 -- Doesn't help with inherently non-undoable operations, like undo.
i2.5 -- It may not be possible for a user to know that they've been
hacked, so that may not know to undo.
Mitigation 3, minimal referer checks
For "unsafe" requests, the security machinery could attempt to get the
HTTP Referer header from the request and determine if it seems to
point to a local object. If not, the request will be denied.
An unsafe request is a request of a protected resource through a POST
request or a GET request with a query string.
If necessary for xml-rpc or soap, we might allow a request to omit
http referer if it has auth data in a form that would not be
automatically provided by the browser.
If the referer does appear to be a local object, we look at the local
[298 more lines...]