Canmove, confirm
1,537
edits
Changes
Created page with '= Origin header proposal for CSRF and clickjacking mitigation = <i>The HTTP Request header Sec-From, has changed from "Origin" to avoid conflict with the similarly named header i…'
= Origin header proposal for CSRF and clickjacking mitigation =
<i>The HTTP Request header Sec-From, has changed from "Origin" to avoid conflict with the similarly named header in [http://www.w3.org/TR/2009/WD-cors-20090317/ Cross-Origin Resource Sharing].</i>
= Summary =
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 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.
= 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 ([http://webblaze.cs.berkeley.edu/2009/origin/origin.txt]). The general format of the Sec-From header will be:
Sec-From: <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 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.
{| border="1" cellpadding="2"
|-
! 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)
<i>The HTTP Request header Sec-From, has changed from "Origin" to avoid conflict with the similarly named header in [http://www.w3.org/TR/2009/WD-cors-20090317/ Cross-Origin Resource Sharing].</i>
= Summary =
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 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.
= 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 ([http://webblaze.cs.berkeley.edu/2009/origin/origin.txt]). The general format of the Sec-From header will be:
Sec-From: <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 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.
{| border="1" cellpadding="2"
|-
! 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)
