On Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne <[email protected]> wrote: > Take XSS and history stealing for example. Assume these are seperate > modules and each is responsible for mitigating its respective threat. > Presumably the safe history module will prevent a site from being able > to do getComputedStyle (or equivalent) on a link from a different > origin. But an attacker could still steal history from any site that he > can inject script into by document.writing the list of URLs into the > page, testing if they are visited, and sending the results back to the > attacker's site. Granted, this is a contrived example and the attacker > could probably do worse than history stealing if we're allowing that he > can inject arbitrary script. But the point is that the threat of > history stealing is not fully mitigated by changes to CSS for > cross-origin links. A complete mitigation of the threat requires both > altering the behavior of getComputedStyle as well as disabling > non-trusted scripts in the document.
I don't think this argument makes sense. When people complain about history stealing, e.g. on https://bugzilla.mozilla.org/show_bug.cgi?id=147777, they're not worried about the case when their site has XSS. They're worried about a much weaker attacker who simply operates a web site. > Why, though, would we ever want to > change from an opt-in to an opt-out model? I don't think we'll want to change in the future. We should pick the better design now and stick with it (whichever design we decide is better). > I think it's better to have sites be explicit with their policies, as it > forces them to understand the implications of each part of the policy. > If we provide pre-canned policies, sites may wind up with incorrect > assumptions about what is being restricted. I agree, but if you think sites should be explicit, doesn't that mean they should explicitly opt-in to changing the normal (i.e., non-CSP) behavior? > The situation I > want to avoid is having browsers advertise (partial) CSP support and > have websites incorrectly assume that they are getting XSS protection > from those browsers. I don't understand. There is no advertisement mechanism in CSP. Do you mean in the press? What's actually going to happen is that thought leaders will write blog posts with sample code and non-experts will copy/paste it into their web sites. Experts (e.g., PayPal) will read the spec and test various implementations. As for the press, I doubt anything we write in the spec will have much impact on how the press spins the story. Personally, I don't care about what the press says. We should design the best mechanism on a technical level. > Also, it seems unlikely to me that successful > mitigations can be put in place for the other threats if XSS is still > possible (I can provide examples if people are interested, but I have > to run to catch a train, unfortunately). It seems very reasonable to mitigate history stealing and ClickJacking without using CSP to mitigate XSS. As a web developer, I can't do anything about history stealing myself. I need help from the browser. On the the other hand, I can do something about XSS myself. > If we can agree that XSS is > the main threat that we want to address with CSP, then I think we can > also agree to make it a required module. I think we're all agreed on this point. Our current disagreements appear to be: 1) Whether frame-src should be in the resources module or in the same module as frame-ancestor. 2) Whether sites should have to opt-in or opt-out to disabling inline script and/or eval-like APIs. I have a few more minor points, but we can get to those after we settle the above two. I think the way forward is for me (or someone else if they're interested) to write up our current thinking on the wiki. Adam _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
