Canmove, confirm
1,537
edits
Changes
no edit summary
<i>The HTTP Request header Sec-From, has changed from to "Origin" to avoid conflict because it is interoperable with the similarly named Origin header in [http://www.w3.org/TR/2009/WD-cors-20090317/ Cross-Origin Resource Sharing].</i>
= Sec-From Origin header proposal for CSRF and clickjacking mitigation =
This page contains collected thoughts generated in discussion and deep thinking about implementing some type of [http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html Origin-like header].
The Sec-From Origin header is considered helpful against JSON data theft and CSRF attacks. The information provided by Sec-FromOrigin--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 Origin 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 ==
In some scenarios, the string "null" is sent in lieu of origin information. This is done to indicate that the cause of the request is not trustworthy, even though it may come from the same origin. Certain requests are not generally useful as state-changing triggers (like requests for stylesheets, images or window navigation) and probably should not be trusted even if sent same-origin.
We chose the string "null" because of its neutral connotations. The Sec-From Origin header must ''always'' be sent to indicate support from the User Agent; "null" seems to indicate that, though Sec-From Origin is supported, the User Agent didn't think the request should be trusted to trigger state change. Other tokens could be used that more aptly describe the meaning of an "empty but present" header value: "redacted", "private" or "unsafe". "null" is fairly standard across HTTP, though, and for now we have opted to use it. === Diversion from CORS Origin header === We've chosen to create a new header (and not to blend in with the CORS Origin header) so that we have support for redirect chains and are not limited to protecting XHR requests. As a result, a name different from "Origin" needed to be chosen. '''What's in a name?''' <tt>Sec-From</tt> was chosen for two simple reasons. First, according to X, <tt>Sec-</tt> cannot be set or changed from XML HTTP requests and are more difficult to spoof. Second, since the header will describe what origins ''caused'' the request, and not in what context the result will be rendered, "From" seemed to be an appropriate descriptor.
=== 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-FromOrigin. 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 ([[Security/CSP|CSP]] for example).
=== Firewall-based Sec-From Origin 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 Origin header format =In order to provide enough information that makes this Sec-From Origin 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 Origin header is described in [http://webblazetools.csietf.berkeley.eduorg/2009html/draft-abarth-origin/origin.txt -05 an internet draft by Adam Barth, Collin Jackson and Ian Hickson]. The general format of the Sec-From Origin header will be: Sec-FromOrigin: <origin> [<origin>]*
An <tt><origin></tt> 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 Origin is served (and when it is "null") ==
This table explains when origin values for Sec-From Origin are served and when "null" is served as its value instead.
{| border="1" cellpadding="2"
|-
! Redirects
| YES || None || Before honoring redirect, append current origin to end of Sec-From Origin value (unless the last origin in the header is equal to the current origin, then do not modify its value). Set entire header value to "null" if redirect crosses FQDN boundaries or if initial value is "null".
|-
! XHR
=== Privacy-Sensitive Contexts ===
To elaborate on the table above, in the [http://webblazetools.csietf.berkeley.eduorg/2009html/draft-abarth-origin/origin.txt Sec-From Internet Draft05], it is stated that "null" must be sent as the value of Sec-From Origin instead of origin data when the request is initiated from a privacy-sensitive context. Following are a list of privacy sensitive contexts:
; Anchor Tag/hyperlink click : hyperlinks are common ways to jump from one site to another without trust. They should not be used to initiate state-changing procedures.
; Dependent load in stylesheet : usually an image, protected for reasons like the image load mentioned above.
Remaining contexts are not privacy sensitive and origin information should be transmitted in the Sec-From Origin header.
= 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 Origin to protect content from CSRF/JSON-theft)
