See also: IRC log
<bhill2> fuck you, zakim
<bhill2> suggested background reading for first agenda topic: http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0011.html
<bhill2> https://github.com/eoftedal/csp-testing
<bhill2> bhill2: when are implementers turning on un-prefixed header
<bhill2> dveditz: hope is to get it turned on for this release cycle, ~3 months to release
<bhill2> dveditz: be in beta channels earlier, and some fixed for spec compliance needed
<mkwst> bhill2: We just landed the unprefixed header in WebKit yesterday. I'd expect it to hit Chrome 25; so also ~12 weeks away. (I'll join the call in just a bit; just walked in the door)
<mkwst> We also expect some bugfixing to be necessary as it goes through dev/beta, but hopefully nothing major.
<bhill2> are you dialed-in, Mike?
<mkwst> Just about to be.
<scribe> scribe: puhley
bhill: Art discussing joint
meeting with WebApp WG in Silicon Valley.
... Not sure if there is enough work for a full 1-2 day
workshop.
dveditz: Mozilla is still working on test cases for CSP. Currently, built-into the Firefox build process.
<bhill2> ACTION: bhill2 to propose testing day as part of joint HTML/WebApps/WebAppSec F2F in silicon valley to list [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action01]
<trackbot> Created ACTION-91 - Propose testing day as part of joint HTML/WebApps/WebAppSec F2F in silicon valley to list [on Brad Hill - due 2012-11-09].
bhill: We need to identify where more test cases are needed beyond erlend's proposed cases.
mwest: We have layout tests. HTML files that are potentially usable in the W3C style. Most of the tests are currently doing console logging versus JS logging.
bhill: Might be able to write server-side code to work around the issue.
<mkwst> http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/contentSecurityPolicy/ are the current tests.
mwest: Some Perl scripts to
verify report was generated.
... They rely on the fact the entire render tree is dumped and
need work to make them JS compatible.
... Volunteers to be test coordinator.
... May be able to attend Silicon Valley meet-up with HTML
WebApp WG if we set one up with advanced notice.
... Erland's test suite focuses on the core functionality
around "-src" policies. No testing around properties like
sandbox.
... WebKit probably has some test cases on sandbox and
report-uri. They don't have a really thorough test suite for
ensuring sandbox works for all possible variants.
bhill: Perhaps we should ask Microsoft to see if they have test cases they can donate.
<bhill2> ACTION: jrossi to inquire about Microsoft test cases for sandbox directive to contribute to W3C [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action02]
<trackbot> Sorry, couldn't find jrossi. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
bhill: Official go ahead from W3C
to publish CSP 1.0 as candidate req on the 6th.
... We want to get CSP 1.1 to first public working draft.
mwest: CSP 1.1 is ready for first public working draft.
<bhill2> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html
mwest: New CSP 1.1 features are
as follows:
... First new item is meta implementation to allow CSPs in Meta
tag.
... Implemented in WebKit and roughly stable.
dveditz: sandbox is about that
resource being used from somewhere else.
... ui-safety is more of an outgoing policy
... sandbox might difficult to support in a meta tag.
... need to know some things before renderring.
mwest: You wouldn't be able to block the entire load of the page but you could stop the process before something interesting happens.
<mkwst> http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Document.cpp&exact_package=chromium&q=x-frame-options&type=cs&l=2956 <-- x-frame-options inside a document's meta tag.
bhill: X-Frame-Options is ignored in the meta tag
mwest: We should describe in the
non-normative section of the spec where there will be variants
in the behavior when the field is supplied in the meta
tag.
... Will bring the options for putting that in the spec to the
mailing list.
<bhill2> ACTION: mkwest to propose changes to the list about making some directives optional to support in the META tag [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action03]
<trackbot> Sorry, couldn't find mkwest. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
dveditz: Does the spec require meta tags to be in the head of the document?
mwest: It is listed as a to-do in
the spec but it is their.
... Policies are ignored once the document has reached a ready
state.
tanvi: Does it need to be before head tags such as CSS which include JavaScript.
mwest: OK with making it a requirement that it needs to be the first entry in the head tag.
<tanvi> mwest - charset should go before/after the meta tag?
mwest: Google in process of trying to get some company properties to use CSP but it is a difficult transition. Need to support use case where meta tag can be used after a load event but before asynchronous interactions.
<mkwst> tanvi: probably after, since the charset could theoretically impact the way the policy is interpreted.
<bhill2> ISSUE: how to address dynamic application of CSP post page load / partial page load via META or script interface
<trackbot> Created ISSUE-30 - How to address dynamic application of CSP post page load / partial page load via META or script interface ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/30/edit .
mwest: Scripting interface is
read-only but it has been proposed to allow JavaScript to
modify the policy.
... Next experimental feature is to allow paths in rules.
bhill: Is currently non-normative
instead of experimental.
... W3C is currently debating URI parsing. May need to
cross-reference with their work.
dveditz: Does the spec explicitly require hierarchical schemes.
mwest: Not at the moment. Only specifies schemes:
dveditz: May need to address schemes with slashes.
mwest: Curent spec doesn't allow for that use case.
<mkwst> Current 1.1 spec references http://tools.ietf.org/html/rfc3986#section-3.1 which defines schemes as `ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )`.
<bhill2> ISSUE: what specification's definition of URL/URI are we using for path parsing in CSP 1.1?
<trackbot> Created ISSUE-31 - What specification's definition of URL/URI are we using for path parsing in CSP 1.1? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/31/edit .
<bhill2> ISSUE: do we specify that path-specificity applies only to hierarchical URI schemes?
<trackbot> Created ISSUE-32 - Do we specify that path-specificity applies only to hierarchical URI schemes? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/32/edit .
bhill: CSP spec should specific
enough that it can be consistent across all browsers.
... (with regards to URI parsing)
mwest: Parsing a URI for CSP is already different than how normal URLs are parsed in general.
<dveditz> rfc 3986 defines paths as part of URLs that have a hier-part
<tanvi> dveditz: if it starts with two slashes its hierarchical, and if it doesn't than it isn't. for csp we probably don't deal with exotic types, so could just reference rfc 3986.
<tanvi> dveditz: we have blob and other things that are standard but not hierarchical. what do we do if we want to block those or not block those. 1.0 spec doesn't really address them, they are just allowed
<tanvi> mwest: webkit taking position that they are the same as 'self' and allowed when 'self' is allowed. since only created and accessible within context of an origin
<tanvi> we should address it in the 1.1 spec, so consistent across implementors
<bhill2> ISSUE: need to address blob, data, filesystem URL types with greater specificity in CSP 1.1 spec
<trackbot> Created ISSUE-33 - Need to address blob, data, filesystem URL types with greater specificity in CSP 1.1 spec ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/33/edit .
<tanvi> mwest - file system api. sandboxed file system associated with an origin (like indexeddb). In webkit
<bhill2> ACTION: dveditz to propose spec text to resolve ISSUE-32 [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action04]
<trackbot> Created ACTION-92 - Propose spec text to resolve ISSUE-32 [on Daniel Veditz - due 2012-11-09].
mwest: Currently not saying
anything about queries but we could say that we are explicitly
ignoring queries.
... WebKit is throwing a warning that queries aren't accepted
in source expressions and are being ignored.
... Worth noting in the spec explicitly.
<bhill2> ACTION: mkwst to clarify CSP 1.1 spec text to make handling of query strings in source expressions explicit [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action05]
<trackbot> Sorry, couldn't find mkwst. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
<mkwst> mwest2. :)
mwest: Next new feature in 1.1
is: script interfaces which allows read of the union of the
content security policies in effect.
... Some discussion about whether there should be write
compatibilities. WebKit has read-only in Canary and Dev version
of Chrome.
... No known use case for allowing the read of the
report-uri
bhill: If unique report-uris are created for each instance, then an XSS issue could be used to spam the report-uri to hide attacks.
mwest: Should assume that report-uri is public. That said, no known value in exposing to JavaScript.
bhill: Send email to the list to see if anyone is concerned with dropping it.
<bhill2> ACTION: mwest2 to query list if any use cases for reportURIs script interface [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action06]
<trackbot> Created ACTION-93 - Query list if any use cases for reportURIs script interface [on Mike West - due 2012-11-09].
puhley: Depends on whether per-session data in the report-uri to help refine log correlation on attacks.
dveditz: Would custom extension changes be reported in the report?
mwest: Yes. WebKit makes sure
reports go to the URI that is associated with the specific
policy that is being violated in the case of multiple
policies.
... Not sure if there is a good way to distinguish policies
from the page and policy changes by extension.
... Use case for script detection of policies is so that a page
can determine whether eval is allowed.
<mkwst> Specifically, the request came from Angular, which has two implementations of templates: one without eval, and one with eval (which is more performant). They'd like to be able to hop between them.
dveditz: There are concerns about
privacy implications regarding detecting the end-user's
environment and extensions.
... Perhaps make it a request method rather than a read
approach where you get the entire string.
mwest: It is currently
request-orientated.
... I am open to further discussion regarding how much
information needs to provided to JavaScript.
<tanvi> mwest - drop uri from the spec right now. we can discuss whether adding it back is a good idea later.
<bhill2> ISSUE: discuss use cases / risks of script access to CSP information, solicit specific public comment on this feature with FPWD
<trackbot> Created ISSUE-34 - Discuss use cases / risks of script access to CSP information, solicit specific public comment on this feature with FPWD ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/34/edit .
<tanvi> mwest - rest we can leave in for the FPWD and solicit use cases
<tanvi> dveditz - one use case is to find out if anything in a user agent will block a load because of csp
<tanvi> dveditz - not because of adblock or anything else. just on csp blocking the load
<bhill2> ACTION: mwest2 to add specificity to CSP 1.1 draft that script access queries ONLY state of CSP, not general reachability of URLs by configured browser context [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action07]
<trackbot> Created ACTION-94 - Add specificity to CSP 1.1 draft that script access queries ONLY state of CSP, not general reachability of URLs by configured browser context [on Mike West - due 2012-11-09].
<tanvi> dveditz - at mozilla we probably wouldn't want to report what extension supplied csp's say.
<tanvi> tanvi - that could be tricky
mwest: Could allow for an http-only style policy for whether the policy is avialable to JavaScript
<bhill2> ISSUE: should we add an "httpOnly" like directive to CSP to indicate that the state of this policy is not available to the script APIs?
<trackbot> Created ISSUE-35 - Should we add an "httpOnly" like directive to CSP to indicate that the state of this policy is not available to the script APIs? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/35/edit .
dveditz: Jonas suggested that perhaps directives such as font-src should default to style-src instead of default-src when not specified. He will write an email to the list.
mwest: Next new directive is form-action which restricts the URIs can be used as the action of form-elements. Experimental version in Dev and Canary of Chrome but not well tested.
tanvi: What if you want to restrict to just HTTPS URI?
mwest: Should be able to specify similar to any other directive.
group agrees there isn't much value in restricting the form method with CSP.
Group agrees there isn't much value in restricting the mime-type
bhill: Is there value in restricting the scheme such as no mailto: in forms?
<tanvi> dveditz - should form-action fall back to default-src? maybe not.
<dveditz> in fact I'd say almost certainly not -- pages that work fine with CSP 1.0 will break in 1.1
<dveditz> if we say the new form-action falls back to default-src
<tanvi> ah yes, that is true
<dveditz> I was suggesting that the spec should be clear that form-action does NOT fall back
<bhill2> ACTION: mwest2 to correct "font-src" typo in the form-action text of CSP 1.1 [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action08]
<trackbot> Created ACTION-95 - Correct "font-src" typo in the form-action text of CSP 1.1 [on Mike West - due 2012-11-09].
<bhill2> ACTION: mwest2 to add note clarifying that form-action is not subject to default-src fallback [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action09]
<trackbot> Created ACTION-96 - Add note clarifying that form-action is not subject to default-src fallback [on Mike West - due 2012-11-09].
Group questions whether there is value to restrict the schemes due to the fact that there are specs for sites to self-register schemes. This may be an issue for 1.2 instead of 1.1 when more information on those specs is available.
<odinho_> Present odinho ekr bhill tanvi puhley DanD dveditz dbaron mkwst
bhill: Next 1.1 feature is that sandbox is now mandatory for compliance with 1.1 in a user agent.
mwest: Next 1.1 feature is
script-nonce. Nonce is supplied by the server. Script is only
allowed if the script has the nonce, unsafe-inline is allowed
and/or script-src matches.
... Allows whitelisting of inline scripts while still trying to
protect against injected script when unsafe-inline is
specified.
... Assumes that the attacker can't predict the nonce.
tanvi: XSS in white-listed js code could bypass the mechanism.
<tanvi> ekr - maybe include an indicator that determines whether this applies to inline scripts or included scripts
<tanvi> or both
<bhill2> ACTION: ekr to make concrete suggestion to list on allowing script-nonce to apply selectively to inline vs src= scripts [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action10]
<trackbot> Sorry, couldn't find ekr. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
<tanvi> ekr - could combine with script-hash. script-hash becomes script-mac where its keyed with the nonce
<bhill2> ISSUE: are we interested in considering script-hash as a CSP 1.1 directive?
<trackbot> Created ISSUE-36 - Are we interested in considering script-hash as a CSP 1.1 directive? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/36/edit .
<tanvi> how solid is the assertion that the attacker can't figure out the hash. only as solid as the implementation.
mwest: Nonce randomness
protection is determined by the server implementation.
... Last 1.1. feature is plugin-types which limits the types of
resources which can be embedded. There needs to be more
discussion about how this will work in every browser due to IE
ClassID mechanism vs the mime-type approach.
<bhill2> ACTION: jrossi to propose spec text for MSIE plugin implementation of plugin-types directive (e.g. with CLSID vs. MIME types) [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action11]
<trackbot> Sorry, couldn't find jrossi. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
<tanvi> plugin-types - issue with mime types and classids. how should this be handled? question for microsoft. discussed an internal mapping from mime-type to classid, but this wouldn't work for all mime-types (ex: custom corporate plugin wouldn't be in the generic mapping)
puhley: How would an iframe be handled whose src points directly to plugin content.
<bhill2> ISSUE: how to apply plugin-types in CSP 1.1 to iframes
<trackbot> Created ISSUE-37 - How to apply plugin-types in CSP 1.1 to iframes ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/37/edit .
mwest: May not be an issue due to same-origin policy enforcement on the content.
<tanvi> tanvi - without iframe, could end up having a vulnerable plugin type included. perhaps not worried about xss but dont want to include vulnerable plugins.
<mkwst> http://www.w3.org/Security/wiki/Content_Security_Policy
tanvi: May be worth discussing bringing back policy-uri in 1.1. Firefox has support for it.
mwest: OK with adding it as an experimental item for 1.1
dveditz: Spec should specify when policy-uri is appropriate and when it is not.
<bhill2> ACTION dveditz to propose spec language for policy-uri directive
<trackbot> Created ACTION-97 - Propose spec language for policy-uri directive [on Daniel Veditz - due 2012-11-09].
tanvi: Should we look at script-hash?
bhill: Need a decent way to implement it. We haven't figured that out yet.
<tanvi> bhill2 - should we restrict to just the script? what about the headers?
tanvi: What about mixed-content restrictions? It could help websites prevent a bad user experience from accidental mixed-content warnings.
dveditz: Could partially fake it with the https restrictions.
ekr: Browsers are already partially solving this, as well.
tanvi: This is only for active content and not display content.
bhill: We can definitely discuss this further
<bhill2> ISSUE: discuss no-mixed-content further as a 1.1 experimental directive
<trackbot> Created ISSUE-38 - Discuss no-mixed-content further as a 1.1 experimental directive ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/38/edit .
bhill: What about JSONP-Src and JSONP-Sync?
<tanvi> tanvi - browser only block mixed active content. not mixed display content. we wouldn't be able to distinguish between the two with the directive (we would just turn all mixed content off) because the definition of mixed active content differs from browser to browser.
<mkwst> sorry, need to leave this room. 2 seeconds.
<tanvi> IE blocks mixed content iframes, Webkit does not. Mozilla will block mixed content iframes
<bhill2> ACTION: bhill2 to propose spec text for experimental jsonp-src jsonp-sink directives [recorded in http://www.w3.org/2012/11/02-webappsec-minutes.html#action12]
<trackbot> Created ACTION-98 - Propose spec text for experimental jsonp-src jsonp-sink directives [on Brad Hill - due 2012-11-09].
tanvi: What about no-user-js? No attacks seen to justify it. What have others seen?
bhill: Nothing seen from his end.
tanvi: What referrer tag that is implemented as Meta tag in WebKit?
mwest: Would be good to formalize it in either case and worth evaluating.
<tanvi> bhill - would be interesting from userCSP perspective, if a user wants to turn off or referrers for certain sites through CSP addons
<bhill2> ISSUE: discuss CSP relevant use cases for possibly including Meta Referrer as a CSP directive
<trackbot> Created ISSUE-39 - Discuss CSP relevant use cases for possibly including Meta Referrer as a CSP directive ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/39/edit .
<ekr> zakiim, who is here?
<mkwst> Probably.
<mkwst> http://www.w3.org/2011/08/appsecwg-charter.html
bhill: Do we need to additional
scope to our charter for CSP 1.1, etc?
... We are chartered to produce something like policy-uri based
on language within the scope Manageability section.
dveditz: May be covered by the fact that load balancers can manage policies.
bhill: Mashups should still be
the same based on the 1.1 things under discussions.
... We are on track to meet the success criteria of "two
independent implementations" even if some minor details aren't
exact.
tanvi: Happy with the current success criteria even if we aren't precisely there yet.
bhill: Can remove UMP from
deliverables.
... Secure cross-domain framing is the UI Safety
Directives
... Secure Cross-Domain Resource Sharing is CORS.
<bhill2> possibly specing out:
<dveditz> <img src="http://domain.com/evil.png" hash="SHA256:xxxxxxxxxxxxxxxxxxx">
<bhill2> <a href="https://foo.com/something.xyz" fingerprint="sha1:akq32r4;2ql342q4kqj234q32" althref="http://foo.com/something.xyz">
<tanvi> the later provides more performant secure page loads
<tanvi> if the fingerprint fails in the <a> we would request the https resource
bhill: Should we take this on as a change to the charter?
<tanvi> relevant to the script-hash discussion
<bhill2> di:location1;location2;hash
<tanvi> dveditz - would it actually get used?
<tanvi> bhill2 - performance and latency benefits would be so compelling, so likely to use it for that reason
<tanvi> maintains authentication but not privacy
<tanvi> which might be okay if you are going to the paypal home page
<tanvi> ekr - side channel problem for althref.
<bhill2> we have a number of WG members expressing an interest in proposing this as a new deliverable and scope item for the charter
<tanvi> dveditz - origin cookies, same domain cookies
bhill: Took stabs on updating timelines within the charter.
CSP 1.1 dates: FPWD - Nov 2012, LC - July 2012, CR - Sept 2013, PR - December 2013, Rec February 2014
Auth'd Mix Content: Mar 2013, LC - Aug 2013, CR - Oct 2013, PR - Dec 2013, Feb 2014
Change Device API Liaison to Web Crypto Liaison
<ekr> http://www.w3.org/2012/webcrypto/track/issues/21
<gopal> is there a different IRC channel and dial in number for Web Crypto WG
Potentially System Applications WG?
<bhill2> rrsagent make minutes
