Set Origin header to "null" for cross origin redirects.

net/url_request/url_request.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "net/url_request/url_request.h"
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
 #include "base/callback.h"
 #include "base/compiler_specific.h"
@@ skipping 19 matching lines @@
 #include "net/http/http_response_headers.h"
 #include "net/http/http_util.h"
 #include "net/ssl/ssl_cert_request_info.h"
 #include "net/url_request/redirect_info.h"
 #include "net/url_request/url_request_context.h"
 #include "net/url_request/url_request_error_job.h"
 #include "net/url_request/url_request_job.h"
 #include "net/url_request/url_request_job_manager.h"
 #include "net/url_request/url_request_netlog_params.h"
 #include "net/url_request/url_request_redirect_job.h"
+#include "url/gurl.h"
+#include "url/origin.h"
 
 using base::Time;
 using std::string;
 
 namespace net {
 
 namespace {
 
 // Max number of http redirects to follow.  Same number as gecko.
 const int kMaxRedirects = 20;
@@ skipping 885 matching lines @@
       // the POST and don't have meaning in other methods. For example the
       // inclusion of a multipart Content-Type header in GET can cause problems
       // with some servers:
       // http://code.google.com/p/chromium/issues/detail?id=843
       StripPostSpecificHeaders(&extra_request_headers_);
     }
     upload_data_stream_.reset();
     method_ = redirect_info.new_method;
   }
 
+  // Cross-origin redirects should result in an Origin header value of "null" if
+  // the Origin header is present in the original request (see
+  // https://tools.ietf.org/id/draft-abarth-origin-03.html#rfc.section.5). This

[Ryan Sleevi, 2015/03/19 03:46:34]

Cite the RFC :P

http://tools.ietf.org/html/rfc6454

[jww, 2015/03/19 17:53:10]

Good catch. See my comment below.

+  // is necessary to prevent a reflection of POST requests to bypass CSRF
+  // protections. If the header was not set to "null", a POST request from

[Ryan Sleevi, 2015/03/19 03:46:34]

This doesn't align with how http://tools.ietf.org/html/rfc6454#section-7.3
describes it

So why null rather than treating it as an origin list? That is, the RFC doesn't
seem to support your explanation on 959-961, or at least, not why you chose one
over the other.

[jww, 2015/03/19 17:53:09]

Well, unfortunately, my description was based on the Origin Header draft, as you
pointed out above :-( I still think this is "the right thing to do" in that it
matches the behavior of Firefox and IE, and I think you could make an argument
about the ambiguity of "privacy sensitive contexts" applying to this case.

What's your preference/thought here? I'm updating the comment to describe this
rationale, but I'm unsure of the "right" answer here.

[davidben, 2015/03/24 23:47:38]

I believe null is correct. Looks like we ended up with more WHATWG/IETF/reality
divergence.

https://lists.w3.org/Archives/Public/www-archive/2012Jun/0001.html
https://fetch.spec.whatwg.org/#origin-header

Looks like the redirect behavior now comes from:

https://fetch.spec.whatwg.org/#http-fetch (step 4, case 301-308, step 10.1)
Expanding call sites further, it's...
https://fetch.spec.whatwg.org/#http-network-or-cache-fetch (step 3, cites
'serialized')
https://html.spec.whatwg.org/multipage/browsers.html#ascii-serialisation-of-a...
(step 1)

Or

http://www.w3.org/TR/cors/#redirect-steps

The former claims to supplant the latter, but exactly which bucket in the
W3C/WHATWG mess this falls under, I have no clue.

[jww, 2015/03/27 22:16:14]

Great finds! I guess I wasn't aware of Ryan's total ordering of WHATWG > W3C >
IETF, but that's good to know :-) I'll rewrite this comment to reflect and
reference the Fetch spec.

+  // origin A to a malicious origin M could be redirected by M back to A. Then
+  // if A checked the Origin header, it would appear to be a request from
+  // itself, which it might reasonably conclude would allow it to modify server
+  // state.  However, this would actually be a confused deputy, since M may have
+  // carefully chosen what URL on A to redirected to, such that only A should
+  // have been able to make the request.
+  //
+  // The alternate solution is to place both origins in the Origin header, but
+  // whether to do that or set Origin to "null" is left to the discretion of the
+  // user agent.
+  //
+  // See also https://crbug.com/465517.
+  if (redirect_info.new_url.GetOrigin() != url().GetOrigin() &&
+      extra_request_headers_.HasHeader(HttpRequestHeaders::kOrigin)) {
+    extra_request_headers_.SetHeader(HttpRequestHeaders::kOrigin,
+                                     url::Origin().string());
+  }
+
   referrer_ = redirect_info.new_referrer;
   first_party_for_cookies_ = redirect_info.new_first_party_for_cookies;
 
   url_chain_.push_back(redirect_info.new_url);
   --redirect_limit_;
 
   Start();
   return OK;
 }
 
@@ skipping 235 matching lines @@
       new base::debug::StackTrace(NULL, 0);
   *stack_trace_copy = stack_trace;
   stack_trace_.reset(stack_trace_copy);
 }
 
 const base::debug::StackTrace* URLRequest::stack_trace() const {
   return stack_trace_.get();
 }
 
 }  // namespace net