Book Excerpt: The Tangled Web: A Guide to Securing Modern Web Applications

By Michal Zalewski

January 17, 2012 — (Page 6 of 6)

Other Uses of the Origin Header
The Origin header is an essential part of CORS, XDomainRequest, and UMP, but it actually evolved somewhat independently with other uses in mind. In their 2008 paper, Adam Barth, Collin Jackson, and John C. Mitchell advocated the introduction of a new HTTP header that would offer a more reliable and privacy-conscious alternative to Referer. It would also serve as a way to prevent cross-site request vulnerabilities by providing the server with the information needed to identify the SOP-level origin of a request, without disclosing the potentially more sensitive path or query data.

Of course, it was unclear whether the subtle improvement between Referer and its proposed successor would actually make a difference for the small but nonnegligible population of users who block that first header on privacy grounds. The proposal consequently ended up in a virtual limbo, not being deployed in any existing browsers but also discouraging others from pursuing other solutions such as XSRF or XSSI. (To be fair, the concept was very recently revived under the new name of From-Origin and may not be completely dead yet.)

The fate of the original idea aside, the utility of the Origin header in specialized cases such as CORS was pretty clear. Around 2009, this led to Barth submitting an IETF draft specifying the syntax of the header, while shying away from making any statements about when the header should be sent, or what specific security problems it might solve:

The user agent MAY include an Origin header in any HTTP request.
[…]
Whenever a user agent issues an HTTP request from a “privacy-sensitive” context, the user agent MUST send the value “null” in the Origin header.
NOTE: This document does not define the notion of a privacy-sensitive context. Applications that generate HTTP requests can designate contexts as privacy-sensitive to impose restrictions on how user agents generate Origin headers.

The bottom line of this specification is that whatever the decision process is, once the client chooses to provide the header, the value is required to accurately represent the SOP origin from which the request is being made. For example, when a particular operation takes place from http://www .bunnyoutlet.com:1234/bunny_reports.php, the transmitted value should be.

Origin: http://www.bunnyoutlet.com:1234

For origins that do not meaningfully map to a protocol-host-port tuple, the browser must send the value of null instead.

Despite all of these plans, as of this writing only one browser includes the Origin header on non-CORS navigation: WebKit-based implementations send it when submitting HTML forms. Firefox seems to be considering a different approach, but nothing specific seems to have been implemented yet.

Related Search Term(s): The Tangled Web: A Guide to Securing Modern Web Applications

Pages 1 2 3 4 5 6

Share this link: http://sdt.bz/36270

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

Cigital Develops Ready-to-Use Tools for Securing the Smart Grid Cigital Inc. announced the release of the Guide to Developing a Cyber Security and Risk Mitigation Plan.

Kik Launches an Open API to Enable Mobile Developers to Bake Instant Content Sharing Into Any App API-powered developers like Rude Boy Games, DrinkOwl and FlyScreen can promote their apps to millions of Kik Messenger users.

webOS no great loss for developers HP wasn’t able to build momentum for the former Palm operating system