Subject: [websec] draft: draft-hodges-websec-framework-reqs-00

From: =JeffH <[email-masked]>
Date: Fri, 04 Mar 2011 05:48:48 -0800

per the websec charter, we're supposed to produce a "HTTP Application Security 
Problem Statement and Requirements" document.

the deadline for I-D -00 submission is this coming monday and I have a drafty 
draft to submit then. Here's it's present state in order to give you a bit of a 
heads up and chance (sorry it not much time) to quickly review before then (but 
this is just a -00 and this is to get discussion kicked off now and in Prague).

=JeffH
-------

Network Working Group                                          J. Hodges
Internet-Draft                                            A. Steingruebl
Intended status: Standards Track                                  PayPal
Expires: August 27, 2011                                    Feb 23, 2011

        Web Security Framework: Problem Statement and Requirements
                  draft-hodges-websec-framework-reqs-00

Abstract

    Web-based malware and attacks are proliferating rapidly on the
    Internet.  New web security mechanisms are also rapidly growing in
    number, although in an incoherent fashion.  This document provides a
    brief overview of the present situation and the various seemingly
    piece-wise approaches being taken to mitigate the threats.  It then
    provides an overview of requirements as presently being expressed by
    the community in various online and face-to-face discussions.

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 August 27, 2011.

Copyright Notice

    Copyright (c) 2011 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

Hodges & Steingruebl     Expires August 27, 2011                [Page 1]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
      2.1.  The Present State of Affairs . . . . . . . . . . . . . . .  3
      2.2.  High-level Use Cases . . . . . . . . . . . . . . . . . . .  4
    3.  Document Conventions . . . . . . . . . . . . . . . . . . . . .  5
    4.  Overall Constraints  . . . . . . . . . . . . . . . . . . . . .  5
    5.  Overall Requirements . . . . . . . . . . . . . . . . . . . . .  6
    6.  Attacks and Threats to Address . . . . . . . . . . . . . . . .  8
      6.1.  Attacks  . . . . . . . . . . . . . . . . . . . . . . . . .  8
      6.2.  Threats  . . . . . . . . . . . . . . . . . . . . . . . . .  9
    7.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
    8.  Detailed Functional Requirements . . . . . . . . . . . . . . . 11
    9.  Extant Policies to Coalesce? . . . . . . . . . . . . . . . . . 18
    10. Example Concrete Approaches  . . . . . . . . . . . . . . . . . 19
    11. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
    13. Informative References . . . . . . . . . . . . . . . . . . . . 23
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23

Hodges & Steingruebl     Expires August 27, 2011                [Page 2]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

1.  Introduction

    [ Please disscuss this draft on the [email-masked] mailing list
    [WebSec]. ]

2.  Overview

2.1.  The Present State of Affairs

    Over the past few years, we have seen a proliferation of AJAX-based
    web applications (AJAX being shorthand for asynchronous JavaScript
    and XML), as well as Rich Internet Applications (RIAs), based on so-
    called Web 2.0 technologies.  These applications bring both luscious
    eye-candy and convenient functionality--e.g. social networking--to
    their users, making them quite compelling.  At the same time, we are
    seeing an increase in attacks against these applications and their
    underlying technologies [1].  The latter include (but aren't limited
    to) Cross-Site-Request Forgery (CSRF) -based attacks [2], content-
    sniffing cross-site-scripting (XSS) attacks [3], attacks against
    browsers supporting anti-XSS policies [4], clickjacking attacks [5],
    malvertising attacks [6], as well as man-in-the-middle (MITM) attacks
    against "secure" (e.g.  Transport Layer Security (TLS/SSL)-based [7])
    web sites along with distribution of the tools to carry out such
    attacks (e.g. sslstrip) [8].

    During the same time period we have also witnessed the introduction
    of new web security indicators, techniques, and policy communication
    mechanisms sprinkled throughout the various layers of the Web and
    HTTP.  We have a new cookie security flag called HTTPOnly [9].  We
    have the anti-clickjacking X-Frame-Options HTTP header [10], the
    Strict-Transport-Security HTTP header [11], anti-CSRF headers (e.g.
    Origin) [12], an anti-sniffing header (X-Content-Type-Options:
    nosniff) [13], various approaches to content restrictions [14] [15]
    and notably Mozilla Content Security Policy (CSP; conveyed via a HTTP
    header) [16], the W3C's Cross-Origin Resource Sharing (CORS; also
    conveyed via a HTTP header) [17], as well as RIA security controls
    such as the crossdomain.xml file used to express a site's Adobe Flash
    security policy [18].  There's also the Application Boundaries
    Enforcer (ABE) [19], included as a part of NoScript [20], a popular
    Mozilla Firefox security extension.  Sites can express their ABE
    rule-set at a well-known web address for downloading by individual
    clients [21], similarly to Flash's crossdomain.xml.  Amidst this
    haphazard collage of new security mechanisms at least one browser
    vendor has even devised a new HTTP header that disables one of their
    newly created security features: witness the X-XSS-Protection header
    that disables the new anti-XSS features [22] in Microsoft's Internet
    Explorer 8 (IE8).

