On Thu, Oct 22, 2009 at 3:58 PM, Lucas Adamski <[email protected]> wrote: > The threat-model centric approach won't work in the long run for a few > reasons:
I'm not sure what we're arguing about. Do you like Brandon's groupings? They made sense to me. Are there concrete changes you think we should make? > a) threat models change over time.. nobody was even talking about > clickjacking until a few years ago, so had we designed this previously we > would have put frame controls under some other category (maybe content > loading) I'm not sure we would have thought to include frame-ancestors without having ClickJacking in mind. > b) API's change over time so they can drift between threat groupings... > frames are now a potential XSS concern due to postMessage I think it's safe to say that the ability to block inline and external script is the most important use case for CSP. I believe that because I'm motivated by wanting to mitigate XSS. Other folks might have different reasons for thinking they're important. Those policy levers are one or two order of magnitude more important than controlling xhr-src, IMHO. > CSS is content importing.. oh but IE allows CSS "expressions" so its a XSS > vector too. Right, but the issues are separable. It's much more important to disable CSS expressions than it is disable all inline CSS, for the same reason it's much more important to diable inline event handlers than it is to disable all HTML attributes. > But we intentionally did not build the actual directive names > around the threats du jour. I agree that anti-csrf is too narrow a directive name. > If we are concerned about communication and documentation then we should > focus on that problem. I suspect folks are more likely to learn how to use CSP by copy and pasting from Ajaxian than they are to read the spec. > the mechanism should be a generalized method > for enforcing policies, and then the effort is on developing sets of > policies that achieve particular goals, and with sufficient iteration and > testing go on to become common deployment patterns. Trying to bake those in > from the get-go seems to assume perfect knowledge of current and future > threats. I didn't quite understand what you meant here. There's an unbounded number of policy levers we could expose. We should prioritize them based on which threats we think are most important. If the threat landscape changes in the future, we can add more policy levers. Try to predict the threats of the future is a tricky business indeed. That's why I think modularity and extensibility is good for CSP. > P.S. Regarding making XSS a mandatory and opt-out module, those might be > related things. I think the question is really, when a given user agent or > website states that they have deployed CSP, does that really mean anything > in a concrete sense? Mean anything to whom? The proof will be in the pudding, so to speak. If browser X implements a bunch of useless modules, that won't be of much help to web developers. Different vendors might have different ideas about what's important, though. The market will sort out who's right. What I see as likely is that Firefox will implement most / all of the modules, and the other browser vendors will implement some subset. If some directives become popular among web developers, then the other browser vendors will be incentivized to implement them too. Adam _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
