- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Mon, 23 Jun 2008 22:18:16 +0200
- To: "Adam Barth" <w3c@adambarth.com>
- Cc: "Collin Jackson" <w3c@collinjackson.com>, public-webapps@w3.org
* Adam Barth wrote: >There are three cases: > >1) Origin header missing: This is a non-supporting browser. Fall >back to existing CSRF defenses. >2) Origin header has a trusted value: Accept the request. >3) Origin header has an untrusted value: Reject the request. Yes, and I am saying, if the first case properly protects against these attacks, then you do not need the header. If it does not, then you have an insecure web application at least until you drop this case. For this kind of web application, when it needs to be used cross-site, the header does indeed have some "advantage" over the simpler cross-site indicator, but making inherently insecure applications a little less insecure, if you could also fully secure them, does not strike me as a good deal. Note again that I am not talking about "XHR2+AC" here, as the security model is completely different there (you ask before you post) and until very recently, it used a different header than the 'Origin' header that has been proposed. I would be quite interested in having an indicator that helps blocking unwanted cross site requests, like legacy cross site form posts, I just don't see how the non-"XHR2+AC"-'Origin' header is better than a much simpler, more difficult to manipulate, and privacy- enhanced cross site indicator. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Monday, 23 June 2008 20:18:54 UTC