Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
mozilla.dev.security
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Content Security Policy Spec questions and feedback
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Daniel Veditz  
View profile  
 More options Jul 8 2009, 1:05 pm
Newsgroups: mozilla.dev.security
From: Daniel Veditz <dved...@mozilla.com>
Date: Wed, 08 Jul 2009 10:05:11 -0700
Local: Wed, Jul 8 2009 1:05 pm
Subject: Re: Content Security Policy Spec questions and feedback
Print | View thread | Show original | Report this message | Find messages by this author

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.

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google