| Network Working Group | Y. Nir, Ed. |
| Internet-Draft | Check Point |
| Updates: 6454 (if approved) | March 06, 2012 |
| Intended status: Standards Track | |
| Expires: September 05, 2012 |
A More Granular Web Origin Concept
draft-nir-websec-extended-origin-01
This document defines an HTTP header that allows the partitioning of a single origin (as defined in RFC 6454) into multiple origins, so that the same origin policy applies among them.
The header introduced in this document allows a portal to specify that resources that appear to be from the same origin should, in fact, be treated as though they are from different origins, by extending the 3-tuple of the origin to a 4-tuple. A compliant user agent is expected to apply the same-origin policy according to the 4-tuple rather than the 3-tuple.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 05, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Reverse proxies such as SSL VPN portals "flatten" part of the Web, by providing access to multiple web sites through a single host. For example, a company portal may be located at https://sslvpn.example.com, and allow remote access to several websites that form the corporate intranet as well as webified access to the mail server. The different services are distinguised by implementation-specific manipulation of the URL. For example, the following three URLs may be respectively for the internal mail server, for the internal wiki, and for Wikipedia:
The problem here is that although there are separate servers, they all map to the same origin as defined in [RFC6454]. Scripts from any of these sites can affect others. In fact, the Origin header as defined in section 7 of RFC 6454 can leak information to the real web server that it is located within the same flattened domain.
The HTTP header introduced in this document allows the portal to specify that URLs that appear to be from the same origin are, in fact, from different origins, by extending the 3-tuple of the origin to a 4-tuple. The user agent would be expected to apply the same-origin policy according to the 4-tuple rather than the 3-tuple.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When a web portal hides multiple actual web sites behind its own origin, it MUST add the new Extended-Origin header defined in the next section. The name field need not be related to the actual web origin, and is not meant for human consumption. The requirement is only that different origins MUST have different names in the header.
If the response from the original web site already contains one or more Extended-Origin headers, then the portal adds its own header after the rest.
The ABNF is to be added.
Extended-Origin: name; path=/something
The header includes a name, which is not necessarily meant for human consumption, and a path parameter. The general format is
This means that all requests of the format "GET /something/..." will be considered as going to the origin defined by the combination of the RFC 6454 origin and the name. As such, cookies from the portal MUST not be returned in requests to the extended origin, and vice versa. Scripts from inside the extended origin MUST be prevented from executing requests against the main portal and against other extended origins within the same portal.
Section 6 of RFC 6454 defines how to serialize an origin for inclusion in the "Origin" header defined in section 7 of that RFC.
For serializing an extended origin, follow steps 1-3 of section 6.1 or 6.2 of RFC 6454. To the result, append the name from the Extended-Origin header and a U+002E FULL STOP code points ("."). Then continue with steps 4-6.
For example, if the host is sslvpn.example.com, and the name in the extended origin header is webmail, then the serialized origin becomes https://webmail.sslvpn.example.com
To avoid collisions between serialized extended origins and serialized non-extended origins, servers SHOULD NOT use readable origins such as "webmail". Instead they should choose random-looking extended origin names, possibly obtained by hashing an internally meaningful name.
CONNECT https://sslvpn.example.com
GET / HTTP/1.1
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Set-Cookie: session=1234
<html>
<body>
Welcome, you can read your mail
<a href="/link/my_web_mail/inbox/index.html">here</a>
</body>
</html>
GET /link/my_web_mail/inbox/index.html HTTP/1.1
Referer: https://sslvpn.example.com/
Cookie: session=1234
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Extended-Origin: d41d8cd98f00b204; path=/link/my_web_mail
Set-Cookie: mailsession=5678
<html>
<body>
You have 1 unread message. Jumping in 5 seconds...
<script>...</script>
</body>
</html>
GET /link/my_web_mail/inbox/msg0945.html HTTP/1.1
Referer: https://sslvpn.example.com/link/my_web_mail/inbox/index.htm
Origin: https://d41d8cd98f00b204.sslvpn.example.com
Cookie: mailsession=5678
Here's an example of a connection with both the Extended-Origin and the Origin headers.
In this example, the first GET was the result of the user typing in an address, or following a link. Therefore it has no Origin header. It goes to the main page of the portal, so the response contains no Extended-Origin.
The second GET also happened because of clicking a link, not by any action of the page, so there's no need to send an Origin header. If there had been such a header, it would be just as defined in RFC 6454: https://sslvpn.example.com
The third GET is caused by a script running on the mail page. This page came with an Extended-Origin header, and so the user agent constructs the Origin header in the request according to the new rules in Section 2.2.
Note that the cookie set by the main portal was not sent in the third request. The second reply marked all requests beginning with "/link/my_web_mail" as belonging to the extended origin, and the third request matches that pattern. Cookies from the non-extended origin are not forwarded to the extended origin.
The second request did include the portal cookie in a request to the mail server. This is only an issue with the main portal cookies, not among the extended origins. Some SSL VPN portals strip their own cookies from requests going to the other servers, and this behavior is RECOMMENDED.
The interaction between this draft and CORS ([CORS]) is to be added.
https://sslvpn.example.com/p/inb/msg0945.html,HOST=mail.example.com
Some SSL-VPN products and configurations do not encode the server identity using a prefix in the URL, as shown in the example in Section 3. One such Method is this:
Extended-Origin: webmail; expr=/p/*,HOST=mail.example.com
The issue here is that the way the path parameter is defined, you cannot use it to define what URLs belong to the extended origin. We could replace it with a parameter that accepts a regular expression, but that seems overly complex:
Oren Souroujon contributed some of the text in this document, and also came up with the original idea. Yehezkel Horowitz helped with reviewing the draft and pointing out the issues with cookies and paths.
Thanks to James Manger and Tobias Gondrom for reviewing the first version of this draft.
This document causes compliant clients to disallow certain actions that are allowed today. In that sense, it reduces the attack surface.
More to be added.
The permanent message header field registry (see [RFC3864]) should be updated with the following registration:
NOTE TO RFC EDITOR: Please remove this section before publication.
Removed the special handling of portals behind portals.
Changed the syntax of the serialized origin from fragment-like to subdomain-like.
Cleaned up some grammar.
| [1] | Barth, A., "The Web Origin Concept", RFC 6454, December 2011. |
| [2] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [1] | van Kesteren, A., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, July 2010. |
| [2] | Klyne, G., Nottingham, M. and J.C. Mogul, "Registration Procedures for Message Header Fields", RFC 3864, BCP 90, September 2004. |