Hodges & Steingruebl     Expires August 27, 2011                [Page 3]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    Additionally, there are various proposals aimed at addressing other
    facets of inherent web vulnerabilities, for example: JavaScript
    postMessage-based mashup communications [23], hypertext isolation
    techniques [24], and service security policies advertised via the
    Domain Name System (DNS) [25].  Going even further, there are efforts
    to redesign web browser architectures [26], of which Google Chrome
    and IE8 are deployed examples.  An even more radical approach is
    exhibited in the Gazelle Web Browser [27], which features a browser
    kernel embodied in a multi-principal OS construction providing cross-
    principal protection and fair sharing of all system resources.

    Not to be overlooked is the fact that even though there is a plethora
    of "standard" browser security features--e.g. the Same Origin Policy
    (SOP), network-related restrictions, rules for third-party cookies,
    content-handling mechanisms, etc. [28]--they are not implemented
    uniformly in today's various popular browsers and RIA frameworks
    [29].  This makes life even harder for web site administrators in
    that allowances must be made in site security posture and approaches
    in consideration of which browser a user may be wielding at any
    particular time.

    Although industry and researchers collectively are aware of all the
    above issues, we observe that the responses to date have been issue-
    specific and uncoordinated.  What we are ending up with looks perhaps
    similar to Frankenstein's monster [30]--a design with noble intents
    but whose final execution is an almost-random amalgamation of parts
    that do not work well together.  It can even cause destruction on its
    own [31].

2.2.  High-level Use Cases

    From our perspective as web site security practitioners, we believe
    that in the intermediate term we have the goal of deplying web
    browsers featuring more coherent security properties than they do
    today.  We feel that cooperatively working to address specific
    subsets of the overall problem space will yield measurable results
    for both site operators and our users.

    For example, we want to be able to deploy security policies for site-
    wide cookie handling, content restrictions, secure connection
    preferences, and various other things.  We believe that continuing
    the current defacto practice of designing new, disjoint, HTTP headers
    for expressing individual facets of overall site security policies is
    not desirable for even the intermediate term.

    The individual headers, however expeditious in the near-term, should
    be replaced with a more generic, decarative, extensible, security
    policy expression and communication mechanism for the Web--a "website

Hodges & Steingruebl     Expires August 27, 2011                [Page 4]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    security policy framework".  This policy communication mechanism must
    be secure and should have two facets, one for communicating securely
    out-of-band of the HTTP protocol to allow for secure client policy
    store bootstrapping, and then another in-band over HTTP/HTTPS for
    ease of policy delivery, configuration, and to leverage existing
    deployments.  For out-of-band secure client policy store
    bootstrapping, potential approaches are factory-installed web browser
    configuration, site security policy download a la Flash's
    crossdomain.xml and Maone's ABE for Web Authors [21], and DNS-based
    policy advertisement leveraging the security of DNS Security (DNSSEC)
    [32].

    In general, what we are striving for is to provide web site
    administrators the tools for managing, in a least privilege [33]
    manner, the overall security characteristics of their web site/
    applications when realized in the context of user agents.

3.  Document Conventions

    Note:  ..is a note to the reader.  These are points that should be
           expressly kept in mind and/or considered.

    Warning:  This is how a warning is shown.  These are things that can
              have suboptimal downside risks if not heeded.

    [[XXXn: Some of the more major known issues are marked like this
    (where "n" in "XXXn" is a number). --JeffH]]

    [[TODOn: Things to fix (where "n" in "TODOn" is a number). --JeffH]]

4.  Overall Constraints

    Regardless of the overall approaches chosen for conveying site
    security policies, we believe that to be deployed at Internet-scale,
    and to be as widely usable as possible for both novice and expert
    alike, the overall solution approach will need to address these three
    points of tension:

       Granularity:

          There has been much debate during the discussion of some policy
          mechanisms (e.g.  CSP) as to how fine-grained such mechanisms
          should be.  The argument against fine-grained mechanisms is
          that site administrators will cause themselves pain by
          instantiating policies that do not yield the intended results.
          E.g. simply copying the expressed policies of a similar site.

Hodges & Steingruebl     Expires August 27, 2011                [Page 5]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

          The claim is that this would occur for various reasons stemming
          from the mechanisms' complexity [34].

       Configurability:

          Not infrequently, the complexity of underlying facilities, e.g.
          in server software, is not well-packaged and thus
          administrators are obliged to learn more about the intricacies
          of these systems than otherwise might be necessary.  This is
          sometimes used as an argument for "dumbing down" the
          capabilities of policy expression mechanisms [34].

       Usability:

          Research shows that when security warnings are displayed, users
          are often given too much information as well as being allowed
          to relatively easily bypass the warnings and continue with
          their potentially compromising activity [35] [36] [37] [38]
          [39].  Thus users have become trained to "click through"
          security notifications "in order to get work done", though not
          infrequently rendering themselves insecure and perhaps
          compromised [40].

    In the next section we discuss various high-level requirements
    derived with the guidance of the latter tension points.

5.  Overall Requirements

    1.  Policy conveyance:

           in-band:

              We believe that a regime based on HTTP header(s) is
              appropriate.  However we must devise a generalized,
              extensible HTTP security header(s) such that the on-going
              "bloat" of the number of disjoint HTTP security headers is
              mitigated and there is a documented framework that we can
              leverage as new approaches and/or threats emerge.

              Note:  The distinction between in-band and out-of-band
                     signaling is difficult to characterize because some
                     seemingly out-of-band mechanisms rely on the same
                     protocols (HTTP/HTTPS) and infrastructure
                     (transparent proxy servers) as the protocols they
                     ostensibly protect.

