W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: XSS mitigation in browsers

From: Lucas Adamski <ladamski@mozilla.com>
Date: Fri, 21 Jan 2011 15:29:42 -0800
Message-Id: <EC42C038-FDD1-4578-93FB-7A5BDE525E34@mozilla.com>
To: public-web-security@w3.org
On Jan 21, 2011, at 1:47 PM, Devdatta Akhawe wrote:
> To me it looks like Adam's proposal makes 2 key new ideas:
> * It should be possible to specify policy without messing around in
> headers. With the 'extra policy can only make things more restrictive'
> setup, I don't see why this isn't a good idea.

As Dan already mentioned, we had this in previously and could certainly put it back into the proposal.  It just adds a bit of complexity.

> * It should be possible to handle violations programmatically. As I
> argued before, I think this is a cleaner/simpler/better/flexible
> design than the current CSP design. As Adam noted before, the
> SecurityViolation (and whatever its called in CSP) is for programmer
> convenience and thus accessing it programmatically (which is imho more
> convenient for the developer) is a good idea.

Actually the reporting is primarily aimed at webserver and security admins, not developers.  Developers aren't usually the ones monitoring production websites.  The current reporting mechanism integrates better with existing server logging technologies, and can be deployed universally across an entire website w/o require explicit developer support in every page (an advantage of using headers to deliver policies in general).  One major benefit of CSP is that server admins can deploy policies with confidence that they will be applied consistently to all HTML, which can help detect when new code is deployed that violates the existing policy (and associated security assumptions).  I'm generalizing, but in-content solutions tend to rely on dogmatically consistent implementation on the part of developers... which is a problem.

I'm not 100% sure here, but we do report at least some CSP violations in the developer console, to support web developers during development and testing cycles.  I'm not sure offhand if that's just parsing errors or policy violations as well.  In-code error checking would certainly be an additional benefit, but does not provide the same functionality and benefits as server reporting, so would likely add complexity to the model vs. reducing it.
Received on Saturday, 22 January 2011 07:06:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC