Internet DRAFT - draft-caldwell-tbsa

draft-caldwell-tbsa



INTERNET-DRAFT                                                      S. Caldwell
draft-caldwell-tbsa-00.txt                                       Firelytics.com
Category: Informational                                          10 August 2010
Expires: February 10, 2010

                 Trusted Browser Security Architecture (TBSA)

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 3, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

    This document proposes a trusted browser security model intended to
    secure the mutual automated consent between the end-user and the
    content provider before allowing a web browser to engage the
    services of an arbitrary third-party add-on, extension or service.
    Properly implemented, this proposed security model would create a
    standardized API across all browsers to further the security of
    e-commerce and other on-line transactions.


1. Introduction

    As the world moves away from the traditional desktop computer and becomes
    more dependent upon web applications, it is critical that the web browser
    through which these applications may be accessed provide robust security
    mechanisms which will protect sensitive data and systems from malicious
    parties [See Wadlow and Gorelik].  Currently there exists a considerable 
    body of work (such as the standards describing SSL/TLS) for client and 
    server authentication as well as the encryption of traffic between client 
    and server.  However, there exists no similar standards for securing 
    information prior to its encryption by the SSL/TLS mechanisms.  The 
    following pages demonstrate the problems and proposed solution, which if 
    standardized will allow end users and network administrators to establish
    browser security levels, and further will allow web application 
    administrators and developers to implement server-side security levels.  
    Accordingly, during web application operations, under this proposed model, 
    the browser and web server would be forced to first agree that the two agree
    on a mutually acceptable security level before the web application is 
    allowed to function.  This framework is called "Trusted Browser Security
    Architecture" (TBSA).

