Security/Origin

The HTTP Request header Sec-From, has changed from "Origin" to avoid conflict with the similarly named header in Cross-Origin Resource Sharing.

Sec-From header proposal for CSRF and clickjacking mitigation

This page contains collected thoughts generated in discussion and deep thinking about implementing some type of Origin-like header.

The Sec-From header is considered helpful against JSON data theft and CSRF attacks. The information provided by Sec-From--a bit of contextual request-creation information--should provide hints to web servers about trustworthiness of requests in all three of these situations.

JSON data theft

Data served via JSON (and imported using a script tag) can be stolen if the origin of a JSON request is not authenticated. If the origin of a script request were provided, web servers could decide whether or not to serve JSON data.

CSRF

Cross-site request forgeries are often GET requests assembled and sent through the use of an automatic load (like an img or script tag). In many scenarios, like the two mentioned, state changing transactions should not be allowed. In other scenarios, like form submissions, state-changing transactions should be accepted but should be authenticated so the server knows what site generated the request.

Generally, the Sec-From header aims to provide a bit of context with HTTP requests so that servers may make educated decisions on whether or not to serve data, accept request data for state-changing transactions, or continue with a persistent session. This is accomplished by specifying a list of sites that indirectly caused a request (the redirect chain) and the immediate "Origin" of a request, or the entity that most recently caused the request to happen. This Origin may be a host name or the string "null" in the cases where a request may have been falsely or deceptively generated.

Design Path

Advantage of more than one bit of data

TODO: discuss why we decided this approach is better than just sending "OK" or "FAIL".

Selection of "null" token

TODO: describe why we chose "null" instead of something like "redacted" or "private" or "fail".

Diversion from CORS Origin header

TODO: explain why we diverged from CORS. Also, "What's in a name?"

Why not include a frame list?

There were a number of factors that caused this proposal to change from a model that helps prevent clickjacking to what is proposed here. An earlier proposal suggested providing the chain of frames as well as the origin of the request. However, the chain of requests (i.e., redirects and referrer) that cause a document to load and the layout context in which a document will be rendered seem to be useful in different cases; the data points for "how you get something" versus "what you do with it" solve pretty orthogonal problems and we don't want to add complexity to Origin/Sec-From if it means a significant delay in adoption.

Knowing the frame chain is indeed useful, but it seems helpful when solving problems different from those originally targeted by a feature like Sec-From. For example, clickjacking prevention (one of the uses for the layout context or frame tree) seems most appropriate on the client side where the framing takes place, so it seems to me that sending this data to the server might not be a best course of action.

There are other features in the works that will hopefully fill the need for clickjacking prevention (CSP for example).

Firewall-based Sec-From header scrubbing

TODO: Explain why and how admins of intranets may want to manipulate requests (setting to "null" instead of erasing) when forwarding outbound requests. Explain why removing is bad.

Sec-From header format

In order to provide enough information that makes this Sec-From header useful for more server-side protections (other than just CSRF), the origin of a request may be sent (or the string "null") as well as a list of any redirects that led to the final request.

The Sec-From header is described in an internet draft by Adam Barth, Collin Jackson and Ian Hickson ([1]). The general format of the Sec-From header will be:

Sec-From: <origin> [<origin>]*

An <origin> is a combination of scheme, host and port. Unlike HTTP Referer, no path data or query string will be provided in the origin. The first origin value will be the initial source of the request, and any remaining values will be origins of any redirects that changed the target of the request.

When Sec-From is served (and when it is "null")

This table explains when origin values for Sec-From are served and when "null" is served as its value instead.

API	Send Origins	Workaround to Default Behavior	Notes
Anchor tag	"null"	Convert to GET FORM	Many sites allow users to post links, so we don't want to send Origin with links
Window navigation	"null"	Convert to GET FORM	Refers to anchor.href, window.location, window.open, ...? These are often used as equivalents to user generated links, making them susceptible to CSRF.
IMG	"null"	If we were to send the RequestType then we could send the origin	Images are easy to inject into a site.
iframe, embed, applet	YES*	None	Embedding information useful to address clickjacking. *If ancestor tree is more than 1 deep, send Origin:null
Form (GET and POST)	YES	Rewrite as simple GET upon submission	Remote sites need to authenticate source of request
<SCRIPT>	YES	None	Additional mitigation for JSON data theft
stylesheets	YES	None	?
dependent loads from stylesheets	"null"	?	?
Redirects	YES*	None	*Set Origin:null if redirect crosses FQDN boundaries
XHR	YES*	None	*Comply with Access Control behavior

Implementation

... (discuss confusion with CORS Origin, Referer, etc. Programmatic details about serving the origins)

Sample Web Application Use

... (show examples of how to use Sec-From to protect content from CSRF/JSON-theft)