Hodges & Steingruebl     Expires August 27, 2011                [Page 6]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

              It may be reasonable to devise a small set of headers to
              convey different classes of policies, e.g. web application
              content policies versus web application network
              capabilities policies.

           out-of-band:

              This policy communication mechanism must be secure and
              should have two facets, one for communicating securely out-
              of-band of the HTTP protocol to allow for secure client
              policy store bootstrapping. potential approaches are
              factory-installed web browser configuration, site security
              policy download a la Flash's crossdomain.xml and Maone's
              ABE for Web Authors [21], and DNS-based policy
              advertisement leveraging the security of DNS Security
              (DNSSEC) [32].

    2.  Granularity:

           In terms of granularity, vast arrays of stand-alone blog,
           wiki, hosted web account, and other "simple" web sites could
           ostensibly benefit from relatively simple, pre-determined
           policies.  However, complex sites--e.g. payment, ecommerce,
           software-as-a-service, mashup sites, etc.--often differ in
           various ways, as well as being inherently complex
           implementation-wise.  One-size-fits-all policies will
           generally not work well for them.  Thus, we believe that to be
           effective for a broad array of web site and application types,
           the policy expression mechanism must fundamentally facilitate
           fine-grained control.  For example, CSP offers such control.
           In order to address the less complex needs of the more simple
           classes of web sites, the policy expression mechanism could
           have a "macro"-like feature enabling "canned policy profiles".
           Or, the configuration facilities of various components of the
           web infrastructure can be enhanced to provide an appropriately
           simple veneer over the complexity.

    3.  Configurability:

           With respect to configurability, development effort should be
           applied to creating easy-to-use administrative interfaces
           addressing the simple cases, like those mentioned above, while
           providing advanced administrators the tools to craft and
           manage fine-grained multi-faceted policies.  Thus more casual
           or novice administrators can be aided in readily choosing, or
           be provided with, safe default policies while other classes of
           sites have the tools to craft the detailed policies they
           require.  Examples of such an approach are Microsoft's

Hodges & Steingruebl     Expires August 27, 2011                [Page 7]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

           "Packaging Wizard" [41] that easily auto-generates a quite
           complicated service deployment descriptor on behalf of less
           experienced administrators, and Firefox's simple Preferences
           dialog [42] as compared to its detailed about:config
           configuration editor page [43].  In both cases, simple usage
           by inexperienced users is anticipated and provided for on one
           hand, while complex tuning of the myriad underlying
           preferences is provided for on the other.

    4.  Usability:

           Much has been learned over the last few years about what does
           and does not work with respect to security indicators in web
           browsers and web pages, as noted above, these lessons should
           be applied to the security indicators rendered by new proposed
           security mechanisms.  We believe that in cases of user agents
           venturing into insecure situations, their response should be
           to fail the connections by default without user recourse,
           rather than displaying warnings along with bypass mechanisms,
           as is current practice.  For example, the Strict Transport
           Security specification stipulates the former hard-fail
           behavior.

6.  Attacks and Threats to Address

    This section enumerates various attacks and threats that ought to be
    mitigated by a web security policy framework.  In terms of defining
    threats in contrast to attacks, Lucas supplied this:

    <"Re: More on XSS mitigation (was Re: XSS mitigation in browsers)"
    (Lucas Adamski).  http://lists.w3.org/Archives/Public/
    public-web-security/2011Jan/0089.html>

       "...  There's a fundamental question about whether we should be
       looking at these problems from an attack vs threat standpoint.  An
       attack is XSS [or CSRF, or Response Splitting, etc.].  A threat is
       that an attacker could compromise a site via content injection to
       trick the user to disclosing confidential information (by
       injecting a plugin or CSS to steal data or fool the user into
       sending their password to the attacker's site). ..."

6.1.  Attacks

    The below attacks should be mitigated by a web application security
    framework (see [44] for a definition and taxonomy of attacks):

Hodges & Steingruebl     Expires August 27, 2011                [Page 8]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    1.  cross-site-scripting (XSS) [2] [44]

    2.  Cross-Site-Request Forgery (CSRF) [3] [44]

    3.  Man-in-the-middle (MITM) attacks against "secure" (e.g.
        Transport Layer Security (TLS/SSL)-based [7] [8] [44]) web sites

    4.  Response Splitting [44]

    5.  more (ie eg from [44] ?) ?

6.2.  Threats

    Via the attacks above, an attacker can..

    1.  Obtain a victim's confidential web application credentials (e.g.
        cookie theft), and use the credentials to impersonate the victim
        and enter into transactions, often with the aim of monetizing the
        transaction results to the attacker's benefit.

    2.  Insert themselves as a Man-in-the-Middle (MITM) between victim
        and various services, thus is able to instigate, control,
        intercept, and attempt to monetize various transactions and
        interactions with web applications, to the benefit of the
        attacker.

    3.  Enumerate various user agent information stores, e.g. browser
        history, facilitating views of the otherwise confidential habits
        of the victim.  This information could possibly be used in
        various offline attacks against the victim directly, e.g.
        blackmail, denial of services, law enforcement actions, etc.

    4.  Use gathered information and credentials to construct and present
        a falsified persona of the victim (e.g. for character
        assassination).

    There is a risk of exfiltration of otherwise confidential victim
    information with all the threats listed above.

