Adam Barth wrote:
I think it might be better to focus this module on the "forum poster" threat model. Instead of assuming the attacker can inject arbitrary content, we should limit the attacker to injecting content that is allowed by popular form sites (e.g., bbcode). At a first guess, I would limit the attacker to text, hyperlinks, and images. (And maybe bold / italics, if that matters.)
There should be room for each directive to address slightly different threat scenarios. For the forum threat you've described, the attack mechanics (i.e., CSRF) and basic remediation strategy (disallow sending cookies) are common to other threats the module aims to defend against. Additionally, cookieless-images is complementary to anti-csrf because it defines an additional constraint to images loaded from |self|. So perhaps the module needs to be better positioned and each directive better motivated.
I think we should assume that the attacker cannot inject form elements because this is uncommon in forum web sites.
That is fine for motivating cookieless-images, but this assumption could prove inadequate for other scenarios where the threat exists. It may be OK to remove the language governing form actions from CSRFModule if the issue is further deferred to another module (as does [1]), where this (currently hypothetical) module entirely blocks form submission if the action URI is not in a whitelist of trusted origins. (That would target the form-based password theft threat, as well as the CSRF threat.)
There is a usability issue here: is it more usable (w.r.t. the web developer) to:
(1) support a declaration of "anti-csrf" and enable the widest default set of protections that could be offered against CSRF (without being too strict as to break the most common use cases), but possibly having multiple modules specifying (complementary) form policies, or
(2) group all form-related policies in a single module, even if the policies address fundamentally different attacks?
In this case, this boils down to: should CSP directives be threat-centric or content-type-centric? Alternatively, this may be an example of CSP being too granular.
Mike [1] https://wiki.mozilla.org/Security/CSP/XSSModule#Open_Issues _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
