On 10/22/2009 06:09 PM, Adam Barth wrote: > On Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne<bste...@mozilla.com> wrote: >> 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.
Granted, it was a contrived example. Here's another try: say we have the theoretical CSRF module that does a perfect job of stopping the browser from sending spurious requests to a site that originate from some other site. The site would still be vulnerable to forged same-site requests if an attacker is able to inject script or other content into the site itself. You might say "well, *cross-site* request forgery is mitigated so our obligation is met", but the broader forged request threat isn't completely sealed off. A site will still need additional policy to be secured against request forgery. It's challenging to make this case for capability-based modules given only the current set of known web app threats. We know that future attacks will be based on the combination of browser capabilities. If we can do a good job of enumerating those capabilities and providing policy "levers" to restrict them we'll be able to address new threats that arise in the future with new policies, which can be deployed overnight by websites, rather than new modules which take at least one browser release cycle plus a policy change by the websites to take advantage of the module. FWIW, I'm actually not hearing you object strongly to the capability-based module system but rather that you're pointing out (admitted) weakness in my earlier example. Do I have that right? Are others still preferring a threat model based approach to the modules, or can we close this issue? >> 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). Well, I personally think that safe-by-default (opt-in to inline scripts, etc.) is a better design because it forces sites to be more explicit with what they are permitting and it is consistent with the white list approach used throughout the model. I've stated it elsewhere, but we definitely want to avoid sites thinking they are protected when they are not, in fact. >> 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? I apologize, but I don't understand this question. What is the normal behavior we are talking about changing in this example? >> 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? Yes, in the press e.g. some table on a web developer site showing "CSP support in all major browsers" but only a subset supporting the core XSS part. > 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. We're in total agreement here. >> 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. Awesome :-) > Our current disagreements appear to be: > > 1) Whether frame-src should be in the resources module or in the same > module as frame-ancestor. I think your suggestion to put in in the content loading module makes more sense than a "frame loading" module. > 2) Whether sites should have to opt-in or opt-out to disabling inline > script and/or eval-like APIs. I stated my opinion above. I'll wait to hear back from others. > I have a few more minor points, but we can get to those after we > settle the above two. Look forward to hearing them. > I think the way forward is for me (or someone else if they're > interested) to write up our current thinking on the wiki. This is a good idea. We're still coalescing a lot of what has been discussed over the last two weeks, and that information is living in several places currently. As we resolve these points, Sid and I will definitely be updating the spec. > Adam Cheers, Brandon _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