7.  Use Cases

    This section outlines various concrete use cases.  Where applicable,
    source email messages are cited.

    1.  I'm a web application site administrator.  My web app includes
        static user-supplied content (e.g. submitted from user agents via
        HTML FORM + HTTP POST), but either my developers don't properly

Hodges & Steingruebl     Expires August 27, 2011                [Page 9]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

        sanitize user-supplied content in all cases or/and content
        injection vulnerabilities exist or materialize (for various
        reasons).

        This leaves my web app vulnerable to cross-site scripting.  I
        wish I could set overall web app-wide policies that prevent user-
        supplied content from injecting malicious content (e.g.
        JavaScript) into my web app.

    2.  I'm a web application site administrator.  My web application is
        intended, and configured, to be uniformly served over HTTPS, but
        my developers mistakenly keep including content via insecure
        channels (e.g. via HTTP-only; resulting in so-called "mixed
        content").

        I wish I could set a policy for my web app that prevents user
        agents from loading content insecurely even if my web app is
        otherwise telling them to do so.

    3.  I'm a web application site administrator.  My site has a policy
        that we can only include content from certain trusted providers
        (e.g., our CDN, Amazon S3), but my developers keep adding
        dependencies on origins I don't trust.  I wish I could set a
        policy for my site that prevents my web app from accidentally
        loading resources outside my whitelist.

    4.  I'm a web application site administrator.  I want to ensure that
        my web app is never framed by other web apps.

    5.  I'm a developer of a web application which will be included (i.e.
        framed) by third parties within their own web apps.  I would like
        to ensure that my web app directs user agents to only load
        resources from URIs I expect it to (possibly even down to
        specific URI paths), without affecting the containing web app or
        any other web apps it also includes.

    6.  I'm a web application site administrator.  My web app frames
        other web apps whose behavior, properties, and policies are not
        100% known or predictable.

        I need to be able to apply policies that both protect my web app
        from potential vulnerabilities or attacks introduced by the
        framed web apps, and that work to ensure that the desired
        interactions between my web app and the framed apps are securely
        realized.

Hodges & Steingruebl     Expires August 27, 2011               [Page 10]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

8.  Detailed Functional Requirements

    Many of the below functional requirements are extracted from a recent
    discussion on the [public-web-security] list.  Particular messages
    are cited inline and appropriate quotes extracted and reproduced
    here.  Inline citations are provided for definitions of various
    terms.

    1.   Policy expression syntax:

         *  Declarative.

               <"declarative languages".  http://www.encyclopedia.com/
               doc/1O11-declarativelanguages.html>

         *  Extensible.

               <"Extensibility".
               https://secure.wikimedia.org/wikipedia/en/wiki/Extensible>

         <"Re: XSS mitigation in browsers" (Lucas Adamski).  http://
         lists.w3.org/Archives/Public/public-web-security/2011Jan/
         0066.html>

            "On a conceptual level, I am not really a believer in the
            current proliferation of orthogonal atomic mechanisms
            intended to solve very specific problems.  Security is a
            holistic discipline, and so I'm a big supporter of investing
            in an extensible declarative security policy mechanism that
            could evolve as the web and the threats that it faces do.
            Web developers have a hard enough time with security already
            without being expected to master a potentially large number
            of different security mechanisms, each with their own unique
            threat model, implementation and syntax.  Not to mention
            trying to figure out how they're expected to interact with
            each other... how to manage the gaps and intersections
            between the models."

         <"Re: Scope and complexity (was Re: More on XSS mitigation)"
         (Adam Barth).  http://lists.w3.org/Archives/Public/
         public-web-security/2011Jan/0108.html>

            "I guess I wish we had an extensibility model more like HTML
            where we could grow the security protections over time.  For
            example, we can probably agree that both <canvas> and <video>
            are great additions to HTML that might not have made sense
            when folks were designing HTML 1.0.

Hodges & Steingruebl     Expires August 27, 2011               [Page 11]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

            As long as you're not relying on the security policy as a
            first line of defense, the extensibility story for security
            policies is even better than it is with HTML tags.  With an
            HTML tag, you need a fall-back for browsers that don't
            support the tag, whereas with a security policy, you'll
            always have your first line of defense.

            Ideally, we could come up with a policy mechanism that let us
            nail XSS today and that fostered innovation in security for
            years to come.  In the short term, you could view the
            existing CSP features (e.g., clickjacking protection) as the
            first wave of innovation.  If those pieces are popular, then
            it should be easy for other folks to adopt them."

    2.   Tooling:

         *  We will need tools to (idealy) analyze a web application and
            generate a starting point security policy.

         <"Re: More on XSS mitigation" (John Wilander).  http://
         lists.w3.org/Archives/Public/public-web-security/2011Jan/
         0082.html>

            "*Developers Will Want a Policy Generator* A key issue for
            in-the-field success of CSP is how to write, generate and
            maintain the policies.  Just look at the epic failure of Java
            security policies.  The Java policy framework was designed
            for static releases shipped on CDs, not for moving code,
            added frameworks, new framework versions etc.  The world of
            web apps is so dynamic I'm still amazed.  If anything, for
            instance messy security policies, gets in the way of daily
            releases it's a no go.  At least until there's an exploit.
            Where am I going with this?  Well, we should implement a PoC
            *policy generator* and run it on some fairly large websites
            before we nail the standard.  There will be subtleties found
            which we can address and we can bring the PoC to production
            level while the standard is being finalized and shipped in
            browsers.  Then we release the policy generator along with
            policy enforcement -- success! "

    3.   Performance:

         *  Minimizing performance impact is a first-order concern.

         <"Re: More on XSS mitigation" (John Wilander).  http://
         lists.w3.org/Archives/Public/public-web-security/2011Jan/
         0082.html>

