Print

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



Email
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
 

close
NEXT ARTICLE
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 Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?