On Jun 5, 10:40 am, Gervase Markham <[EMAIL PROTECTED]> wrote: > - Are we concerned about the bandwidth used by the additional headers, > or are the days of worrying about a few bytes overhead per request long > past?
I am not particularly concerned with the additional bandwidth, nor have I heard any specific objections in that area. I think that a larger impact may be created, though, by the additional round trips required by the CSRF aspects of the proposal (which you bring up below). > - I am concerned about the performance implications of making a > preliminary HEAD request for every cross-site resource, which is needed > to enable Request-Source. Has this been analysed at all? Analyzed, no... but I agree that the Request-Source checks should only be made for non-safe methods. The proposal includes that statement, though perhaps it could have been made more prominently: http://people.mozilla.com/~bsterne/site-security-policy/details.html#non-safe > The impact would be significantly reduced if we were to do such checks > only for unsafe HTTP verbs (i.e. POST rather than GET). The vast > majority of cross-site requests (e.g. images, searches) are GETs. I totally agree. > - "When any Script-Source instruction is received by the browser script > enforcement mode is enabled ..." > > This means that all script has to be in external .js files. (This is one > of the differences in approach from Content-Restrictions.) While this is > an encouragement of best practice in JS authorship (unobtrusive script, > addition of event handlers using addEventListener() and so on) would > site authors find it too restrictive? This is admittedly the most cumbersome aspect of the proposal for site authors. The assumptions I have been going on that led to this model are twofold: 1. It is extremely difficult to differentiate "intended" inline script from "injected" inline script and a clear boundary can be established if we simply require that all JavaScript be included from external files from white-listed hosts. 2. Sites that wish to utilize Site Security Policy will perhaps be willing to do more work in reorganizing their pages, at least for those resources that they consider "sensitive" enough to justify using SSP. > - I am assuming that the script-removal required by Script-Source would > be done at parse time. Is that correct? Yes. The add-on that I wrote is a total hack (see Nils' comments below) and is for proof-of-concept purposes only. A permanent implementation (for Mozilla) will likely be a patch to the HTML and XML parsers that creates a mode for disabling inline and non-white- listed scripts which can be toggled on or off per a site's policies. > - Is it worth having a special value for Script-Source and > Request-Target, such as "domain", to enable all sites in the same domain > (as defined by the Public Suffix List,http://www.publicsuffixlist.org) > to receive requests, rather than making the site owner list them explicitly? Yes. I think this is worthwhile and would be useful, for example, for authors whose content may be subject to move periodically and who don't want to hard code server names into their policies. > - Perhaps via an extension, the browser could also support notifying the > user/web developer of policy violations. Yes, that would be very easy to support as well and would provide useful information to interested users. > - Can you more carefully define the relative priority and order of > application of allow and deny rules in e.g. Script-Source? Yes. I made comments in the add-on code that does this, but you're right that it should be explained in the proposal as well. For example, if a host matches any deny rule, that rule will take precedence over any rule allowing the host. > - Do you plan to permit these policies to also be placed in <meta > http-equiv=""> tags? There are both pros and cons to this, of course. Yes, I've thought about this as well, and I think http-equiv will probably be useful for the set of users who don't have CGI privileges on their server and can't set custom headers the traditional way. Also, I'm seeing a lot of suggestions/requests (off newsgroup mostly) that policies be defined in an external file rather than via headers. This would obviously be closer to Adobe's Flash model. I have heard you, in this discussion and previously, bring up the issue of the log spam created by all the 404s generated in sites that don't have a policy file. What about the following idea (from Dan Veditz): If a server wants to set Site Security Policy, it sends a HTTP header or http-equiv meta tag that points the user agent to the location where the policy file sits. Thoughts? > Hope that's helpful :-) It is, as always. Cheers, Brandon _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
