Sid Stamm wrote:
> 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.
I had always assumed that if we were going to report anything, it'd be
an inline script attempt -- the heart of most XSS attacks.
> How about this: the report either contains a
> "violated-directive" field or "violated-base-restriction" field.
I'm not keen on the either/or, can we pick one that will serve for both?
There are not many policies that are not directives, we can define in
the spec what we will send for those violations.
e.g.
<restriction>allow none</restriction>
<restriction>img-src *.flickr.com self</restriction>
<restriction>inline script</restriction>
I don't care so much what the tagname is (although
"violated-base-restriction" is a little extreme) as much as I'd like a
consistent report format. All fields should be present (even if empty),
and the same fields every time.
Suggestions for the tag could be
violated-directive // mostly accurate, reporting the implied
// no-inline-script "directive" is OK
violated-policy
restriction
policy // violation implied, else we wouldn't report
>> 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.
I prefer sending the actual policy, I just want the spec to be clear
about what happens.
> Maybe we can compromise and say something like:
> <violated-directive>(allow as img-src) self
> othersite.com</violated-directive>
>
> Thoughts?
I like either of your first suggestions over a wishy-washy sending both.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
