Bug 20792

To prevent CSRF attacks, we should send an Origin header with POST requests that identifies the origin that initiated the request. If the browser cannot determine the origin, the browser sends the value "null". == Privacy == The Origin header improves on the Referer header by respecting the user’s privacy: 1. The Origin header includes only the information required to identify the principal that initiated the request (typically the scheme, host, and port of the active document’s URL). In particular, the Origin header does not contain the path or query portions of the URL included in the Referer header that invade privacy without providing additional security. 2. The Origin header is sent only for POST requests, whereas the Referer header is sent for all requests. Simply following a hyperlink (e.g., from a list of search results or from a corporate intranet) does not send the Origin header, preventing the majority of accidental leakage of sensitive information. By responding to privacy concerns, the Origin header will likely not be widely suppressed. == Server Behavior == To use the Origin header as a CSRF defense, servers should behave as follows: 1. All state-modifying requests, including login requests, must be sent using the POST method. In particular, state-modifying GET requests must be blocked in order to address the forum poster theat model. 2. If the Origin header is present, the server must reject any requests whose Origin header contains an undesired value (including null). For example, a site could reject all requests whose Origin indicated the request was initiated from another site. == Security Analysis == Although the Origin header has a simple design, the use of the header as a CSRF defense has a number of subtleties. * Rollback and Suppression. Because a supporting browser will always include the Origin header when making POST requests, sites can detect that a request was initiated by a supporting browser by observing the presence of the header. This design prevents an attacker from making a supporting browser appear to be a non-supporting browser. Unlike the Referer header, which is absent when suppressed by the browser, the Origin header takes on the value null when suppressed by the browser. * DNS Rebinding. In existing browsers, the Origin header can be spoofed for same-site XMLHttpRequests. Sites that rely only on network connectivity for authentication should use one of the existing DNS rebinding defenses, such as validating the Host header. This requirement is complementary to CSRF protection and also applies to all the other existing CSRF defenses. * Plug-ins. If a site opts into cross-site HTTP requests via crossdomain.xml, an attacker can use Flash Player to set the Origin header in cross-site requests. Opting into cross-site HTTP requests also defeats secret token validation CSRF defenses because the tokens leak during cross-site HTTP requests. To prevent these (and other) attacks, sites should not opt into cross-site HTTP requests from untrusted origins.