You are not logged in Log in Join
You are here: Home » Members » jim » ZopeSecurity » ClientSideTrojan

Log in
Name

Password

 
 

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...]