Hodges & Steingruebl     Expires August 27, 2011               [Page 12]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

            "*We Mustn't Spoil Performance* Web developers (and browser
            developers) are so hung up on performance that we really need
            to look at what they're up to and make sure we don't spoil
            things.  Especially load performance now that it's part of
            Google's rating."

    4.   Granularity:

         *  For example, discriminate between:

            +  "inline" script in <head> versus <body>, or not.

            +  "inline" script and "src=" loaded script.

            +  Classes of "content", e.g. scriptable content, passive
               multimedia, nested documents, etc.

         <"Proposal to move the debate forward" (Daniel Veditz).  http://
         lists.w3.org/Archives/Public/public-web-security/2011Jan/
         0122.html>

            "We oscillated several times between lumpy and granular.
            Fewer classes (simpler) is always more attractive, easier to
            explain and understand.  The danger is that future features
            then end up being added to the existing lumps, possibly
            enabling things that the site isn't aware they need to now
            filter.  It's a constant problem as we expand the
            capabilities of browsers -- sites that used to be perfectly
            secure are suddenly hackable because all the new browsers
            added feature-X."

    5.   Notifications and reporting:

         *  Convey to the user agent an identifier (e.g. a URI) denoting
            where to send policy violation reports.  Could also specify a
            DOM event to be dedicated for this purpose.

         *  An ability to specify that a origin's policies are to be
            enforced in a "report only" mode will be useful for debugging
            policies as well as site-policy interactions.  E.g. for
            answering the question: "does my policy 'break' my site?".

         <"[Content Security Policy] Proposal to move the debate forward"
         (Brandon Sterne).  http://lists.w3.org/Archives/Public/
         public-web-security/2011Jan/0118.html>

Hodges & Steingruebl     Expires August 27, 2011               [Page 13]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    "...
    3. Violation Reporting
       a. report-uri: URI to which a report will be sent upon policy
          violation
       b. SecurityViolation event: DOM event fired upon policy violations
     ..."

    6.   Facilitating Separation of Duties:

         *  Specifically, allowing for Web Site operations/deployment
            personnel to apply site policy, rather then having it being
            encoded in the site implementation code by side developers/
            implementors.

         <"RE: Content Security Policy and iframe@sandbox" (Andrew
         Steingruebl).  http://lists.w3.org/Archives/Public/
         public-web-security/2011Feb/0050.html>

            "... 2.  SiteC is also totally in control of all HTTP headers
            it emits.  It could just as easily indicate policy choices
            for all frames via CSP.  It could advertise a blanket policy
            (No JS, No ActiveX).  Advertising a page-specific, or frame/
            target specific policy is substantially more difficult and
            probably unwieldy.  But, depending on how SiteC is
            configured, setting a global site policy via headers offers a
            potential separation of duties that #1 does not, it allows
            website admin to specific things that each web developer
            might not be able to. ..."

    7.   Hierarchical Policy Application:

         *  The notion that policy emitted by the application's source
            origin is able to constrain behavior and policies of
            contained origins.

         <"RE: Content Security Policy and iframe@sandbox" (Andrew
         Steingruebl).  http://lists.w3.org/Archives/Public/
         public-web-security/2011Feb/0048.html>

            "...  I could imagine a tweak to CSP wherein CSP would
            control all contents hierarchically.  I already spoke to
            Brandon about it, but it was just a quick brainstorm.

            You could imagine revoking permissions in the frame hierarchy
            and not granting them back.  This does start to get awfully
            ugly, but just as CSP controls loading policy for itself, it
            could also control loading policy for children, ..."

Hodges & Steingruebl     Expires August 27, 2011               [Page 14]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    8.   Framing Policy Hierarchy, cross-origin, granularity:

            <"Re: Content Security Policy and iframe@sandbox") (Andy
            Steingruebl, Adam Barth) http://lists.w3.org/Archives/Public/
            public-web-security/2011Feb/0051.html>

On Sat, Feb 12, 2011 at 9:01 PM, Steingruebl, Andy
                 <[email-masked]> wrote:
 >> -----Original Message-----
 >> From: Adam Barth [mailto:[email-masked]]
 >
 >> That all sounds very abstract. If you have some concrete examples,
 >> that might be more productive to discuss. When enforcing policy
 >> supplied by one origin on another origin, we need to be careful to
 >> consider the case where the policy providing origin is the attacker
 >> and the origin on which the policy is being enforced is the victim.
 >
 > SiteA  wants to make sure it cannot ever be framed.  It deploys
X-Frame-Options headers and framebusting JS, and maybe even CSP
frame-ancestors.
 >
 > SiteB wants to make sure it never loads data from anything other than
SiteB (no non-origin loads).  It outputs CSP headers to this effect
 >
 > SiteC wants to make sure that any content it frames cannot run ActiveX
controls, nor do a 401 authentication.  It can't really do this with
current iframe sandboxing, but pretend it could...
 >
 > SiteC wants to control the behavior of children that it frames.  It
