Hi Dan,
You raise some excellent questions... you know, I hadn't really thought
about what to do about reporting inline script violations. I think the
intention was to just *not run* the violating script, but reporting the
violation is definitely a good idea since much of XSS happens this way.
Daniel Veditz wrote:
> Just jumping off here on a related topic: What do we send as the
> "blocked-uri" when we find inline script? Since this is perhaps the most
> common injection type this would be a good one for an example.
I think we need to send the URI of the protected document as the
blocked-uri, since the inline scripts live in there.
> I suppose we could leave blocked-uri empty and let people infer that it
> was inline script from the violated directive. I'd rather be explicit
> about it, but then "blocked-uri" might be the wrong name. Or do we leave
> the blocked-uri empty (absent, or present-but-empty?) and use a keyword
> like <violated-directive>inline script</violated-directive>
As far as the report details go.... since inline scripts violate a base
restriction of CSP, maybe we should change up the violation report
format a bit. How about this: the report either contains a
"violated-directive" field or "violated-base-restriction" field. If a
directive is violated due to a resource load (like an image), the
"violated-directive" field is sent. If it is a base restriction, such
as inline script, the "violated-base-restriction" field is sent. We can
formalize the names of each base restriction for inclusion in the report.
Here's an example, as I propose:
<csp-report>
<request>GET /index.html HTTP/1.1</request>
<request-headers><![CDATA[
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; ...
Accept: text/html,application/xhtml ...
]]></request-headers>
<blocked-uri>http://myserver.com/index.html</blocked-uri>
<violated-base-restriction>1.0: NO INLINE SCRIPTS</violated-directive>
</csp-report>
And then the new schema would require one of either the
"violated-directive" or "violated-base-restriction" entities.
> For clarification, if the entire policy was "allow self othersite.com"
> and we tried to load an image in violation of that policy, would the
> violated-directive be the implied img-src or the allow fall-back that is
> actually specified? I imagine it would be the allow directive.
There's arguments for both choices:
1. We could send the "allow" directive for ease in figuring out which
directive was violated; this is the most straightforward report.
2. We could send the "img-src" directive: the recipient of the report
may want to know that the blocked URI was requested for display as an image.
Maybe we can compromise and say something like:
<violated-directive>(allow as img-src) self
othersite.com</violated-directive>
Thoughts?
-Sid
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
