draft-ietf-websec-origin-01.txt   draft-ietf-websec-origin-02.txt 
websec A. Barth websec A. Barth
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track June 21, 2011 Intended status: Standards Track June 24, 2011
Expires: December 23, 2011 Expires: December 26, 2011
The Web Origin Concept The Web Origin Concept
draft-ietf-websec-origin-01 draft-ietf-websec-origin-02
Abstract Abstract
This document defines the concept of an "origin", which is often used This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically, as the scope of authority or privilege by user agents. Typically,
user agents isolate content retrieved from different origins to user agents isolate content retrieved from different origins to
prevent malicious web site operators from interfering with the prevent malicious web site operators from interfering with the
operation of benign web sites. In addition to outlining the operation of benign web sites. In addition to outlining the
principles that underly the origin concept, this document defines how principles that underly the origin concept, this document defines how
to determine the origin of a URI, how to serialize an origin into a to determine the origin of a URI, how to serialize an origin into a
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2011. This Internet-Draft will expire on December 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 3, line 33
3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 13 4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 13
5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 14 5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 14
6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 15 6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 15
6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15 6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15
6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15 6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15
7. The HTTP Origin header . . . . . . . . . . . . . . . . . . . . 17 7. The HTTP Origin header . . . . . . . . . . . . . . . . . . . . 17
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17 7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19
11. Implementation Considerations . . . . . . . . . . . . . . . . 22 8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20
11.1. IDNA dependency and migration . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10. Implementation Considerations . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.1. IDNA dependency and migration . . . . . . . . . . . . . . 22
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
User agents interact with content created by a large number of User agents interact with content created by a large number of
authors. Although many of those authors are well-meaning, some authors. Although many of those authors are well-meaning, some
authors might be malicious. To the extent that user agents undertake authors might be malicious. To the extent that user agents undertake
actions based on content they process, user agent implementors might actions based on content they process, user agent implementors might
wish to restrict the ability of malicious authors to disrupt the wish to restrict the ability of malicious authors to disrupt the
confidentiality or integrity of other content or servers. confidentiality or integrity of other content or servers.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
2.3. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
1.3). 1.3).
A globally unique identifier is a value which is different from all A globally unique identifier is a value which is different from all
other previously existing values. For example, a sufficiently long other previously existing values. For example, a sufficiently long
random string is likely to be a globally unique identifier. random string is likely to be a globally unique identifier.
A idna-canonicalization host name is the string generated by the A idna-canonicalized host name is the string generated by the
following algorithm: following algorithm:
1. Convert the host name to a sequence of NR-LDH labels (see Section 1. Convert the host name to a sequence of NR-LDH labels (see Section
2.3.2.2 of [RFC5890]) and/or A-labels according to the 2.3.2.2 of [RFC5890]) and/or A-labels according to the
appropriate IDNA specification [RFC5891] or [RFC3490] (see appropriate IDNA specification [RFC5891] or [RFC3490] (see
Section 11.1 of this specification) Section 10.1 of this specification)
2. Convert the labels to lower case. 2. Convert the labels to lower case.
3. Concatenate the labels, separating each label from the next with 3. Concatenate the labels, separating each label from the next with
a %x2E (".") character. a %x2E (".") character.
3. Principles of the Same-Origin Policy 3. Principles of the Same-Origin Policy
Many user agents undertake actions on behalf of remote parties. For Many user agents undertake actions on behalf of remote parties. For
example, HTTP user agents follow redirects, which are instructions example, HTTP user agents follow redirects, which are instructions
skipping to change at page 8, line 19 skipping to change at page 8, line 19
example, if both TLS and non-TLS protected resources used the "http" example, if both TLS and non-TLS protected resources used the "http"
URI scheme (as in [RFC2817]), a document would be unable to specify URI scheme (as in [RFC2817]), a document would be unable to specify
that it wished to retrieve a script only over TLS. By using the that it wished to retrieve a script only over TLS. By using the
"https" URI scheme, documents are able to indicate that they wish to "https" URI scheme, documents are able to indicate that they wish to
interact with resources that are protected from active network interact with resources that are protected from active network
attackers. attackers.
3.2. Origin 3.2. Origin
In principle, user agents could treat every URI as a separate In principle, user agents could treat every URI as a separate
protection domain and require explicit content for content retrieved protection domain and require explicit consent for content retrieved
from one URI to interact with another URI. Unfortunately, this from one URI to interact with another URI. Unfortunately, this
design is cumbersome for developers because web applications often design is cumbersome for developers because web applications often
consist of a number of resources acting in concert. consist of a number of resources acting in concert.
Instead, user agents group URIs together into protection domains Instead, user agents group URIs together into protection domains
called "origins". Roughly speaking, two URIs are part of the same called "origins". Roughly speaking, two URIs are part of the same
origin (i.e., represent the same principal) if they have the same origin (i.e., represent the same principal) if they have the same
scheme, host, and port. (See Section 4 for full details.) scheme, host, and port. (See Section 4 for full details.)
Q: Why not just use the host? Q: Why not just use the host?
skipping to change at page 10, line 29 skipping to change at page 10, line 29
grant authority to resources irrespective of media type. Many web grant authority to resources irrespective of media type. Many web
applications serve untrusted content with restricted media types. A applications serve untrusted content with restricted media types. A
new web platform feature that grants authority to these pieces of new web platform feature that grants authority to these pieces of
content risks introducing vulnerabilities into existing applications. content risks introducing vulnerabilities into existing applications.
Instead, prefer to grant authority to media types that already Instead, prefer to grant authority to media types that already
possess the origin's full authority or to new media types designed possess the origin's full authority or to new media types designed
specifically to carry the new authority. specifically to carry the new authority.
In order to remain compatible with servers that supply incorrect In order to remain compatible with servers that supply incorrect
media types, some user agents employ "content sniffing" and treat media types, some user agents employ "content sniffing" and treat
content as if had a different media type than the media type supplied content as if it had a different media type than the media type
by the server. If not done carefully, content sniffing can lead to supplied by the server. If not done carefully, content sniffing can
security vulnerabilities because user agents might grant low- lead to security vulnerabilities because user agents might grant low-
authority media types, such as images, the privileges of high- authority media types, such as images, the privileges of high-
authority media types, such as HTML documents [SNIFF]. authority media types, such as HTML documents [SNIFF].
3.4. Policy 3.4. Policy
Generally speaking, user agents isolate different origins and permit Generally speaking, user agents isolate different origins and permit
controlled communication between origins. The details of how user controlled communication between origins. The details of how user
agents provide isolation and communication vary depending on several agents provide isolation and communication vary depending on several
factors. factors.
skipping to change at page 12, line 12 skipping to change at page 12, line 12
from another resource in the same origin. However, withholding from another resource in the same origin. However, withholding
privileges in this way is ineffective because the resource without privileges in this way is ineffective because the resource without
the privilege can usually obtain the privilege anyway because user the privilege can usually obtain the privilege anyway because user
agents do not isolate resources within an origin. Instead, agents do not isolate resources within an origin. Instead,
privileges should be granted or withheld from origins as a whole privileges should be granted or withheld from origins as a whole
(rather than discriminating between individual resources within an (rather than discriminating between individual resources within an
origin) [BOFGO]. origin) [BOFGO].
3.5. Conclusion 3.5. Conclusion
The same-origin policy uses URIs to designates trust relationships. The same-origin policy uses URIs to designate trust relationships.
URIs are grouped together into origins, which represent protection URIs are grouped together into origins, which represent protection
domains. Some resources in an origin (e.g., active content) are domains. Some resources in an origin (e.g., active content) are
granted the origin's full authority, whereas other resources in the granted the origin's full authority, whereas other resources in the
origin (e.g., passive content) are not granted the origin's origin (e.g., passive content) are not granted the origin's
authority. Content that carries its origin's authority is granted authority. Content that carries its origin's authority is granted
access to objects and network resources within its own origin. This access to objects and network resources within its own origin. This
content is also granted limited access to objects and network content is also granted limited access to objects and network
resources of other origins, but these cross-origin privileges must be resources of other origins, but these cross-origin privileges must be
designed carefully to avoid security vulnerabilities. designed carefully to avoid security vulnerabilities.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
Otherwise: Otherwise:
2. Let uri-port be the port component of the URI. 2. Let uri-port be the port component of the URI.
7. Return the triple (uri-scheme, uri-host, uri-port). 7. Return the triple (uri-scheme, uri-host, uri-port).
Implementations MAY define other types of origins in addition to the Implementations MAY define other types of origins in addition to the
scheme/host/port triple type defined above. For example, an scheme/host/port triple type defined above. For example, an
implementation might define an origin based on a public key or an implementation might define an origin based on a public key or an
implementation might append addition "sandbox" bits to a scheme/host/ implementation might append additional "sandbox" bits to a scheme/
port triple. host/port triple.
5. Comparing Origins 5. Comparing Origins
To origins are "the same" if, and only if, they are identical. In To origins are "the same" if, and only if, they are identical. In
particular: particular:
o If the two origins are scheme/host/port triple, the two origins o If the two origins are scheme/host/port triples, the two origins
are the same if, and only if, they have identical schemes, hosts, are the same if, and only if, they have identical schemes, hosts,
and ports. and ports.
o An origin that is globally unique identifier cannot be the same as o An origin that is a globally unique identifier cannot be the same
an origin that is a scheme/host/port triple. as an origin that is a scheme/host/port triple.
o Two origins that are globally unique identifiers cannot be the o Two origins that are globally unique identifiers cannot be the
same if they were created at different times, even if they were same if they were created at different times, even if they were
created for the same URI. created for the same URI.
Two URIs are the same-origin if their origins are the same. Two URIs are the same-origin if their origins are the same.
NOTE: A URI is not necessarily same-origin with itself. For NOTE: A URI is not necessarily same-origin with itself. For
example, a data URI is not same-origin with itself because data example, a data URI is not same-origin with itself because data
URIs do not use a server-based naming authority and therefore have URIs do not use a server-based naming authority and therefore have
skipping to change at page 15, line 27 skipping to change at page 15, line 27
null null
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps. and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple. 2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result. 3. Append the string "://" to result.
4. Append the IDNA ToUnicode algorithm [RFC5891] to each component 4. Apply the IDNA ToUnicode algorithm [RFC5891] to each component of
of the host part of the origin triple, and append the results of the host part of the origin triple, and append the results of
each component, in the same order, separated by U+002E FULL STOP each component, in the same order, separated by U+002E FULL STOP
code points (".") to result. code points (".") to result.
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code point (":") and the given port, in 1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result. base ten, to result.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
following requirements: following requirements:
o Each of the serialized-origin productions in the grammar MUST be o Each of the serialized-origin productions in the grammar MUST be
the ascii-serialization of an origin. the ascii-serialization of an origin.
o No two consecutive serialized-origin productions in the grammar o No two consecutive serialized-origin productions in the grammar
can be identical. In particular, if the user agent would generate can be identical. In particular, if the user agent would generate
two consecutive serialized-origins, the user agent MUST NOT two consecutive serialized-origins, the user agent MUST NOT
generate the second one. generate the second one.
8. Privacy Considerations 8. Security Considerations
[TODO: Privacy considerations.] The same-origin policy is one of the cornerstones of security for
many user agents, including web browsers. Historically, some user
agents tried other security models, including taint tracking and
exfiltration prevention, but those model proved difficult to
implement at the time (although there has been recent interest in
reviving some of these ideas).
9. Security Considerations Evaluating the security of the same-origin policy is difficult
because the origin concept itself plays such a central role in the
security landscape. The notional origin itself is just a unit of
isolation, imperfect as are most one-size-fits-all notions. That
said, there are some systemic weaknesses, discussed below.
[TODO: Security considerations.] 8.1. Reliance on DNS
10. IANA Considerations In practice, the same-origin policy relies upon the Domain Name
System (DNS) for security because many commonly used URI schemes,
such as http, use DNS-based naming authorities. If the DNS is
partially or fully compromised, the same-origin policy might fail to
provide the security properties required by applications.
[TODO: Register the Origin header.] Some URI schemes, such as https, are more resistant to DNS compromise
because user agents employ other mechanisms, such as certificates, to
verify the source of content retrieved from these URIs. Other URI
schemes, such as the chrome-extension URI scheme, use a public-key-
based naming authority and are fully secure against DNS compromise.
11. Implementation Considerations That the web origin concept isolates content retrieved from different
URI schemes is essential to containing the effects of DNS compromise.
11.1. IDNA dependency and migration 8.2. Divergent Units of Isolation
Over time, a number of technologies have converged on the web origin
concept as a convenient unit of isolation. However, many
technologies in use today, such as cookies [RFC6265], pre-date the
modern web origin concept. These technologies often have different
isolation units, leading to vulnerabilities.
One alternative is to use only the "registry-controlled" domain
rather than the fully qualified domain name as the unit of isolation
(e.g., "example.com" instead of "www.example.com"). This practice is
problematic for a number of reasons, and is NOT RECOMMENDED:
1. The notion of a "registry-controlled" domain a function of human
practice surrounding the DNS rather than a property of the DNS
itself. For example, many municipalities in Japan run public
registries quite deep in the DNS hierarchy. There are widely
used "public suffix lists", but these lists are difficult to keep
up to date and vary between implementations.
2. This practice is incompatible with URIs schemes that do not use a
DNS-based naming authority. For example, if a given URI scheme
uses public keys as naming authorities, the notion of a
"registry-controlled" public key is somewhat incoherent. Worse,
some URI schemes, such as nntp, used dotted delegation in the
opposite direction from DNS (e.g., alt.usenet.kooks) and others
use the DNS, but present the labels in the reverse of the usual
order (e.g., com.example.www).
At best, using registry-controlled domains is URI-scheme- and
implementation-specific. At worse, differences between URI schemes
and implementations can lead to vulnerabilities.
8.3. Ambient Authority
When using the same-origin policy, user agents grant authority to
content based on the URI from which the user agent retrieved the
content rather than based on the objects which the content is able to
designate. This disentangling of designation from authority is an
example of ambient authority and can lead to vulnerabilities.
Consider, for example, cross-site scripting in HTML documents. If an
attacker can inject script content into an HTML document, those
scripts will run with the authority of the document's origin, perhaps
allowing the script access to sensitive information, such as the
user's medical records. If, however, the script's authority were
limited to those objects that the script could designate, the
attacker would not gain any advantage by injecting the script into an
HTML document hosted by a third party.
9. IANA Considerations
The permanent message header field registry (see [RFC3864]) should be
updated with the following registrations:
9.1. Origin
Header field name: Origin
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: this specification (Section 7)
10. Implementation Considerations
10.1. IDNA dependency and migration
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not
backwards-compatible. For this reason, there will be a transition backwards-compatible. For this reason, there will be a transition
period (possibly of a number of years). User agents SHOULD implement period (possibly of a number of years). User agents SHOULD implement
IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46 IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46
<http://unicode.org/reports/tr46/>] in order to facilitate a smoother <http://unicode.org/reports/tr46/>] in order to facilitate a smoother
IDNA transition. If a user agent does not implement IDNA2008, the IDNA transition. If a user agent does not implement IDNA2008, the
user agent MUST implement IDNA2003 [RFC3490]. user agent MUST implement IDNA2003 [RFC3490].
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
See Section 11.1 for an explanation why the normative See Section 10.1 for an explanation why the normative
reference to an obsoleted specification is needed. reference to an obsoleted specification is needed.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
12.2. Informative References 11.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2817] "FIXME: RFC2817". [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[SNIFF] "FIXME: Media Type Sniffing".
[HTML] "FIXME: HTML5". [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[WEBSOCKETS] [WEBSOCKETS]
"FIXME: WebSockets". Fette, I., "The WebSocket protocol", <http://
tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol>.
[CORS] "FIXME: Cross-Origin Resource Sharing". [SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing",
<http://tools.ietf.org/html/draft-ietf-websec-mime-sniff>.
[CSRF] "FIXME: Robust Defenses to Cross-Site Request Forgery". [HTML] Hickson, I., "HTML5: A vocabulary and associated APIs for
HTML and XHTML", <http://www.w3.org/TR/html5/>.
[BOFGO] "FIXME: Beware of Finer-Grained Origins". [CORS] van Kesteren, A., "Cross-Origin Resource Sharing",
<http://www.w3.org/TR/cors/>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery", 2008,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained
Origins", 2008,
<http://w2spconf.com/2008/papers/s2p1.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Author's Address Author's Address
Adam Barth Adam Barth
Google, Inc. Google, Inc.
Email: ietf@adambarth.com Email: ietf@adambarth.com
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 32 change blocks. 
48 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/