2. The Problem, Defined

            -------------------------------------------------------------------
                                AUTHOR'S NOTE:
            -------------------------------------------------------------------
            The problem described in the following section is a well-known
            attack and vulnerability that has existed for many years.  The
            public discussion of this issue is therefore considered to be of
            very little value to the computer criminal community.  It is the
            opinion of the author that the following public discussion of the
            issue is the best and only recourse to ensure the problem is 
            resolved once and for all, as years of silence has not been a source
            of solutions.
            -------------------------------------------------------------------

    For purposes of illustration, the author will describe a scenario using
    the Google Chrome web browser (5.0.375.99 beta).  However the problem
    described can be reproduced on all major web browsers, including
    Internet Explorer, Mozilla Firefox, and Apple Safari.  Additionally
    the problem is demonstrated through a simple manual operation.  For
    ethical and legal reasons, the code for a full exploit is not made
    public in this document, as the author does not wish to assist malicious
    parties by providing a "how-to" guide for criminal conduct.

    2.a. Browser Keylogging Demonstration

        Assume there exists a web application whose login screen is rendered
        as depicted below in HTML:

            <html>
                <head>
                    <title>Target Site</title>
                </head>
                <body>
                    <div>
                        <form>
                            Username:<input id="username" type="text" />
                            <br />
                            Password:<input id="password" type="password" />
                            <br />
                            <input id="submit" value="submit" type="submit" />
                        </form>
                    </div>
                </body>
            </html>

        The site administrator considers the site to be sensitive and
        desires the strongest possible security.  The web browser requires
        TLS with client authentication, and a client-side certificate has
        been installed on the end-user's computer.  This ensures that only
        the end-user's computer can connect to the web server for the web
        application and that all communications between client and server
        are encrypted.

        The end user installs a browser extension for use with another site's
        content, and as required by that site, the end-user enables JavaScript.
        The extension, however, has been compromised and unknown to the
        end-user begins logging the end-user's browser key strokes.  The next
        time the end-user accesses the secured 'target' site, the extension
        covertly obtains the user's credentials.  While TLS would prevent the
        attacker from accessing the secured site from a remote system, the
        attacker is able to obtain credentials which can then be used to
        access the secured target site through the end-user's system via
        some arbitrary code injected through the trojan browser extension.

                                        Process

            1. Open the Google Chrome web browser.
            2. Navigate to some web page (see example HTML page provided above).
            3. When page loads, right click page and select "Inspect Element"
            4. Click "console" in the toolbar.
            5. Within the console window, paste the following code:
    
                    var o=document.getElementById('password');
                    o.onkeypress=function(e){console.log(e);}
    
            6. Press <ENTER>.
            7. Return to the form on the target page and select the password
               field.
            8. Begin typing while observing the console window.  All keystrokes
               should appear as captured ASCII codes in the console.
    
        The above scenario demonstrates a simple key logger possible through 
        most browsers.  This exploit can be enhanced to use AJAX where the 
        attacker will submit the keystrokes captured during operation to a 
        remote web server.  While manual operation requires physical or remote
        access to the system to inject the code in an open browser prior to the
        user's interaction with a pre-loaded web-page, this exploit can be 
        extended through the use of add-on or extension software used with many
        web browsers.
    
    2.b. Discussion

        Given the absence of a security mechanism preventing malicious activity
        by browser add-ons or extensions, and given the lack of code signing or
        other strategies to ensure that any previously trusted browser add-on or
        extension software has not been tainted by malicious code, it is 
        possible for an attacker to first introduce malicious code into an 
        existing browser add-on or extension or to introduce a Trojan add-on/
        extension from which the attack can occur.

        Under the Trojan add-on/extension theory, the author constructed a 
        simple browser extension for Mozilla Firefox.  This extension was 
        intended to synchronize passwords between a user's many distributed 
        computers, providing a centralized mechanism for password storage (i.e. 
        the author's own web server).  This test-scenario resulted in an
        extension crafted to secure the end-user's consent to capture and store
        user names and passwords, possibly blurring the lines of legality if put
        into actual practice.  The author then conducted testing of this 
        extension using his own personal accounts on many popular websites, 
        demonstrating the ability of a browser extension to inject the above key
        logging code into the target pages and to capture keystrokes.  While the
        code injected by the test extension was much more complex than the above
        demonstration, it painted a picture that defeats any SSL/TLS or
        operating system level security measures and makes the SAAS model of web
        applications a foolhardy effort without further mechanisms within the 
        web browser.

3. Trusted Browser Security Architecture (TBSA)

    Simply blocking any and all browser add-ons and extensions is not a valid
    long-term solution to this problem.  Extensions and add-ons include
    Adobe's Reader and Flash Player as well as other media players and even
    those open source gizmos end-users find indispensable.  While blocking
    extensions and add-ons is feasible in the corporate environment, where
    IT policy can over-ride end-user demand, in the home and small business
    arena, this option simply does not exist.  Often through a lack of
    technical education or complacency, systems are left vulnerable and site
    developers for banking and other institutions are left without a valid
    recourse.

    One strategy, proposed by Adam Barth, Adrienne Porter Felt, Prateek Saxena
    and Aron Boodman in "Protecting Browsers from Extension Vulnerabilities"
    (University of California at Berkley Technical Report No. UCB/EECS-2009-185)
    suggests a stronger browser security strategy that restricts the privileges
    of a browser extension, isolates extensions, separates privileges and
    otherwise increases the security of extensions in general.  However, such
    strategies does nothing to allow the legitimate content-provider to be
    aware of or to consent to an otherwise user-approved extension running with
    his or her web application.  Thus, where an end-user may for whatever
    reason believe his or her choice of browser extensions is 'safe,' or where
    the user may intentionally choose an extension in order to reverse
    engineer a web application, the site operator has absolutely no control
    to protect his or her intellectual property or the other users who rely
    upon this system.
    
    The above issue can be resolved by implementing an API at the browser
    which is accessible from client-side programming languages, such as 
    JavaScript, vbScript, etc.  This API would allow a TBSA-aware web 
    application to identify and negotiate the security level of the client-
    server relationship before delivering privileged content.  Part of this
    strategy would also involve a browser integrity check, completing the
    integration of the client (i.e. web browser) and the application or web
    server.
        
      -----------------------------------------------------------------
                                NOTE
        TBSA is implemented as an API accessible via client-side 
        programming rather than HTTP headers sent to the server.
        This is consistent with the current trend in web application
        development, where an initial application 'seed' can be sent 
        to the client and expand dynamically based on client-side
        demand.  This strategy is a more scalable and robust approach
        which gives web developers the greatest amount of freedom with
        the lowest learning curve while not compromising on security.
      -----------------------------------------------------------------
      
    3.b. Browser Integrity Check (BIC)

        No security strategy will succeed without the verification of the
        platform's integrity.  Loss of integrity could mean that the 
        'trusted platform' is lying about its current state, rendering any 
        further work absolutely worthless.
        
        Because the web browser's integrity is in question, it cannot be 
        self-determined.  However, because the server most likely exists 
        outside the network perimeter and may not own or have rights to access
        lower-level operating system functionality (which in its own right would
        create other security issues), the browser integrity check must consist
        of both a client and server component, as described below:
        
        3.b.1 Client-side Browser-Integrity Check (BIC)
        
            The TBSA-compliant browser must provide a tbsa object whose methods
            are used for TBSA operations.  These standardized methods ensure 
            platform independence and a lower industry learning curve--two 
            factors that increase the likelihood this standard will be adopted.
            The browser-integrity check is an example of this.
            
            A TBSA-compliant browser must expose the following method for its 
            most basic operation:

            <string> tbsa.browserIntegrityCheck(<string> serverCallbackURL);

            When a web browser connects to a TBSA-aware web server, the web
            application calls tbsa.browserIntegrityCheck() through using some
            client-side programming language (e.g. JavaScript).  This call must
            specify some server-side facility for the TBSA Browser-Integrity 
            Check (i.e. serverCallBackURL).  The browser will execute the 
            browser-integrity check by performing an xmlHTTPrequest to the 
            serverCallBackURL where it will submit its digital signature to the
            server:
            
                    +-----------------------------------------------+
                    |           Browser-Integrity Check             |
                    |                   HTTP/POST                   |
                    +-----------------------------------------------+
                    |POST <some_serverCallback_url> HTTP/1.0        |
                    |From: <user_specification>                     |
                    |User-Agent: <browser-specfied agent>           |
                    |Content-Type: application/x-www-form-urlencoded|
                    |Content-Length: 32                             |
                    |                                               |
                    |browserName=<some_browser_name>&               |
                    |digitalSignature=<browser_digital_signature>   |
                    +-----------------------------------------------+
                    
            When tbsa.browserIntegrityCheck() submits its digital signature to
            the serverCallbackURL, the server-side arbitrary tbsa module will
            evaluate the digital signature to determine if the browser is to be
            trusted.  The browser must at no time know the outcome of this
            operation.  Thus, the server-side browser-integrity check routine 
            will return some TOKEN only the server can interpret.  This token is
            returned in response to the xmlHTTPrequest, and the browser, unable
            to process or interpret the token, is expected to return the same to
            the code which first invoked tbsa.browserIntegrityCheck().
             
            The TOKEN received upon termination of tbsa.browserIntegrityCheck()
            must be cross-verified with the server.  To do this, the code which
            first initiates the browser-integrity check must submit the TOKEN to
            its server-side component for cross-validation.  In response, the 
            server may reply with a simple boolean result or it may disconnect
            the session altogether.
                
            The entire Browser-Integrity Check process is illustrated below:
              
               +-------------------------------------------------------------+
               |                TBSA Browser-Integrity Check                 |
               |                     Client-side Example                     |
               +-------------------------------------------------------------+
               |                                                             |
               |<script type="text/javascript">                              |
               |      if(tbsa){                                              |
               |           var bicToken=tbsa.browserIntegrityCheck(          |
               |                          "http://foo.com/tbsa-bic.php"      |
               |                        );                                   |
               |                                                             |
               |           if(myApp.tbsaBicXverify(bicToken))){              |
               |                                                             |
               |            /* Browser-Integrity Check token is verified */  |
               |                                                             |
               |           } else {                                          |
               |                                                             |
               |              /*Browser Integrity Check failed!*/            |
               |                                                             |
               |           }                                                 |
               |      }else{                                                 |
               |                                                             |
               |              /*Browser is not TBSA-compliant*/              |   
               |                                                             |
               |      }                                                      |
               |  </script>                                                  |
               +-------------------------------------------------------------+      
    
               -----------------------------------------------------------------
                                A NOTE ON BIC TOKEN CONSTRUCTION
                The construction of BIC TOKENS is completely arbitrary, but any
                strategy should ensure the TOKEN is of reasonable complexity to
                ensure such a token cannot be easily guessed.  For this reason
                the BIC TOKEN must not be some value the browser might determine 
                by analyzing the web application.  It is suggested that this
                value should be a sha512 hash of some random string of no less 
                than 8192 bits (possibly including a timestamp.
               -----------------------------------------------------------------
        
            3.b.2 The Server-side of Browser-Integrity Check (BIC)
            
                The bulk of TBSA must be implemented at the client side.  
                However, to realize the benefit of TBSA, some server-side body
                is needed.  This server-side TBSA library must be platform-
                independent, and it must be easily applied in any of the several
                common server-side programming languages (e.g. ASP.NET, PHP, 
                Python, Perl).
            
                To implement the browser-integrity check at the server-side 
                requires any TBSA server-side library to have two components.
                The first is tbsa.bicValidate() and the second is 
                tbsa.bicXvalidate().
            
                tbsa.bicValidate() is the module which is exposed as the 
                serverCallBackURL used at the client side to obtain the BIC 
                TOKEN.
            
                This method must be aware of X.509 digital certificates and 
                capable of validating the same.  This may mean that 
                tbsa.bicValidate could use an existing project such as openSSL 
                to validate the certificate or it could apply some proprietary 
                strategy.  
            
                The tbsa.bicValidate() method must also be capable of generating
                the random BIC TOKEN for return to the calling entity.  This is
                a simple matter of generating a random string of bits then 
                performing a SHA512 hash operation on the same.  However, this 
                TOKEN must be cross-verified through tbsa.bicXvalidate().  Thus,
                the TOKEN must be stored for a reasonable amount of time in some
                server-side repository.  It must also be able to age-out old 
                TOKENS.
            
                tbsa.bicXvalidate() is the counterpart to tbsa.bicValidate().  
                This method must be able to recieve a TOKEN from the client-side
                and compare the TOKEN to the TOKENS registered by 
                tbsa.bicValidate(). Further, to minimize the attack surface of 
                registered TOKENS, the tbsa.bicXvalidate() method must remove 
                any TOKEN it cross-validates.  Removing cross-validated TOKENS
                conserves server-side storage also resources, but the primary 
                purpose is to avoid increasing the probability that some browser
                may 'guess' a valid TOKEN and spoof the TBSA framework.
                       
    3.c. Signed Third-Party Extensions and Add-on Software
        
        TBSA requires any 'trusted' browser, third-part extensions, or add-
        on software be digitally signed.  While it should remain possible to
        install and execute unsigned extensions and add-on software for 
        backward compatibility, only those software packages which are 
        digitally signed should be considered 'trusted.'
        
    3.d. TBSA Extension Privilege Levels (tbsa.extensionPrivileges)

        Browser extensions are the largest security risk in the current web
        application environment.  This risk arises largely from the lack of
        any boundaries or limits on the extension-space.  Web servers are 
        unable to limit the browser add-on/extension or to verify their 
        integrity if they are needed for the operation of the web application.
        
        The TBSA client-side API provides tbsa.extensionPrivileges() and four
        security levels for the control of any browser extension:

                +--------------------------------------+
                |        extensionSecurityLevel        |
                +---+----------------------------------+
                | 0 | Allow All Extensions             |
                | 1 | Allow Signed Extensions          |
                | 2 | Allow Specific Signed Extensions |
                | 3 | Disallow ALL extensions          |
                +---+----------------------------------+

        When a web browser connects to a web server, the browser extensions 
        are assumed to operate at some privilege level set by browser design
        and user permissions.  Where the web application is TBSA-aware and 
        the browser is TBSA-compliant, the application may invoke the 
        tbsa.extensionPrivileges() API call to either determine the current 
        security level or to negotiate a higher security level.
       
            <int> tbsa.extensionPrivileges( <int> intLevel,
                                            <array> arrAllowedExtensions=NULL
                                           );

           ----------------------------------------------------------------
                                     WARNING
             Caution must be exercised when implementing the browser TBSA
             API.  Calls to tbsa.extensionPrivileges must NEVER be allowed
             to negotiate a LOWER extension privilege level than the user's
             minimum (default) privilege level.
           ----------------------------------------------------------------

        Assume a web browser connects to some TBSA-aware web server and requests
        a web application.  This web application would, presumably first perform
        a browser-integrity check, as described in the preceeding sections, and
        then, if the browser's integrity is verified, evaluate and negotiate any
        browser extension security level.  This second security check may look 
        something like the example below: 

            <script type="text/javascript">
                if(tbsa.extensionPrivileges(1){
                    /*We have passed!  The extension privilege level is set
                      to our minimum specification*/
                }else{
                    alert('Browser cannot provide tbsa security level');
                }
            </script>bicValidate

        In the above example, the web application instructs the browser to 
        set a minimum browser extension security level of 1 ("Allow Signed
        Extensions").  The browser evaluates the request against its internal 
        preference (i.e. the internal minimum privilege level).  If possible 
        the browser will elevate its privilege level to the requested level.  
        
        Regardless of the outcome of any internal operations, the browser will 
        return its CURRENT browser extension security level.  Thus, in the 
        above example, where the browser is NOT TBSA-compliant, the call to the
        tbsa.extensionPrivileges() method would result in a zero or null value 
        which would cause an alert to be raised informing the end user that the
        web application cannot be run on his/her platform.
        
        However, assuming a browser processing the above script is TBSA-
        compliant and the browser's internal default privilege level is equal
        to or higher than the input value (1), the above example would allow
        the web application to load.  This presents a weakness for the above
        example that can be best addressed using a switch() statement and 
        fall-through to dynamically negotiate content rendered based on TBSA
        compliance:
        
                <script type="text/javascript">
                    switch(tbsa.extensionPrivileges(3)){
                        case 0:
                            /*Render security notification page.*/
                            break;
                        case 1:
                            /*Allow only non-sensitive content.*/
                            /*Fall-through*/
                        case 2:
                            /*Allow minimal content.*/
                            /*Fall-through*/
                        case 3:
                            /*Allow sensitive content.*/
                            break;
                        default:
                            /*Display error*/
                    }
                </script>
        
        In the above example, the web application could respond dynamically to 
        the browser's TBSA compliance level.  Assume, for example, that we have
        an travelling end-user who must remain connected to some corporate web 
        application.  The user most often uses a corporate laptop computer to
        engage the web application, but on one given trip the user's only access
        is through a public computer at, say, some coffee shop.  While on a
        trusted TBSA-compliant computer, the user logs in using only a username
        and password.  But when the web application detects that the browser at
        the coffee shop is not TBSA compliant, it executes a different user 
        login mechanism whereby the user must provide not only username and 
        password but a one-time passcode provided via automated telephone 
        message or other means.
        
        Another use of the above example is to disable specific features and 
        content (such as a banking site which may not allow wire transfers or 
        other operations without a TBSA-compliant browser).
        
        The tbsa.extensionPrivileges() API call can request a browser to allow 
        ANY extension to operate.  It may also require that ONLY signed 
        extensions be allowed to operate. At the opposite end of the spectrum, 
        the web application may require that all signed or unsigned extensions 
        be blocked from executing on the web site.  This leverages existing 
        mechanisms in most web browsers and will impose a small implementation 
        overhead.  The interesting feature of this API call is its ability to 
        specify a set of known extensions that may run, banning all others.
        Thus, where the web application includes a structure such as the 
        following, the browser may idenfify those extensions which it knows 
        and trusts:
                
                    <script type="text/javascript">
                        var arrAllowableExt=[
                                               {name:'booExtension'},
                                               {name:'cooExtension'},
                                               {name:'dooExtension'},
                                               {name:'fooExtension'},
                                               {name:'gooExtension'},
                                               {name:'mooExtension'},
                                            ];
                        switch(tbsa.extensionPrivileges( 2, arrAllowableExt)){
                            case 3:
                                /*
                                    Oops! 
                                          We may have needed those trusted
                                          extensions to run our web application
                                          but the browser restricts all 
                                          extensions.  The system should notify
                                          someone.
                                */  
                            case 2:
                                /*
                                    Success!
                                             We requested specific extensions 
                                             be allowed, and they were allowed.
                                             At this point we can proceed to 
                                             verify our extension integrity and
                                             load the application.
                            default:
                                /*
                                    Error!  
                                            The browser declined our request
                                            We are NOT trustworthy.
                                */
                        }
                    </script>

             --------------------------------------------------------------
                                          NOTE
               When the web browser engages a TBSA-aware web application, 
               it is presumed that the web developer will have designed 
               the system to first implement all TBSA security checks 
               before proceeding to render sensitive information to the 
               browser. However, nothing should preclude the web 
               application from re-engaging the browser's TBSA API to 
               reset or re-evaluate the TBSA privilege levels or integrity
               checks.  Thus, it is possible to elevate the required
               security when performing login or other sensitive
               operations, while relaxing these controls at other times.
             --------------------------------------------------------------

    3.e. Extension-Integrity Check (EIC)
        
        TBSA integrity verification starts with the browser integrity check 
        described earlier and continues to the extensions themselves.  Any
        browser-extension which is TBSA compliant must provide a valid 
        digital signature.  This signature may be used by browsers, the
        operating system and by engaged web applications to verify the 
        integrity of the extension, using the TBSA API.
        
        3.e.1. Client-Side Extension-Integrity Check (EIC)
            
            At extension privilege level one (1) or higher, as described in the
            above section, a browser extension may be considered 'trusted' and
            therefore must be subject to verification processes.  Unsigned 
            extensions are not subject to verification as they are ineligible 
            for 'trusted' status.  The integrity of a 'trusted' extension may be
            verified by a web application using the tbsa.validateExtension() API
            call:
            
                <bool> tbsa.validateExtension( <string>strExtensionName,
                                               <string>strServerCallbackURL
                                             );

            As with tbsa.browserIntegrityCheck(), the browser cannot be trusted 
            to perform any client-side security operation under TBSA.  Otherwise
            it would be feasible for a malicious party to construct a client-
            side exploit of the TBSA model.  Good security principles dictates
            that the perimeter must be well established between client and 
            server and all sensitive operations must be performed at the server
            until the integrity of the COMPLETE platform (including extensions)
            is verified.  For this reason, a call to tbsa.validateExtension() 
            must specify a server callback URL with which the browser will call
            the server to submit the digital certificate of a named extension.
            
            The name of any extension passed to tbsa.validateExtension() must 
            match the name of the extension identified in the certificate, and
            the server must be able to validate the certificate chain for the
            certificate.  Once the server-side module (identified by the call-
            back URL) has verified the extension, the server will generate an
            integrity-check verification TOKEN and return the same to the 
            browser.  The browser will then return the TOKEN to the calling
            structure, which must cross-verify the extension's integrity by
            submitting the TOKEN to the server's TBSA cross-validation API.  At
            this point, the server may either respond with a boolean 'true'
            value indicating "extension valid," or the server may respond with a
            boolean 'false' indicating the extension's integrity check failed. A
            web application's server-side could also discretely flag the session
            for termination and block any further communication with the client
            browser, at the discretion of the web application's developers.

        3.e.2. Server-Side Extension Integrity Check (EIC)
        
            The server side of an extension integrity check is facilitated by
            two methods (tbsa.eicValidate() and tbsa.eicXvalidate()).  The first
            method is exposed indirectly via the server call back URL to 
            validate the digital signature and generate the validation TOKEN the
            server will later cross-validate.  When the TOKEN is returned to the
            browser and the browser returns the TOKEN to its arbitrary calling
            structure, the calling structure must make the server-side 
            tbsa.eicXvalidate() API call in order to complete the validation
            process.
            
            At the server-side, when tbsa.eicValidate() is invoked, a TOKEN must
            be generated regardless of the validation outcome.  The browser must
            not be able to discern from the TOKEN whether or not the integrity
            check has passed or failed.  This protects the validation process
            from tipping its hand to the browser which (being suspect) could 
            craft a passing validation token for cross validation or otherwise 
            spoof a lesser strategy.
            
            When tbsa.eicValidate() generates the validation TOKEN, the token 
            must be returned to the browser as well as stored server-side for
            validation.  In order to reduce attack surface on the TOKEN space,
            the eicValidate() method should also be expected to age-off any 
            old TOKENS in its store.  No TOKEN, therefore, should be allowed to
            remain in a token store for more than a few seconds, as cross-
            validation should be a relatively immediate process.
            
            At the other side of the server-side validation process, the
            tbsa.eicXvalidate() method must be able to look up and compare the
            TOKEN received from the web application's client-side code to any
            TOKENs located in the token store and to return a boolean 'true' if
            the TOKEN exists or otherwise respond as appropriate to the web 
            application's design if no match is found.  Further, the cross-
            validation method must remove any TOKENS it has found matching a
            given value.  This too reduces the attack surface and prevents a 
            replay attack against the system.
            
    3.f. Ajax Privileges
    
        Ajax is a powerful tool which is essential in web application 
        development.  However, this also allows for many vulnerabilities the
        web application developer cannot control.  Thus, though there may be
        some extension which meets the standard for 'trusted' status, once this
        extension has access to the DOM, it is possible for the extension to
        share information in an unexpected and unauthorized manner with some
        third party.
        
        To avoid the abuse of Ajax by extensions or other code-injection 
        strategy, TBSA implements Ajax privileges:
        
            <int> tbsa.ajaxPrivileges( <int> intLevel,
                                            <array> arrUrlList=NULL
                                           );
                                           
                +-------------------------------+
                |       ajaxPrivilegeLevels     |
                +-------------------------------+
                | 0 | Allow All                 |
                | 1 | Allow Specific HTTP URLs  |
                | 2 | Allow Specific HTTPS URLs |
                | 3 | Block All URLs            |
                +-------------------------------+

        The default ajax privilege level must be assigned by the end-user or 
        browser design.  No web application should be allowed to reduce this
        default privilege level.  Web applications may only increase or identify
        the current privilege level.
        
        When a TBSA-compliant browser engages a web application, the application
        may query the browser for or request a specific Ajax privilege level in
        the same way the application may do so for the extension privilege 
        level.
        
        For example, a web application may include a block of code similar to 
        the following:
        
            <script type="text/javascript">
                switch(tbsa.ajaxPrivileges(3)){
                    case 3:
                            /*
                                SUCCESS: 
                                            We have blocked all third-party 
                                            Ajax calls.  This would allow the
                                            application to only talk to its 
                                            own server(s), as determined by
                                            FQDN.
                            */
                    case 2:
                            /*
                                ALLOW SPECIFIC HTTPS:
                                            
                                            The browser has indicated it cannot
                                            block all third-party URLS for some
                                            reason, but it can limit access to
                                            a few specific URLS over HTTPS.  If 
                                            none were identified, this may be
                                            the same as the requested level 3,
                                            but this should not be trusted to be
                                            the case.
                            */
                    case 1:
                            /*
                                ALLOW SPECIFIC HTTP:
                                        
                                            The browser has indicated that it 
                                            can only restrict ajax to specific
                                            URLs using either HTTP or HTTPS.  If
                                            no URLs were identified, this may 
                                            have the same effect as level 3, but
                                            this should not be assumed to be the
                                            case.
                            */
                    default:
                            /*
                                OOPS!
                                            The browser has declined to honor 
                                            the TBSA ajax privileges request or
                                            it is unable to do so.  In either 
                                            case, the effect is the same.  No
                                            restrictions on Ajax are in place
                                            at this time.
                            */
                }
            </script>
     
        In the above example, we use a switch() ladder at the client side to 
        process the TBSA Ajax negotiation.  Assuming we wish to lock down all
        thrid-party Ajax transactions, and the browser responds with any value
        less than our requested level 3 lock-down on Ajax, our web application
        should respond by refusing to proceed.
        
        Alternatively, if the web application is accessed by a browser but 
        refuses to lock-down the ajax privileges as we have requested, the 
        application could show an error message or warning that notifies the 
        end user of the problem and asks that they agree to proceed (thereby
        making an informed decision).
        
        Content could be restricted based on the above script given a browser's 
        response in order to minimize the risk to security while not completely
        disabling a customer/user base.
        
        When restricting Ajax privileges to specific URLs, a call to 
        tbsa.ajaxPrivileges() must be given a one-dimensional array of strings
        that describes URL of every allowed site.  TBSA must also allow the 
        dynamic reconfiguration of the Ajax privileges.  Thus, a web application
        could begin with a complete ajax lock-down and then slowly introduce
        allowed URLs as the site requires, minimizing the attack surface at any
        given time.

   3.g. Password Encryption
   
        The example in the earlier problem statement involved stealing a value
        from some password field on a web page using JavaScript code injection.
        While the other measures specified in this document could prevent many
        attacks of this nature, password information is nonetheless stored in
        cleartext.  A TBSA-compliant browser should encrypt this information as
        it is input by the end-user.
        
        To facilitate inline password encryption, TBSA-compliant browsers must
        provide the following API calls:
        
            <bool> tbsa.passwordEncryption(<string> publicKey);
            
        The server can, therefore, configure the means by which the browser
        will protect password fields.  The server may set an arbitrary public
        key for use with the AES encryption algorithm using the above method.
        When a field is specified in some website using the HTML <input /> tag 
        with a field type of "password," a TBSA-compliant browser should ensure
        the field value is encrypted as key strokes are encountered.
        
        Because the server is specifying the public key of an encryption scheme
        the browser may only encrypt the password information without any risk
        of the cryptographic system being compromised by some third party.  Also
        because the server is establishing the public key cryptography 
        parameters, the browser must only perform the encrypt operation then 
        submit the information to the server, where it can be decrypted.

4. Security Considerations

    There do not appear to be any security considerations associated with the
    Trusted Browser Security Architecture at this time, other than those 
    expressed elsewhere in this document.  The TBSA is intended as a loosely
    defined framework of client-server interactions, which when implemented by
    specific web browser developers/vendors may reveal implementation-specific
    vulnerabilities or security concerns that are best addressed on a case-by-
    case basis.

5. IANA Considerations

    There are no anticipated IANA Considerations.  The subject discussed in this
    document do not alter the specifications for any internet identifiers.  The
    proposed TBSA is intended to operate at the application layer of the OSI
    reference model, and has no impact on the other layers of said model.  

6. Conclusion

    The solution proposed herein is intended to be backward compatible and
    to impose the minimal administrative overhead and industry investment
    to address the described problem.  For this reason, no new protocols
    are needed.  Nor are any server-side changes required, other than the
    implementation of TBSA-aware code within the web applications.  The key
    to addressing the described vulnerability is to implement TBSA within
    all browsers and to enforce the TBSA at the server-side through the use
    of TBSA-aware code within those applications which require the additional
    security.

7. Contributors

8. Acknowledgements

    The following persons are acknowledged for their feedback and peer-review
    of this document prior to submission:

        Tristan Slominski
        Daniel Molina Wegener(dmw@coder.cl)
        Phil Salemi (phil@firelytics.com)
        Keith Chadwick (keith.chadwick@magma.ca)

9. Appendicies

    There are no appendicies at this time.

10. References

    Wadlow, T., Gorelik, Vlad.  "Security in the Browser."  Communications of 
    the ACM.  Vol. 52, No. 5.  May 2009.

    See also Barth, A., et al. "Protecting Browsers from Extension
    Vulnerabilities." University of California at Berkley.  Technical Report No.
    UCB/EECS-2009-185 http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-
    2009-185.pdf.  December 18, 2009

11. Author's Address

    Sam Caldwell
    POBox 2401
    Round Rock, Texas 78680
    512.963.7805
    mail@samcaldwell.net
    http://samcaldwell.net
    skype: x684867

12. IPR Boilerplate