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
 
Sid Stamm  
View profile  
 More options Jul 7 2009, 8:43 pm
Newsgroups: mozilla.dev.security
From: Sid Stamm <s...@mozilla.com>
Date: Tue, 07 Jul 2009 17:43:38 -0700
Local: Tues, Jul 7 2009 8:43 pm
Subject: Re: Content Security Policy Spec questions and feedback
Print | View thread | Show original | Report this message | Find messages by this author
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


 
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