It seems that the entire problem could be solved very elegantly by simply adding a new flag to the HTTP cookie specification.
Similarly to how cookies flagged
Secure will only be submitted by the user agent over secure connections and those which are flagged
HttpOnly will be forever inaccessible via DOM access, why not specify a new flag, say,
SameOriginOnly, which, when set, would prevent the cookie from being submitted with requests triggered by cross-origin referrers?
Of course, it would default to off so as not to break the previously expected behavior for already existing web sites, as per HTML5 Design Principle #2.1. I suppose there does exist one security hole, but not one that can't be easily solved: it can't be indiscriminately depended on, because old browsers would presumably just ignore the unrecognized flag.
So why not just create a whitelisted enumeration of
NoCSR-implementing user agents versions' corresponding UA strings, and then only accept/process authorization-requiring and sensitive requests that carry one of those
User-Agent: values? For requests submitted with no or non-whitelisted UA headers, an error could be returned that reasonably demands that the user upgrade to a supported browser version.
The whitelisting could be DRYed out with canonical implementation libraries (it would probably be more like a single simple function) for various server side languages.
Doesn't this seem much simpler than the current system of generating, keeping track of, and reading secure CSRF tokens?