On Jul 12, 10:35 am, "Evert | Rooftop" <[EMAIL PROTECTED]> wrote: > Sorry if this was already brought up in this thread (or if its a > closed subject), but using headers vs. a policy file is a bad idea, > for the following reasons: > > * Allows caching > * Allows usage of the policy on a site where there's no scripting > available (static content servers?) > * Allows a policy to enforced on a domain-level, instead of for every > html page > * Removes the HEAD before POST requirement > > The last one is an important one for a different reason as well. PHP, > as an example, will execute scripts the same way regardless if its > HEAD, POST or GET, so this could produce unwanted results on existing > sites, not to mention a bandwidth and time overhead.
Hi Evert, I appreciate your comments and I am working hard on a set of changes to the proposal based on a lot of feedback I've received both on the newsgroup and in private communications. These changes, I think, encompass the comments you made. First, we do plan to support both HTTP headers as well as files for policy transmission. That request has come from a number of people, so it seems wise to give the people what they want :-) I am working hard on modifying the proposal document to include these changes which are fairly broad. I will spare most of the details now and will post to the newsgroup when those changes have been published. With regard to your last comment (re: PHP treating all requests equally), I don't think that's quite accurate. Applications written using the $_REQUEST super-global will suffer from that, but using $_REQUEST only is not a best practice and most web applications should reasonably be expected to differentiate POST, GET, and HEAD. However, this point may be moot as we are starting to consider other options for CSRF protection rather than the pre-flight requests originally proposed. It may be the case that adding such policy requests for all cross-site POSTs will have too high an impact on bandwidth, round trips, etc. Jackson, Barth and Mitchell have written a paper regarding CSRF protection that utilizes a new HTTP header, Origin: http://crypto.stanford.edu/websec/csrf/ An Origin header has also been proposed in the W3C's Access-Control spec. I would be happy to hear feedback on utilizing this model instead of the browser-based ingress/egress filtering model which was originally proposed. In my opinion, it has several benefits most notably: 1) ease of implementation for user agents, and 2) adds no additional round trips and minimal additional bandwidth. It will also be consistent with the Access-Control spec. Thoughts? -Brandon _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