needs to advertise this policy to a web browser.  It has two choices:
 >
 > 1. It can do it inline in the HTML it outputs with extra attributes of
the iframe it creates.  SiteC is in complete control of the HTML that
creates the iframe.  I can impose any policy via sandbox attributes.
Currently for example, it can disable JS in the frame.  If it frames
SiteA, SiteA's framebusting JS will never run, but the browser will
respect its X-Frame-Options headers.
 >
 > 2. SiteC is also totally in control of all HTTP headers it emits.  It
could just as easily indicate policy choices for all frames via CSP.  It
could advertise a blanket policy (No JS, No ActiveX).  Advertising a
page-specific, or frame/target specific policy is substantially more
difficult and probably unwieldy. But, depending on how SiteC is
configured, setting a global site policy via headers offers a potential
separation of duties that #1 does not, it allows website admin to
specific things that each web developer might not be able to.

Hodges & Steingruebl     Expires August 27, 2011               [Page 15]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

 >
 > 3. Because all of Site A,B,C are in different origins, they don't
really have to worry about polluting other origins, but they do have to
worry about problematic behavior such as top-nav, 401-auth popups, etc.
Parents need to constrain certain behavior of things they embed,
according to certain rules of whether the child allows itself to be
framed.
 >
 > I totally get how existing iframe sandboxing that turns off JS is
problematic for sites [due to] older browsers that don't support
X-Frame-Options.  We already have a complicated interaction between
these multiple security controls.
 >
 > Can you give me an example of why my #1/#2 are actually that
different?  Whether we control behavior with headers of inline content,
each site is totally responsible for what it emits, and can already
control in some interesting ways the behavior of content it
frames/includes.

In this example, the trade-off for Site C seems to boil down to the
granularity of the policy.  Using attributes on a frame is more
fine-grained because Site C can make these decisions on an
iframe-by-iframe basis whereas using a document-wide policy is more
coarse-grained.

Of course, there's a trade-off between different granularities.  On
the one hand, fine-grained gives the site more control over how
different iframes behavior.  On the other hand, it's much easier to
audit and understand the effects of a coarse-grained policy.

Adam

    9.   Policy Delivery:

         *  The web application policy must be communicated by the web
            application to the user agent.  There are various approaches
            and they have tradeoffs between security, audience, and
            practicality.

         <"[Content Security Policy] Proposal to move the debate forward"
         (Brandon Sterne).  http://lists.w3.org/Archives/Public/
         public-web-security/2011Jan/0118.html>

Hodges & Steingruebl     Expires August 27, 2011               [Page 16]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    "...
    6. Policy delivery
       a. HTTP header
       b. <meta> (or <link>) tag, to be superseded by header if present
       c. policy-uri: a URI from which the policy will be fetched; can be
          specified in either header or tag
    ..."

         <"Re: [Content Security Policy] Proposal to move the debate
         forward" (gaz Heyes).  http://lists.w3.org/Archives/Public/
         public-web-security/2011Jan/0148.html>

            "...
            a) Policy shouldn't be defined in a http header it's too
            messy and what happens when there's a mistake?

            b) As discussed on the list there is no need to have a
            separate method as it can be generated by an attacker.  If a
            policy doesn't exist then an attacker can now DOS the web
            site via meta.

            c) We have a winner, a http header specifying a link to the
            policy file is the way to go IMO, my only problem with it is
            devs implementing it.  Yes facebook would and probably
            twitter would but Dave's tea shop wouldn't pay enough money
            to hire a web dev who knew how to implement a custom http
            header yet they would know how to validate HTML.  So the
            question is are we bothered about little sites that are
            likely to have nice tea and XSS holes?  If so I suggest
            updating the HTML W3C validator to require a security policy
            to pass validation if not I suggest a policy file delivered
            by http header.
            ..."

    10.  Policy Conflict Resolution:

         *

         <"RE: Content Security Policy and iframe@sandbox" (Andrew
         Steingruebl).  http://lists.w3.org/Archives/Public/
         public-web-security/2011Feb/0048.html>

