One document matched: draft-ietf-websec-framework-reqs-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC.4949 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC.5246 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC.6454 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml">
<!ENTITY RFC.6797 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6797.xml">
<!--
<!ENTITY I-D.draft-ietf-websec-strict-transport-sec PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-websec-strict-transport-sec-14.xml">
-->
<!ENTITY W3C.CR-CSP-20121115 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml4/reference.W3C.CR-CSP-20121115.xml">
]>
<!-- PROCESSING INSTRUCTIONS -->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<?rfc tocdepth="4"?>
<!--
This .xml file intended to be processed by xml2rfc
http://xml.resource.org/
source filename: draft-ietf-websec-framework-reqs-00
-->
<rfc category="std" ipr="trust200902"
docName="draft-ietf-websec-framework-reqs-00">
<front>
<title abbrev="WebSec Framework Reqs">Web Security Framework: Problem Statement and Requirements</title>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization>PayPal</organization>
<address>
<postal>
<street>2211 North First Street</street>
<city>San Jose</city>
<region>California</region>
<code>95131</code>
<country>US</country>
</postal>
<email>Jeff.Hodges@PayPal.com</email>
</address>
</author>
<!--
<author initials="" surname="" fullname="" >
<organization></organization>
<address>
<email></email>
<uri> </uri>
</address>
</author>
-->
<date month="Feb" year="2013"/>
<area>Applications</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sctn-intro">
<t>
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].
</t>
<t>
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 <xref
target="RFC6797"/>, 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).
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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].
</t>
<t>
Thus, the goal of this document is to define the requirements
for a common framework expressing security constraints on HTTP
interactions. Functionally, this framework should be general
enough that it can be used to unite the various individual
solutions above, and specific enough that it can address
vulnerabilities not addressed by current solutions, and guide
the development of future mechanisms.
</t>
<t>
Overall, such a framework would 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.
</t>
<t>
[[ The author(s) understand that many of the references to web
security issues are now somewhat dated and more recent work
has appeared in the literature. Suggestions of references to
use in superseding the ones herein are welcome; references to
web security survey papers would be good. ]]
</t>
<section anchor="sctn-wherediscuss" title="Where to Discuss This Draft">
<t>
Please disscuss this draft on the websec@ietf.org mailing
list <xref target="WebSec"/>.
</t>
</section>
</section> <!-- sctn-introduction -->
<section title="Document Conventions">
<t>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
..is a note to the reader. These are points that should be
expressly kept in mind and/or considered.
</t>
</list>
<!--
<list style="hanging" hangIndent="10">
<t hangText="Warning:">
This is how a warning is shown. These are things that can
have suboptimal downside risks if not heeded.
</t>
</list>
-->
</t>
<!--
<t>
<cref anchor="XXXn" source="JeffH">
Some of the more
major known issues are marked like this (where "n" in
"XXXn" is a number).
</cref>
</t>
-->
<t>
<cref anchor="TODOn" source="JeffH"> Things to fix (where "n"
in "TODOn" is a number). </cref>
</t>
<t>
We will also be making use of the WebSec WG issue tracker, so use of
the TODO marks will evolve accordingly.
</t>
</section> <!-- Document Conventions -->
<!--
<section anchor="sctn-terminology" title="Terminology">
<t>Terminology is defined in this section.</t>
<t><list style="hanging" hangIndent="18">
<t hangText="term">
<vspace/>
means term definition
</t></list>
</t>
</section> --> <!-- sctn-terminology -->
<section anchor="sctn-overall-constr" title="Overall Constraints">
<t>
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:
</t>
<t>
<list style="empty">
<t>
Granularity:
<list style="empty">
<t>
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. The claim is that this would occur for
various reasons stemming from the mechanisms'
complexity [34].
</t>
</list>
</t>
<t>
Configurability:
<list style="empty">
<t>
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].
</t>
</list>
</t>
<t>
Usability:
<list style="empty">
<t>
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].
</t>
</list>
</t>
</list>
In the next section we discuss various high-level requirements derived
with the guidance of the latter tension points.
</t>
</section> <!-- sctn-overall-constr -->
<section anchor="sctn-ovr-reqs" title="Overall Requirements">
<t>
<list style="numbers">
<t>
Policy conveyance:
<list style="empty">
<t>
in-band:
<list style="empty">
<t>
HTTP header(s) are already presently used to convey
policy to user agents.
However, devising
generalized, extensible HTTP security header(s) such
that the on-going "bloat" of the number of disjoint
HTTP security headers is mitigated, is a stated requirement
by various parties. Also, then there would be a
documented framework that can be leveraged as new
approaches and/or threats emerge.
</t>
<t>
It may be
reasonable to devise distinct sets of headers to
convey different classes of policies, e.g., web
application content policies
(such as <xref target="W3C.CR-CSP-20121115"/>)
versus web application
network connection policies
(such as <xref target="RFC6797"/>).
</t>
</list>
</t>
<t>
out-of-band:
<list style="empty">
<t>
An out-of-band 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 ofthe
Secure DNS (DNSSEC) [32].
</t>
</list>
</t>
</list>
<list style="hanging" hangIndent="7">
<t hangText="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
(e.g., transparent proxy servers) as the protocols
they ostensibly protect.
</t>
</list>
</t>
<t>
Granularity:
<list style="empty">
<t>
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.
</t>
<t>
Thus, to be effective for a broad array of web site and
application types, some derived requirements are:
<list>
<t>
the policy expression mechanism
should fundamentally facilitate fine-grained
control. For example, CSP <xref target="W3C.CR-CSP-20121115"/>
offers such control.
</t>
<t>
In
order to address the less complex needs of the more
simple classes of web sites, the policy expression
mechanism should have some facility for enabling
"canned policy profiles".
</t>
<t>
In addition, the configuration
facilities of various components of the web
infrastructure can be enhanced to provide an
appropriately simple veneer over the complexity.
</t>
</list>
</t>
</list>
</t>
<t>
Configurability:
<list style="empty">
<t>
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 "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.
</t>
</list>
</t>
<t>
Usability:
<list style="empty">
<t>
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
<xref target="RFC6797"/>
suggests the former so-called "hard-fail" behavior.
</t>
</list>
</t>
</list> <!-- numbers -->
</t>
<!--
<list style="hanging" hangIndent="7">
<t hangText="Note:">
this is a note.
</t>
</list>
-->
</section> <!-- overall requirements- -->
<section anchor="sctn-threats" title="Vulnerabilities, Attacks, and Threats">
<t>
This section enumerates vulnerabilities and attacks of concern,
and then illustrates plausible threats that could result from exploitation
of the vulnerabilities. The intent is to illustrate threats that
ought to be mitigated by
a web security policy framework.
</t>
<t>
The definitions of vulnerability, attack, and threat used in this document are based on
the definitions from <xref target="RFC4949"/>, and are paraphrased here as:
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="Vulnerability:">
A flaw or weakness in a system's design, implementation, or
operation and management that could be exploited.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="Attack:">
An intentional act of vulnerability exploitation, usually
characterized by one or more of: the method or technique
used, and/or the point of initiation, and/or the method of
delivery, etc. For example: active attack, passive attack,
offline attack, Cross-site Scripting (XSS) attack, SQL
injection attack, etc.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="Threat:">
Any circumstance or event with the potential to adversely
affect a system and its user(s) through unauthorized access, destruction,
disclosure, or modification of data, or denial of service.
</t></list>
</t>
<t>
See also <xref target="apdx-disc-ref-atk-threat"/>
<xref target="apdx-disc-ref-atk-threat" format="title"/>.
</t>
<section anchor="sctn-attacks" title="Attacks">
<t>
These are some of the attacks which are desirable to mitigate via a web
application security framework (see <xref target="WASC-THREAT"/> for a
more complete taxonomy of attacks):
<list style="numbers">
<t>
Cross-site-scripting (XSS) [2] <xref target="WASC-THREAT-XSS"/>
</t>
<t>
Cross-Site-Request Forgery (CSRF) <xref target="WASC-THREAT-CSRF"/>
</t>
<t>
Response Splitting <xref target="WASC-THREAT-RESP"/>
</t>
<t>
User Interface Redressing <xref target="UIRedress"/>,
aka Clickjacking <xref target="Clickjacking"/>.
</t>
<t>
Man-in-the-middle (MITM) attacks against "secure" web applications, i.e., ones
accessed using TLS/SSL <xref target="RFC5246"/>
<xref target="WASC-THREAT-TLS"/> <xref target="SSLSTRIP"/>.
</t>
<t>
<cref anchor="TODO2" source="JeffH">
more? (e.g. from [WASC-THREAT] ?)
</cref>
</t>
<!--
<t>
</t>
<t>
</t>
<t>
</t>
-->
</list>
</t>
</section> <!-- sctn-attacks -->
<section title="Threats">
<t>
Via attacks exploiting the vulnerabilities above, an attacker can..
<list style="numbers">
<t>
Obtain a victim's confidential web application
credentials (e.g., via 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Use gathered information and credentials to construct
and present a falsified persona of the victim (e.g. for
character assassination).
</t>
<!--
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
-->
</list>
There is a risk of exfiltration of otherwise confidential victim information with all
the threats listed above.
</t>
</section> <!-- sctn-threats -->
</section> <!-- sctn-attacks-and-threats -->
<section anchor="sctn-use-cases" title="Use Cases">
<t>
This section outlines various example use cases.
</t>
<t>
<list style="numbers">
<t>
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 sanitize
user-supplied content in all cases or/and content injection
vulnerabilities exist or materialize (for various reasons).
<vspace blankLines="1"/>
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.
</t>
<t>
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 insecure
HTTP; resulting in so-called "mixed content").
<vspace blankLines="1"/>
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.
</t>
<t>
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.
</t>
<t>
I'm a web application site administrator. I want to ensure
that my web app is never framed by other web apps.
</t>
<t>
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.
</t>
<t>
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.
<vspace blankLines="1"/>
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.
</t>
<t>
<cref anchor="TODO3" source="JeffH">
additional use cases to add?
</cref>
</t>
</list>
</t>
<!--
<t>
<list style="numbers">
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
</list>
</t>
-->
</section>
<section anchor="sctn-detailed-reqs" title="Detailed Functional Requirements">
<t>
Many of the below functional requirements are extracted from a
discussion on the <xref target="public-web-security"/> mailing list (in early 2011).
Particular messages are cited inline and appropriate quotes
extracted and reproduced here. Inline citations are provided
for definitions of various terms.
</t>
<t>
The overall functional requirement categories are:
<list style="numbers">
<t>
Policy mechanism scope
</t>
<t>
Policy expression syntax
</t>
<t>
Tooling
</t>
<t>
Performance
</t>
<t>
Granularity
</t>
<t>
Notifications and reporting
</t>
<t>
Facilitating Separation of Duties
</t>
<t>
Hierarchical Policy Application
</t>
<t>
Policy Delivery
</t>
<t>
Policy Conflict Resolution
</t>
</list>
<cref anchor="TODO4" source="JeffH">
additional functional requirement categories to add?
</cref>
</t>
<t>
These requirements are discussed in more detail below:
</t>
<t>
<list style="numbers">
<t>
Policy mechanism scope and extensibility:
<list style="empty">
<t>
There is a current proliferation of orthogonal atomic
mechanisms intended to solve very specific problems.
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; e.g., how to manage the gaps
and intersections between the models.
</t>
<t>
Thus the desire to have an extensible
security policy mechanism that could evolve as the web evolves,
and the threats that the web faces also evolve.
For example, an extensibility model
similar to HTML where the security protections
could grown over time.
</t>
<t>
See also <xref target="apdx-disc-ref-syntax1"/>
<xref target="apdx-disc-ref-syntax1" format="title"/>.
</t>
</list>
</t>
<t>
Policy expression syntax:
<list style="empty">
<t>
The policy expression syntax for a web security
framework should be declarative <xref target="DeclLang"/>
(and extensible, as noted above). This is for simplicity sake, as the
alternative to declarative is procedural/functional, e.g., the class
of language ECMAscript falls into.
</t>
<t>
See also <xref target="apdx-disc-ref-syntax1"/>
<xref target="apdx-disc-ref-syntax1" format="title"/>, and,
<xref target="apdx-disc-ref-syntax2"/>
<xref target="apdx-disc-ref-syntax2" format="title"/>.
</t>
</list>
</t>
<t>
Tooling:
<list style="empty">
<t>
We will need tools to (idealy) analyze a web application and
generate an initial security policy.
</t>
<t>
See also <xref target="apdx-disc-ref-tooling"/>
<xref target="apdx-disc-ref-tooling" format="title"/>.
</t>
</list>
</t>
<t>
Performance:
<list style="empty">
<t>
Minimizing performance impact is a first-order concern.
</t>
<t>
See also <xref target="apdx-disc-ref-perf"/>
<xref target="apdx-disc-ref-perf" format="title"/>.
</t>
</list>
</t>
<t>
Granularity:
<list style="empty">
<t>
For example, discriminate between:
<list style="symbols">
<t>
"inline" script in <head> versus <body>, or not.
</t>
<t>
"inline" script and "src=" loaded script.
</t>
<t>
Classes of "content", e.g. scriptable content,
passive multimedia, nested documents, etc.
</t>
</list>
</t>
<t>
See also <xref target="apdx-disc-ref-granularity"/>
<xref target="apdx-disc-ref-granularity" format="title"/>.
</t>
</list>
</t>
<t>
Notifications and Reporting:
<list style="empty">
<t>
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.
</t>
<t>
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?".
</t>
<t>
See also <xref target="apdx-disc-ref-rept"/>
<xref target="apdx-disc-ref-rept" format="title"/>.
</t>
</list>
</t>
<t>
Facilitating Separation of Duties:
<list style="empty">
<t>
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.
</t>
<t>
See also <xref target="apdx-disc-ref-sep-duty"/>
<xref target="apdx-disc-ref-sep-duty" format="title"/>.
</t>
</list>
</t>
<t>
Hierarchical Policy Application:
<list style="empty">
<t>
The notion that policy emitted by the application's
source origin is able to constrain behavior
and policies of contained origins.
</t>
<t>
See also <xref target="apdx-disc-ref-hier"/>
<xref target="apdx-disc-ref-hier" format="title"/>.
</t>
</list>
</t>
<t>
Framing Policy Hierarchy, cross-origin, granularity, auditability, roles:
<list style="empty">
<t>
<cref anchor="TODO5" source="JeffH">
Need more fully coalesce the source info from appendix into this item.
</cref>
</t>
<t>
<list style="symbols">
<t>
"Framing" is a
client-side instance notion, where webapp1's client-side instance (aka "document")
loads another webapp, "webapp2", into an HTML <IFRAME> element.
</t>
<t>
A webapp may wish to never be framed by another webapp.
</t>
<t>
webapps are denoted by "origins" <xref target="RFC6454"/>.
</t>
<t>
an origin can emit policy (i.e. from the server-side webapp component) to the
user agent (i.e. the execution environment/container for the client-side
webapp component) in at least two fashions: HTML element attributes, HTTP header fields,
ecmascript code.
See also <xref target="req-pol-devl"/>.
</t>
<t>
Policy expressed via HTML <IFRAME> elements is "fine-grained"
because the webapp can control such policies on iframe-by-iframe basis.
Policies conveyed by HTTP header fields applies "document-wide" (i.e., to the
webapp client-side instance) as a whole.
</t>
<t>
Note that either or both of the "framing" or "framed" webapp client-side instance
may be an attacker (in which case the other webapp client-side instance would be
considered a "victim" (whether or not its actual intentions are malicious or not)).
</t>
</list>
</t>
<t>
See also <xref target="apdx-disc-ref-framing"/>
<xref target="apdx-disc-ref-framing" format="title"/>.
</t>
</list>
</t>
<t anchor="req-pol-devl">
Policy Delivery:
<list style="empty">
<t>
<cref anchor="TODO6" source="JeffH">
Need more fully coalesce the source info from appendix into this item,
and blend/resolve/contrast with above item.
</cref>
</t>
<t>
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.
</t>
<t>
See also <xref target="apdx-disc-ref-pol-delv1"/>
<xref target="apdx-disc-ref-pol-delv1" format="title"/>, as well as,
<xref target="apdx-disc-ref-pol-delv2"/>
<xref target="apdx-disc-ref-pol-delv2" format="title"/>.
</t>
</list>
</t>
<t>
Policy Conflict Resolution:
<list style="empty">
<t>
<cref anchor="TODO7" source="JeffH">
Need more fully coalesce the source info from appendix into this item.
</cref>
</t>
<t>
What is the model for resolving conflicts between policies expressed
by "parent" and "child"
webapps?
</t>
<t>
Should policies conveyed via HTTP header fields (i.e., that apply webapp-wide)
be handled differently than those expressed by webapp client-side instances (e.g.,
via HTML elements and their attributes)?
</t>
<t>
See also <xref target="apdx-disc-ref-pol-confl-resln"/>
<xref target="apdx-disc-ref-pol-confl-resln" format="title"/>.
</t>
</list>
</t>
<!--
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
-->
</list>
</t>
</section>
<section anchor="sctn-extant-pols-coalesce" title="Extant Policies to Coalesce">
<t>
Presently, this section lists a grab-bag of individually-expressed web app security
policies which a more general substrate could ostensibly encompass (in order to, for
example, reduce "header bloat" and bytes-on-the-wire issues), as well as reduce functional
policy duplication/overlap.
</t>
<t>
<list>
<t>
CORS
</t>
<t>
XDomainRequest
</t>
<t>
toStaticHtml
</t>
<t>
innerSafeHtml
</t>
<t>
X-Frame-Options
</t>
<t>
CSP frame-ancestors
</t>
<t>
more?
</t>
<!--
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
-->
</list>
</t>
</section>
<section anchor="sctn-extant-facilities" title="Example Concrete Approaches">
<t>
An overall, broad approach (from [0]):
</t>
<t>
<list style="empty">
<t>
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.
</t>
</list>
</t>
</section>
<section anchor="sctn-sec-cons" title="Security Considerations">
<!-- <t>This section is non-normative.</t> -->
<t>
Security considerations go here.
</t>
</section> <!-- h2 sctn-sec-cons -->
<!--
<section anchor="sec-iana-consid" title="IANA Considerations">
<t>
Below is the Internet Assigned Numbers Authority (IANA)
[...fill in here...]
information per [RFC3864] --> <!-- <xref target="RFC3864" /> -->
<!--
</t>
<figure>
<artwork>
[IANA template here as appropriate]
</artwork>
</figure>
</section> --> <!-- h2 sec-iana-consid -->
<!--
<section anchor="sctn-design-decision-faq" title="Design Decision Notes">
<t>This appendix is non-normative.</t> -->
<!--
<t>This appendix documents various design decisions.</t>
<t>
<list style="numbers">
<t>
design decisions here.
</t>
</list>
</t>
</section> --> <!-- design-decision-faq -->
<section title="References">
<t>
<cref anchor="TODO1" source="JeffH">
re-code refs into xml and place in proper refs section.
</cref>
</t>
<t>
[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
</t>
<t>
[1] Breach Security, "THE WEB HACKING INCIDENTS DATABASE 2009," Aug. 2009.
http://www.breach.com/resources/whitepapers/downloads/WP_TheWebHackingIncidents-2009.pdf
</t>
<t>
[2] R. Auger, The Cross-Site Request Forgery (CSRF/XSRF) FAQ, 2007.
http://www.cgisecurity.com/articles/csrf-faq.shtml
</t>
<t>
[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.
</t>
<t>
[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/
</t>
<t>
[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
</t>
<t>
[6] W. Salusky, Malvertising, 2007.
http://isc.sans.org/diary.html?storyid=3727
</t>
<t>
[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
</t>
<t>
[8] M. Marlinspike, SSLSTRIP, 2009.
http://www.thoughtcrime.org/software/sslstrip/
</t>
<t>
[9] Scope of HTTPOnly Cookies.
http://docs.google.com/View?docid=dxxqgkd_0cvcqhsdw
</t>
<t>
[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
</t>
<t>
[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
</t>
<t>
[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
</t>
<t>
[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
</t>
<t>
[14] G. Markham, Content restrictions, 2007.
http://www.gerv.net/security/content-restrictions/
</t>
<t>
[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.
</t>
<t>
[16] B. Sterne, "Content Security Policy (CSP)," 2011.
https://dvcs.w3.org/hg/content-security-policy/raw-file/bcf1c45f312f/csp-unofficial-draft-20110303.html
</t>
<t>
[17] A.V. Kesteren, "Cross-Origin Resource Sharing (CORS)," Mar. 2009.
http://www.w3.org/TR/2009/WD-cors-20090317/
</t>
<t>
[18] Adobe Systems, "Cross-domain policy file specification."
http://learn.adobe.com/wiki/download/attachments/64389123/CrossDomain_PolicyFile_Specification.pdf?version=1
</t>
<t>
[19] G. Maone, ABE - Application Boundaries Enforcer, 2009.
http://noscript.net/abe/
</t>
<t>
[20] G. Maone, NoScript.
http://noscript.net/
</t>
<t>
[21] G. Maone, ABE for Web Authors, 2009.
http://noscript.net/abe/web-authors.html
</t>
<t>
[22] Microsoft, "Event 1046 - Cross-Site Scripting Filter," MSDN Library,
undated.
http://msdn.microsoft.com/en-us/library/dd565647%28VS.85%29.aspx
</t>
<t>
[23] A. Barth, C. Jackson, and W. Li, "Attacks on JavaScript Mashup
Communication," Proceedings of the Web 2.0 Security and Privacy Workshop, 2009.
</t>
<t>
[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 .
</t>
<t>
[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.
</t>
<t>
[26] C. Reis, A. Barth, and C. Pizano, "Browser Security: Lessons from Google
Chrome," ACM Queue, 2009, pp. 1-8.
</t>
<t>
[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.
</t>
<t>
[28] M. Zalewski, Browser Security Handbook.
http://code.google.com/p/browsersec/
</t>
<t>
[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
</t>
<t>
[30] Mary Shelley, "Frankenstein, or The Modern Prometheus," ca. 1831.
http://en.wikipedia.org/wiki/Frankenstein%27s_monster
</t>
<t>
[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/
</t>
<t>
[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
</t>
<t>
[33] J.H. Saltzer and M.D. Schroeder, "The Protection of Information in
Computer Systems," Communications of the ACM, vol. 17, Jul. 1974.
</t>
<t>
[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
</t>
<t>
[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.
</t>
<t>
[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.
</t>
<t>
[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).
</t>
<t>
[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.
</t>
<t>
[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.
</t>
<t>
[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.
</t>
<t>
[41] Microsoft, "Packaging Wizard."
http://msdn.microsoft.com/en-us/library/aa157732(office.10).aspx
</t>
<t>
[42] Mozilla, "Options window."
http://support.mozilla.com/en-US/kb/Options+window
</t>
<t>
[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
</t>
<!--
<t>
[44] Web Application Security Consortium, "The WASC Threat Classification v2.0," 2009.
http://projects.webappsec.org/f/WASC-TC-v2_0.pdf
</t>
-->
<!-- <xref target=""/> -->
<!--
<reference anchor="" target="URI">
<front>
<title></title>
<author/>
</front>
</reference>
-->
</section> <!-- references (for now) -->
<!--
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors thank Michael Barrett, Sid Stamm, Maciej
Stachowiak, Andy Steingrubl, Brandon Sterne, Daniel Veditz for
their review and contributions. </t>
<t>Special thanks to ...</t>
</section>
-->
<!-- h2 acknowledgments -->
</middle>
<back>
<references title="Informative References">
<!-- <xref target=""/> -->
<!--
<reference anchor="" target="URI">
<front>
<title></title>
<author/>
</front>
</reference>
-->
<!-- <xref target="DeclLang"/> -->
<reference anchor="DeclLang"
target="http://www.encyclopedia.com/doc/1O11-declarativelanguages.html">
<front>
<title>declarative languages</title>
<author fullname="John Daintith">
<organization></organization>
</author>
<date day="" month="" year="2004" />
</front>
<seriesInfo name="A Dictionary of Computing" value="Encyclopedia.com"/>
</reference>
<!-- <xref target="WASC-THREAT"/> -->
<reference anchor="WASC-THREAT" target="http://projects.webappsec.org/f/WASC-TC-v2_0.pdf">
<front>
<title>The WASC Threat Classification v2.0</title>
<author>
<organization>Web Application Security Consortium</organization>
</author>
<date month="January" year="2010" />
</front>
</reference>
<!-- <xref target="WASC-THREAT-XSS"/> -->
<reference anchor="WASC-THREAT-XSS"
target="http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting">
<front>
<title>Cross Site Scripting</title>
<author>
<organization>Web Application Security Consortium</organization>
</author>
<date month="January" year="2010" />
</front>
<seriesInfo name="The WASC Threat Classification v2.0" value="Reference ID: WASC-8" />
</reference>
<!-- <xref target="WASC-THREAT-TLS"/> -->
<reference anchor="WASC-THREAT-TLS"
target="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">
<front>
<title>Insufficient Transport Layer Protection</title>
<author>
<organization>Web Application Security Consortium</organization>
</author>
<date month="January" year="2010" />
</front>
<seriesInfo name="The WASC Threat Classification v2.0" value="Reference ID: WASC-04"/>
</reference>
<!-- <xref target="WASC-THREAT-CSRF"/> -->
<reference anchor="WASC-THREAT-CSRF"
target="http://projects.webappsec.org/w/page/13246919/Cross%20Site%20Request%20Forgery">
<front>
<title>Cross Site Request Forgery</title>
<author>
<organization>Web Application Security Consortium</organization>
</author>
<date month="January" year="2010" />
</front>
<seriesInfo name="The WASC Threat Classification v2.0" value="Reference ID: WASC-9"/>
</reference>
<!-- <xref target="WASC-THREAT-RESP"/> -->
<reference anchor="WASC-THREAT-RESP"
target="http://projects.webappsec.org/w/page/13246931/HTTP%20Response%20Splitting">
<front>
<title>HTTP Response Splitting</title>
<author>
<organization>Web Application Security Consortium</organization>
</author>
<date month="January" year="2010" />
</front>
<seriesInfo name="The WASC Threat Classification v2.0" value="Reference ID: WASC-25"/>
</reference>
<!-- <xref target="Clickjacking"/> -->
<reference anchor="Clickjacking" target="http://www.sectheory.com/clickjacking.htm">
<front>
<title>Clickjacking</title>
<author fullname="Robert Hanson">
<organization></organization>
</author>
<author fullname="Jeremiah Grossman">
<organization></organization>
</author>
<date day="12" month="Sep" year="2008" />
</front>
</reference>
<!-- <xref target="UIRedress"/> -->
<reference anchor="UIRedress" target="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-September/016284.html">
<front>
<title>Dealing with UI redress vulnerabilities inherent to the current web</title>
<author fullname="Michal Zalewski">
<organization></organization>
</author>
<date day="25" month="Sep" year="2008" />
</front>
</reference>
<!-- <xref target="W3C.CR-CSP-20121115"/> -->
&W3C.CR-CSP-20121115;
<!-- <xref target="SSLSTRIP"/> -->
<reference anchor="SSLSTRIP" target="http://www.thoughtcrime.org/software/sslstrip/">
<front>
<title>SSLSTRIP</title>
<author initials="M" surname="Marlinspike">
<organization></organization>
</author>
<date day="" month="" year="2009" />
</front>
</reference>
<!-- <xref target=""/> -->
<!--
<reference anchor="" target="">
<front>
<title></title>
<author>
<organization></organization>
</author>
<date day="" month="" year="" />
</front>
<seriesInfo name="" value="" />
</reference>
-->
<!-- <xref target="WebSec"/> -->
<reference anchor="WebSec" target="https://www.ietf.org/mailman/listinfo/websec">
<front>
<title>Web HTTP Application Security Minus Authentication and Transport</title>
<author/>
</front>
</reference>
<!-- <xref target="public-web-security"/> -->
<reference anchor="public-web-security" target="http://lists.w3.org/Archives/Public/public-web-security/">
<front>
<title>
public-web-security@w3.org: Improving standards and
implementations to advance the security of the Web.
</title>
<author/>
</front>
</reference>
&RFC.4949; <!-- <xref target="RFC4939"/> -->
&RFC.5246; <!-- <xref target="RFC5246"/> -->
&RFC.6454; <!-- <xref target="RFC6454"/> -->
&RFC.6797; <!-- <xref target="RFC6797"/> -->
</references>
<section anchor="acknowledgments" title="Acknowledgments">
<t>
Text and ideas were prototypically incorporated from various mailing list discussions,
notably the ones on the <xref target="public-web-security"/> mailing list in early
2011, into this document. The authors wish to acknowledge and thank these individuals in
particular for their tacit contributions to this document:
Lucas Adamski,
Adam Barth,
gaz Heyes,
Andrew Steingruebl,
Brandon Sterne,
Daniel Veditz,
John Wilander.
</t>
</section>
<section anchor="apdx-discussion-refs" title="Discussion References">
<section anchor="apdx-disc-ref-atk-threat" title="Source: Attacks and Threats">
<t>
In terms of defining threats in contrast to attacks:
<vspace blankLines="1"/>
<eref target=""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" />
<list style="empty">
<t>
"... There's a fundamental question about whether we
should be looking at these problems from an attack vs
threat standpoint. An attack is [exploitation of, ed.] 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). ..."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-syntax1" title="Source: Policy Expression Syntax [1]">
<t>
In terms of policy expression syntax and extensibility,
Lucas Adamski supplied this:
<eref target=""Re: XSS mitigation in browsers" (Lucas Adamski).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0066.html" />
<list style="empty">
<t>
"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."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-syntax2" title="Source: Policy Expression Syntax [2]">
<t>
In terms of policy expression syntax and extensibility,
Adam Barth supplied this:
<eref target=""Re: Scope and complexity (was Re: More on XSS mitigation)" (Adam Barth).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0108.html" />
<list style="empty">
<t>
"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.
</t>
<t>
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.
</t>
<t>
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."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-tooling" title="Source: Tooling">
<t>
In terms of tooling needs,
John Wilander supplied this:
<eref target=""Re: More on XSS mitigation" (John Wilander).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0082.html" />
<list style="empty">
<t>
"*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! "
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-perf" title="Source: Performance">
<t>
In terms of performance,
John Wilander supplied this:
<eref target=""Re: More on XSS mitigation" (John Wilander).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0082.html" />
<list style="empty">
<t>
"*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."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-granularity" title="Source: Granularity">
<t>
In terms of granularity,
Daniel Veditz supplied this:
<eref target=""Proposal to move the debate forward" (Daniel Veditz).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0122.html" />
<list style="empty">
<t>
"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."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-rept" title="Source: Notifications and Reporting">
<t>
In terms of notifications and reporting,
Brandon Sterne supplied this:
<eref target=""[Content Security Policy] Proposal to move the debate forward" (Brandon Sterne).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0118.html" />
<figure>
<artwork>
<![CDATA[
"...
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
..."
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="apdx-disc-ref-sep-duty" title="Source: Facilitating Separation of Duties">
<t>
In terms of facilitating separation of duties,
Andrew Steingruebl supplied this:
<eref target=""RE: Content Security Policy and iframe@sandbox" (Andrew Steingruebl).
http://lists.w3.org/Archives/Public/public-web-security/2011Feb/0050.html" />
<list style="empty">
<t>
"... 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. ..."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-hier" title="Source: Hierarchical Policy Application">
<t>
In terms of hierarchical policy application,
Andrew Steingruebl supplied this:
<eref target=""RE: Content Security Policy and iframe@sandbox" (Andrew Steingruebl).
http://lists.w3.org/Archives/Public/public-web-security/2011Feb/0048.html" />
<list style="empty">
<t>
"... 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.
</t>
<t>
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, ..."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-framing" title="Source: Framing Policy Hierarchy, cross-origin, granularity">
<t>
In terms of framing policy hierarchy, cross-origin, granularity,
Andy Steingruebl and Adam Barth supplied this:
<list style="empty">
<t>
<eref target=""Re: Content Security Policy and iframe@sandbox")
(Andy Steingruebl, Adam Barth)
http://lists.w3.org/Archives/Public/public-web-security/2011Feb/0051.html" />
</t>
</list>
<figure>
<artwork>
<![CDATA[
On Sat, Feb 12, 2011 at 9:01 PM, Steingruebl, Andy
<asteingruebl@paypal-inc.com> wrote:
>> -----Original Message-----
>> From: Adam Barth [mailto:w3c@adambarth.com]
>
>> 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.
>
> 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
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="apdx-disc-ref-pol-delv1" title="Source: Policy Delivery [1]">
<t>
In terms of policy delivery,
Brandon Sterne supplied this:
<eref target=""[Content Security Policy] Proposal to move the debate forward" (Brandon Sterne).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0118.html" />
<figure>
<artwork>
<![CDATA[
"...
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
..."
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="apdx-disc-ref-pol-delv2" title="Source: Policy Delivery [2]">
<t>
In terms of defining policy delivery,
gaz Heyes supplied this:
<eref target=""Re: [Content Security Policy] Proposal to move the debate forward" (gaz Heyes).
http://lists.w3.org/Archives/Public/public-web-security/2011Jan/0148.html" />
<list style="empty">
<t>
"...
<vspace blankLines="0"/>
a) Policy shouldn't be defined in a http header it's too messy and what
happens when there's a mistake?
</t>
<t>
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.
</t>
<t>
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.
<vspace blankLines="0"/>
..."
</t>
</list>
</t>
</section>
<section anchor="apdx-disc-ref-pol-confl-resln" title="Source: Policy Conflict Resolution">
<t>
In terms of defining policy conflict resolution,
Andrew Steingruebl supplied this:
<eref target=""RE: Content Security Policy and iframe@sandbox" (Andrew Steingruebl).
http://lists.w3.org/Archives/Public/public-web-security/2011Feb/0048.html" />
<figure>
<artwork>
<![CDATA[
> -----Original Message-----
> From: public-web-security-request@w3.org [mailto:public-web-security-
> request@w3.org] 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.
]]>
</artwork>
</figure>
</t>
</section>
<!--
<section anchor="apdx-disc-ref-foo" title="Source: title">
<t>
In terms of defining foo,
name supplied this:
</t>
</section>
-->
</section>
<!--
<section title="Change Log">
<t>
<list>
<t>
Changes from -01 to -02:
<list style="numbers">
<t>
updated abstract such that means for expressing HSTS Policy other
than via HSTS header field is noted.
</t>
<t>
Changed spec title to "HTTP Strict Transport Security
(HSTS)" from "Strict Transport Security". Updated use
of "STS" acronym throughout spec to HSTS (except for
when specifically discussing syntax of
Strict-Transport-Security HTTP Response Header field),
updated "Terminology" appropriately.
</t>
<t>
Updated the discussion of "Passive Network Attackers" to
be more precise and offered references.
</t>
<t>
Removed para on nomative/non-normative from "Conformance Criteria"
pending polishing said section to IETF RFC norms.
</t>
<t>
Added examples subsection to "Syntax" section.
</t>
<t>
Added OWS to maxAge production in Strict-Transport-Security ABNF.
</t>
<t>
Cleaned up explanation in the "Note:"
in the "HTTP-over-Secure-Transport Request Type" section,
folded 3d para into "Note:",
added conformance clauses to the latter.
</t>
<t>
Added exaplanatory "Note:" and reference to
"HTTP Request Type" section. Added "XXX1"
issue.
</t>
<t>
Added conformance clause to "URI Loading".
</t>
<t>
Moved "Notes for STS Server implementors:"
from "UA Implementation dvice " to
"HSTS Policy expiration time
considerations:" in "Server Implementation
Advice", and also noted another option.
</t>
<t>
Added cautionary "Note:" to "Ability to
delete UA's cached HSTS Policy on a per HSTS Server
basis".
</t>
<t>
Added some informative references.
</t>
<t>
Various minor editorial fixes.
</t>
</list>
</t>
<t>
Changes from -00 to -01:
<list style="numbers">
<t>
Added reference to HASMAT mailing list and request
that this spec be discussed there.
</t>
</list>
</t>
</list>
</t>
</section>
--> <!-- Change Log -->
</back>
</rfc>
<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
<!--
Local Variables:
mode: xml
indent-tabs-mode:nil
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->
| PAFTECH AB 2003-2026 | 2026-04-24 01:05:59 |