The HTTP Sec-From Header
University of California, Berkeley
abarth@eecs.berkeley.edu
http://www.adambarth.com/
Stanford University
collinj@cs.stanford.edu
http://www.collinjackson.com/
Google, Inc.
ian@hixie.ch
http://ln.hixie.ch/
Working Group
Internet-Draft
This document defines the HTTP Sec-From header. The Sec-From
header is added by the user agent to describe the security contexts
that caused the user agent to initiate an HTTP request. HTTP servers
can use the Sec-From header to mitigate against Cross-Site Request
Forgery (CSRF) vulnerabilities.
This document describes the HTTP Sec-From header. The Sec-From
header identifies the security contexts that caused the user agent to
initiate an HTTP request. HTTP servers can mitigate cross-site
request forgery vulnerabilies by accepting requests only if the
Sec-From header contains only white-listed origins.
TODO: Discuss other CSRF defenses.
The following algoritm MUST be used to compute the origin of a URI.
Let /uri/ be the URI for which the origin is being
determined.
Parse /uri/.
If /uri/ does not use a server-based naming authority, or if
parsing /uri/ failed, or if /uri/ is not an absolute URI, then
return an implementation-defined value.
Let /scheme/ be the scheme component of /uri/, converted to
lowercase.
If the implementation doesn't support the protocol given by
/scheme/, then return an implementaion-defined value.
If /scheme/ is "file", then the implementation MAY return a
implementation-defined value.
Let /host/ be the host component of /uri/.
Apply the IDNA ToASCII algorithm to /host/, with both the
AllowUnassigned and UseSTD3ASCIIRules flags set. Let /host/ be the
result of the ToASCII algorithm.
If ToASCII fails to convert one of the components of the string
(e.g. because it is too long or because it contains invalid
characters), then return an implementation-defined value.
Let /host/ be the result of converting /host/ to lowercase.
If there is no port component of /uri/, then let /port/ be the
default port for the protocol given by /scheme/. Otherwise, let
/port/ be the port component of /uri/.
Return the tuple (/scheme/, /host/, /port/).
Implementations MAY define other types of origins in addition to
the scheme/host/port tuple type defined above. (For example, user
agents could implement globally unique origins or certificate-based
origins.)
Implementations MUST use the following algorithm to test whether
two origins are the "same origin".
Let /A/ be the first origin being compared, and let /B/ be the
second origin being compared.
If either /A/ or /B/ is not a scheme/host/port tuple, return an
implementation-defined value.
If /A/ and /B/ have scheme components that are not identical,
return false.
If /A/ and /B/ have host components that are not identical,
return false.
If /A/ and /B/ have port components that are not identical,
return false.
Return true.
Implementations MUST using the following algorithm to compute the
Unicode serialization of an origin:
If the origin in question is not a scheme/host/port tuple, then
return the string
null
(i.e., the character sequence U+006E, U+0075, U+006C, U+006C) and
abort these steps.
Otherwise, let /result/ be the scheme part of the origin
tuple.
Append the string "://" to /result/.
Apply the IDNA ToUnicode algorithm to each component of the
host part of the origin tuple, and append the results of each
component, in the same order, separated by U+002E FULL STOP
characters (".") to /result/.
If the port part of the origin tuple gives a port that is
different from the default port for the protocol given by the
scheme part of the origin tuple, then append a U+003A COLON
character (":") and the given port, in base ten, to /result/.
Return /result/.
TODO: Check that we handle IPv6 literals correctly.
Implementations MUST using the following algorithm to compute the
ASCII serialization of an origin:
If the origin in question is not a scheme/host/port tuple, then
return the string
null
(i.e., the character sequence U+006E, U+0075, U+006C, U+006C) and
abort these steps.
Otherwise, let /result/ be the scheme part of the origin tuple.
Append the string "://" to /result/.
Apply the IDNA ToASCII algorithm the host part of the origin
tuple, with both the AllowUnassigned and UseSTD3ASCIIRules flags
set, and append the result to /result/.
If ToASCII fails to convert one of the components of the
string, e.g. because it is too long or because it contains invalid
characters, then return the literal string "null" and abort these
steps.
If the port part of the origin tuple gives a port that is
different from the default port for the protocol given by the
scheme part of the origin tuple, then append a U+003A COLON
character (":") and the given port, in base ten, to /result/.
Return /result/.
Whenever a user agent issues an HTTP request, the user agent MUST
include exactly one HTTP header named "Sec-From".
The value of the Sec-From header MUST either be
the string "null" (i.e., the character sequence U+006E, U+0075,
U+006C, U+006C) or
a sequence of non-"null" ASCII serializations of origins
separated by at least one LWS character.
Whenever a user agent would send a Sec-From header containing two
consecutive, idential origin serializations, the user agent MAY remove
one such origin serialization from the header.
Whenever a user agent issues an HTTP request from a
"privacy-sensitive" context, the user agent MUST send the value "null"
in the Sec-From header.
Whenever a user agent issues an HTTP request to URI /A/ as a result
of an HTTP redirect from URI /B/, the user agent MUST either:
set the value of the Sec-From header in the HTTP request to /A/
to "null" (i.e., the character sequence U+006E, U+0075, U+006C,
U+006C),
set the value of the Sec-From header in the /A/ request to the
value of the Sec-From header in the /B/ request extended with a
space and the ASCII serialization of the origin of /B/, unless this
would result in the header containing the origin serialization
"null".
Whenever a user agent issues an HTTP request that (1) is *not* the
result of an HTTP redirect and (2) is *not* initiated from a
"privacy-sensitive" context, the user agent SHOULD set the value of the
Sec-From header to the ASCII serialization of the origin that
initiated the HTTP request.
Note: This behavior differs from that of the HTTP Referer header,
which user agents often suppress when an origin with an "https" scheme
issues a request for a URI with an "http" scheme.
HTTP Servers MAY use the Sec-From header to "defend themselves
against CSRF attacks." Such servers are known as "participating
servers" in this section.
Let the /origin white list/ of a participating server be a set of
strings selected by the operator of that server.
The string "null" MUST NOT be a member of the /origin white list/
for any participating server.
Example: The origin white list for the example.com Web server
could be the strings "http://example.com", "https://example.com",
"http://www.example.com", and "https://www.example.com".
A participating server MUST use the following algorithm when
determining whether to modify state in response to an HTTP request:
If the request method is safe (as defined by RFC 2616,
Section 9.1.1, e.g. either "GET" nor "HEAD"), return "MUST NOT
modify state" and abort these steps.
If the request does not contain a header named "Sec-From", return
"MAY modify state" abort these stepts.
For each request header named "Sec-From", let the /initiating
origin list/ be the list of origins represented in the header:
If there exists a origin in the /initiating origin list/ is not
a member of the /origin white list/ for this server, return "MUST
NOT modify state" and abort these steps.
Return "MAY modify state".
Example: A Web server could modify state in response to POST
requests that lack an Sec-From header (because these requests are sent
by non-supporting user agents) and could modify state in response to
POST requests that have an Sec-From header of "http://example.com",
"https://example.com", "http://www.example.com", or
"https://www.example.com".
This section is not normative.
The Sec-From header improves on the Referer header by respecting the
user's privacy: The Sec-From header includes only the information
required to identify the principal that initiated the request
(typically the scheme, host, and port of initiating origin). In
particular, the Sec-From header does not contain the path or query
portions of the URI included in the Referer header that invade privacy
without providing additional security.
The Sec-From header also improves on the Referer header by NOT
leaking intranet host names to external Web sites when a user follows
a hyperlink from an intranet host to an external site because
hyperlinks generate privacy-sensitive requests.
This section is not normative.
Because a supporting user agent will always include the Sec-From
header when making HTTP requests, HTTP servers can detect that a
request was initiated by a supporting user agent by observing the
presence of the header. This design prevents an attacker from making
a supporting user agent appear to be a non-supporting user agent.
Unlike the Referer header, which is absent when suppressed by the user
agent, the Sec-From header takes on the value "null" when suppressed by
the user agent.
In some legacy user agents, The Sec-From header can be spoofed for
same-site XMLHttpRequests. Sites that rely only on network
connectivity for authentication should use a DNS rebinding defense,
such as validating the HTTP Host header, in addition to CSRF
protection.
TODO: The "Sec-From" header should be registered.
Think about how this interacts with proxies.
Think about how this interacts with caches.