Hodges & Steingruebl     Expires August 27, 2011               [Page 17]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

  > -----Original Message-----
  > From: [email-masked] [mailto:public-web-security-
  > [email-masked]] On Behalf Of Adam Barth
  >
  > @sandbox and CSP are very different.  The primary difference is who
  > choses the policy.  In the case of @sandbox, the embedder chooses
  > the policy. In CSP, the provider of the resource chooses the policy.

  While this is true today, I could imagine a tweak to CSP wherein CSP
  would control all contents hierarchically.  I already spoke to Brandon
  about it, but it was just a quick brainstorm.

  You could imagine revoking permissions in the frame hierarchy and not
  granting them back.  This does start to get awfully ugly, but just as
  CSP controls loading policy for itself, it could also control loading
  policy for children, right?

  Fundamentally, since the existing security model doesn't really provide
  for strict separation of parent/child (popups, 401's, top-nav) CSP and
  iframe sandbox both try to control the behavior of resources we pull
  from other parties.

  Do we think that these are both special cases of a general security
  policy (my intuition says yes) or that they have some quite orthogonal
  types of security controls that cannot be mixed into a single policy
  declaration?

  One clear problem that comes to mind is that there are policies that
  come from the "child" such as X-Frame-Options that must break the
  ordinary parent/child relationship from a precedence standpoint.

9.  Extant Policies to Coalesce?

       CORS

       XDomainRequest

       toStaticHtml

       innerSafeHtml

       X-Frame-Options

       CSP frame-ancestors

Hodges & Steingruebl     Expires August 27, 2011               [Page 18]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

10.  Example Concrete Approaches

    An overall, broad approach (from [0]):

       As for an overall policy mechanism, we observe that leveraging a
       combination of CSP [16] and ABE [19], or their employment in
       tandem, as a starting point for a multi-vendor approach may be
       reasonable.  For a near-term policy delivery mechanism, we
       advocate use of both HTTP headers and a policy file at a well-
       known location.  Leveraging DNSSEC is attractive in the
       intermediate term, i.e. as it becomes more widely deployed.

11.  Security Considerations

    Security considerations go here.

12.  References

    [[TODO1: re-code refs into xml and place in proper refs section.
    --JeffH]]

    [0] J. Hodges, A. Steingruebl, "The Need for Coherent Web Security
    Policy Framework(s)", Web 2.0 Security & Privacy, Oakland CA, 20 May
    2010. http://w2spconf.com/2010/papers/p11.pdf

    [1] Breach Security, "THE WEB HACKING INCIDENTS DATABASE 2009," Aug.
    2009. http://www.breach.com/resources/whitepapers/downloads/
    WP_TheWebHackingIncidents-2009.pdf

    [2] R. Auger, The Cross-Site Request Forgery (CSRF/XSRF) FAQ, 2007.
    http://www.cgisecurity.com/articles/csrf-faq.shtml

    [3] A. Barth, J. Caballero, and D. Song, "Secure Content Sniffing for
    Web Browsers--or How to Stop Papers from Reviewing Themselves,"
    Proceedings of the 30th IEEE Symposium on Security & Privacy,
    Oakland, CA: 2009.

    [4] D. Goodin, "Major IE8 flaw makes 'safe' sites unsafe -
    Microsoft's XSS buster busted," The Register, Nov. 2009. http://
    www.theregister.co.uk/2009/11/20/internet_explorer_security_flaw/

    [5] J. Grossman, "Clickjacking: Web pages can see and hear you," Oct.
    2008. http://jeremiahgrossman.blogspot.com/2008/10/
    clickjacking-web-pages-can-see-and-hear.html

    [6] W. Salusky, Malvertising, 2007.

Hodges & Steingruebl     Expires August 27, 2011               [Page 19]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    http://isc.sans.org/diary.html?storyid=3727

    [7] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS)
    Protocol Version 1.2," RFC5246, Internet Engineering Task Force, Aug.
    2008. http://www.ietf.org/rfc/rfc5246.txt

    [8] M. Marlinspike, SSLSTRIP, 2009.
    http://www.thoughtcrime.org/software/sslstrip/

    [9] Scope of HTTPOnly Cookies.
    http://docs.google.com/View?docid=dxxqgkd_0cvcqhsdw

    [10] E. Lawrence, IE8 Security Part VII: ClickJacking Defenses, 2009.
    http://blogs.msdn.com/ie/archive/2009/01/27/
    ie8-security-part-vii-clickjacking-defenses.aspx

    [11] J. Hodges, C. Jackson, and A. Barth, "Strict Transport
    Security," Work-in-progress, Internet-Draft, Jul. 2010.
    http://tools.ietf.org/html/draft-hodges-strict-transport-sec

    [12] A. Barth, C. Jackson, and I. Hickson, "The Web Origin Concept,"
    Internet-Draft, work in progress, Internet Engineering Task Force,
    2009. http://tools.ietf.org/html/draft-abarth-origin

    [13] E. Lawrence, IE8 Security Part VI: Beta 2 Update, 2008. http://
    blogs.msdn.com/ie/archive/2008/09/02/
    ie8-security-part-vi-beta-2-update.aspx

    [14] G. Markham, Content restrictions, 2007.
    http://www.gerv.net/security/content-restrictions/

    [15] T. Jim, N. Swamy, and M. Hicks, "BEEP: Browser-Enforced Embedded
    Policies," Proceedings of the 16th International World Wide Web
    Conference, Banff, Alberta, Canada, 2007.

    [16] B. Sterne, "Content Security Policy (CSP)," 2011. https://
    dvcs.w3.org/hg/content-security-policy/raw-file/bcf1c45f312f/
    csp-unofficial-draft-20110303.html

    [17] A.V. Kesteren, "Cross-Origin Resource Sharing (CORS)," Mar.
    2009. http://www.w3.org/TR/2009/WD-cors-20090317/

    [18] Adobe Systems, "Cross-domain policy file specification." http://
    learn.adobe.com/wiki/download/attachments/64389123/
    CrossDomain_PolicyFile_Specification.pdf?version=1

    [19] G. Maone, ABE - Application Boundaries Enforcer, 2009.
    http://noscript.net/abe/

