On Jan 16, 2009, at 9:02 AM, Bil Corry wrote:
Maciej Stachowiak wrote on 1/15/2009 10:40 PM:
CONCLUSION: We should use a single Origin header with the name and
semantics of the Access-Control Origin header for both its
Access-Control purpose and for redirect defense. The differences in
the
HTML5 version are not worth the cost of a very similar but subtly
different header. And if we ever find the attack in case 3 is more
than
theoretical, we could add a 'Redirected-Via' header to provide full
information.
Thank you for the extended explanation. I do now see your point,
and agree it's probably the best course of action. It will,
however, still leave open some odd side-effects from not identifying
the redirect source, but maybe they're unlikely to be common. For
example, Site A allows the users to specify a remote location for
their avatar image; the user points to Site B, which in turn then
redirects to Site C. Site C doesn't like its images being used
remotely and checks the Origin header and identifies Site A. Site C
then complains to Site A about the hotlinking; Site A checks it's
avatar URLs and doesn't find Site C listed. So now you have Site C
being hotlinked from Site A, but Site A has no way to discover how
it's happening other than to crawl all outbound URLs.
Such hotlinking is probably using a GET request, so no Origin header
would be sent. I believe it is also outside the scope of the CSRF
protection and cross-origin data sharing goals of Origin. The Referer
header is still usable for hotlinking prevention in this scenario, the
only downside being that it is apparently often filtered by sites or
users for privacy reasons.
Regards,
Maciej