Hodges & Steingruebl     Expires August 27, 2011               [Page 20]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    [20] G. Maone, NoScript. http://noscript.net/

    [21] G. Maone, ABE for Web Authors, 2009.
    http://noscript.net/abe/web-authors.html

    [22] Microsoft, "Event 1046 - Cross-Site Scripting Filter," MSDN
    Library, undated.
    http://msdn.microsoft.com/en-us/library/dd565647%28VS.85%29.aspx

    [23] A. Barth, C. Jackson, and W. Li, "Attacks on JavaScript Mashup
    Communication," Proceedings of the Web 2.0 Security and Privacy
    Workshop, 2009.

    [24] M. Ter Louw, P. Bisht, and V. Venkatakrishnan, "Analysis of
    Hypertext Isolation Techniques for XSS Prevention," Proceedings of
    the Web 2.0 Security and Privacy Workshop, 2008 .

    [25] A. Ozment, S.E. Schechter, and R. Dhamija, "Web Sites Should Not
    Need to Rely on Users to Secure Communications," W3C Workshop on
    Transparency and Usability of Web Authentication, 2006.

    [26] C. Reis, A. Barth, and C. Pizano, "Browser Security: Lessons
    from Google Chrome," ACM Queue, 2009, pp. 1-8.

    [27] H.J. Wang, C. Grier, A. Moshchuk, S.T. King, P. Choudhury, and
    H. Venter, "The Multi-Principal OS Construction of the Gazelle Web
    Browser," USENIX Security Symposium, 2009.

    [28] M. Zalewski, Browser Security Handbook.
    http://code.google.com/p/browsersec/

    [29] A. Stamos, D. Thiel, and J. Osborne, Living in the RIA World:
    Blurring the Line between Web and Desktop Security, BlackHat
    presentation, iSecPartners, 2008.
    https://www.isecpartners.com/files/RIA_World_BH_2008.pdf

    [30] Mary Shelley, "Frankenstein, or The Modern Prometheus," ca.
    1831. http://en.wikipedia.org/wiki/Frankenstein%27s_monster

    [31] D. Goodin, "cPanel, Netgear and Linksys susceptible to nasty
    attack - Unholy Trinity," The Register, 2009.
    http://www.theregister.co.uk/2009/08/02/unholy_trinity_csrf/

    [32] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, "DNS
    security introduction and requirements," RFC4033, Internet
    Engineering Task Force, Mar. 2005.
    http://www.ietf.org/rfc/rfc4033.txt

Hodges & Steingruebl     Expires August 27, 2011               [Page 21]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

    [33] J.H. Saltzer and M.D. Schroeder, "The Protection of Information
    in Computer Systems," Communications of the ACM, vol. 17, Jul. 1974.

    [34] I. Hickson and many others, "Comments on the Content Security
    Policy specification," discussion on mozilla.dev.security newsgroup.
    http://groups.google.com/group/mozilla.dev.security/browse_frm/
    thread/
    87ebe5cb9735d8ca?tvc=1&
    q=Comments+on+the+Content+Security+Policy+specification

    [35] S. Egelman, L.F. Cranor, and J. Hong, "You've Been Warned: An
    Empirical Study of the Effectiveness of Web Browser Phishing
    Warnings," CHI 2008, April 5 - 10, 2008, Florence, Italy, 2008.

    [36] S.E. Schechter, R. Dhamija, A. Ozment, and I. Fischer, "The
    Emperor's New Security Indicators," Proceedings of the 2007 IEEE
    Symposium on Security and Privacy.

    [37] R. Dhamija and J.D. Tygar, "The Battle Against Phishing: Dynamic
    Security Skins," Proceedings of the 2005 Symposium on Usable Privacy
    and Security (SOUPS).

    [38] J. Sobey, T. Whalen, R. Biddle, P.V. Oorschot, and A.S. Patrick,
    Browser Interfaces and Extended Validation SSL Certificates: An
    Empirical Study, Ottawa, Canada: School of Computer Science, Carleton
    University, 2009.

    [39] J. Sunshine, S. Egelman, H. Almuhimedi, N. Atri, and L.F.
    Cranor, "Crying Wolf: An Empirical Study of SSL Warning
    Effectiveness," USENIX Security Symposium, 2009.

    [40] C. Jackson and A. Barth, "ForceHTTPS: Protecting High-Security
    Web Sites from Network Attacks," Proceedings of the 17th
    International World Wide Web Conference (WWW), 2008.

    [41] Microsoft, "Packaging Wizard."
    http://msdn.microsoft.com/en-us/library/aa157732(office.10).aspx

    [42] Mozilla, "Options window."
    http://support.mozilla.com/en-US/kb/Options+window

    [43] S. Yegulalp, "Hacking Firefox: The secrets of about:config,"
    ComputerWorld, May. 2007. http://www.computerworld.com/s/article/
    9020880/Hacking_Firefox_The_secrets_of_about_config

    [44] Web Application Security Consortium, "The WASC Threat
    Classification v2.0," 2009.
    http://projects.webappsec.org/f/WASC-TC-v2_0.pdf

Hodges & Steingruebl     Expires August 27, 2011               [Page 22]

Internet-Draft            WebSec Framework Reqs                 Feb 2011

13.  Informative References

    [WebSec]   "Web HTTP Application Security Minus Authentication and
               Transport",
               <https://www.ietf.org/mailman/listinfo/websec>.

    [public-web-security]
               "[email-masked]: Improving standards and
               implementations to advance the security of the Web.",
               <http://lists.w3.org/Archives/Public/
               public-web-security/>.

Authors' Addresses

    Jeff Hodges
    PayPal
    2211 North First Street
    San Jose, California  95131
    US

    Email: [email-masked]

    Andrew Steingruebl
    PayPal
    2211 North First Street
    San Jose, California  95131
    US

    Email: [email-masked]

Hodges & Steingruebl     Expires August 27, 2011               [Page 23]