- From: Yoav Weiss <yoav@yoav.ws>
- Date: Tue, 19 Mar 2013 13:11:31 +0100
- To: Mike West <mkwst@google.com>
- Cc: "Hill, Brad" <bhill@paypal-inc.com>, "dveditz@mozilla.com" <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Adam Barth <w3c@adambarth.com>
- Message-ID: <CACj=BEj-jVOpK2ie5orDReeiD8y9XYWw-_EWuPGP2TF3A+EPyA@mail.gmail.com>
+1 for the general idea of making nonces/hashes part of the path rather than a separate directive. It would make them applicable across different directives without extra effort, and as stated would clarify the "or" relationship. Regarding the "ni://" scheme, while it's ideal for hashes, using it with nonces doesn't feel right to me, since (as Mike stated) nonces are not really URLs, and don't represent a single resource. Maybe a separate syntax for nonces (e.g. the suggested "nonce:FDBEBBE"), while using the "ni://" scheme only for hashes? Yoav On Tue, Mar 19, 2013 at 10:17 AM, Mike West <mkwst@google.com> wrote: > I added percent-encoding of ',' and ';' as a requirement in > https://dvcs.w3.org/hg/content-security-policy/rev/78bb54960042. > > -mike > > -- > Mike West <mkwst@google.com>, Developer Advocate > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 > > > On Mon, Mar 18, 2013 at 6:23 PM, Hill, Brad <bhill@paypal-inc.com> wrote: > >> I suppose that is narrowly true, but we do allow in 1.0 that it is OK >> to supply additional path information which will be truncated. If that >> additional information includes a (valid in many URL schemes) ‘;’ >> character, it must be properly encoded.**** >> >> ** ** >> >> *From:* Mike West [mailto:mkwst@google.com] >> *Sent:* Monday, March 18, 2013 11:21 AM >> >> *To:* Hill, Brad >> *Cc:* dveditz@mozilla.com; public-webappsec@w3.org; Adam Barth >> *Subject:* Re: Nonces/hashes in source expressions.**** >> >> ** ** >> >> 1.0 supports neither paths nor nonces. Which values are you concerned >> about?**** >> >> ** ** >> >> -mike**** >> >> >> **** >> >> -- >> Mike West <mkwst@google.com>, Developer Advocate >> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany >> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91*** >> * >> >> ** ** >> >> On Mon, Mar 18, 2013 at 6:19 PM, Hill, Brad <bhill@paypal-inc.com> wrote: >> **** >> >> Given that it is a valid character in use at least some places that might >> show up as directive values, I think encoding is a better answer.**** >> >> **** >> >> I don’t think requiring the additional encoding is a problem, but this is >> probably something we also need to address in the 1.0 CR draft.**** >> >> **** >> >> *From:* Mike West [mailto:mkwst@google.com] >> *Sent:* Monday, March 18, 2013 11:13 AM**** >> >> >> *To:* Hill, Brad >> *Cc:* dveditz@mozilla.com; public-webappsec@w3.org; Adam Barth**** >> >> *Subject:* Re: Nonces/hashes in source expressions.**** >> >> **** >> >> We currently just define the grammar such that ';' can't appear in a >> directive's value: see section 3.2.1 ( >> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#policies >> ).**** >> >> **** >> >> The only place this might be worrisome at the moment is nonce and URL >> paths. I don't have a problem with excluding ';' from the valid nonce >> characters, nor with asking developers to percent-encode ';' as '%3B'. >> Would that sufficiently address the problem, or is there something deeper >> I'm missing?**** >> >> **** >> >> -mike**** >> >> >> **** >> >> -- >> Mike West <mkwst@google.com>, Developer Advocate >> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany >> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91*** >> * >> >> **** >> >> On Mon, Mar 18, 2013 at 6:06 PM, Hill, Brad <bhill@paypal-inc.com> wrote: >> **** >> >> A twitter follower pointed out this is also in data URIs. How do we deal >> with this? >> >> (time to get back to working on tests now that IETF is over...)**** >> >> >> > -----Original Message----- >> > From: Hill, Brad**** >> >> > Sent: Monday, March 18, 2013 10:44 AM >> > To: Hill, Brad; Mike West >> > Cc: dveditz@mozilla.com; public-webappsec@w3.org; Adam Barth >> > Subject: RE: Nonces/hashes in source expressions. >> > >> > I seem to recall that Tomcat uses the ';' to do URL rewriting for >> session >> > management. Not a secure practice, but certainly popular in the 90's. >> > >> > > -----Original Message----- >> > > From: Hill, Brad [mailto:bhill@paypal-inc.com] >> > > Sent: Monday, March 18, 2013 10:39 AM >> > > To: Mike West >> > > Cc: dveditz@mozilla.com; public-webappsec@w3.org; Adam Barth >> > > Subject: RE: Nonces/hashes in source expressions. >> > > >> > > Eww.. yes. But that does point out a potential problem more >> generally in >> > CSP: >> > > >> > > According to RFC3986 section 2.2, ';' is a reserved character as a >> > > subcomponent delimiter. >> > > >> > > Is this going to bite us elsewhere? >> > > >> > > :( >> > > >> > > -Brad Hill >> > > >> > > --------------------- >> > > From: Mike West [mailto:mkwst@google.com] >> > > Sent: Monday, March 18, 2013 10:35 AM >> > > To: Hill, Brad >> > > Cc: dveditz@mozilla.com; public-webappsec@w3.org; Adam Barth >> > > Subject: RE: Nonces/hashes in source expressions. >> > > >> > > One more observation: we can currently safely assume that ';' >> > > separates directives. We could no longer make that assumption with >> > > this format, which would make parsing slightly more complicated. >> > > -mike >> > > On Mar 18, 2013 5:31 PM, "Mike West" <mkwst@google.com> wrote: >> > > Thanks for the link, it's very informative. The only reservation I >> > > have is that it seems to imply a 1:1 relationship between the URL and >> > > the resource being described (modulo collisions). Nonces are meant to >> > > collide, probably multiple times on a single page. >> > > That said, I don't feel strongly about the format. I'd be happy to >> > > adopt that format wholesale, assuming the general idea (which, the >> > > more I think about, the more strongly I favor) is acceptable. >> > > -mike >> > > On Mar 18, 2013 5:19 PM, "Hill, Brad" <bhill@paypal-inc.com> wrote: >> > > <hat type="individual"> >> > > >> > > I like it. >> > > >> > > </hat> >> > > >> > > <hat type="chair"> >> > > >> > > This draft is relevant to consider vs. inventing a new identifier >> > > syntax, though it is less compact than what you suggest: >> > > >> > > http://tools.ietf.org/html/draft-farrell-decade-ni-10 >> > > >> > > </hat> >> > > >> > > Brad Hill >> > > >> > > ------------------------- >> > > From: Mike West [mailto:mkwst@google.com] >> > > Sent: Monday, March 18, 2013 10:04 AM >> > > To: public-webappsec@w3.org; dveditz@mozilla.com; Adam Barth >> > > Subject: Nonces/hashes in source expressions. >> > > >> > > Before I copy/paste a bunch of text to stub out a 'style-nonce' >> > > directive for CSP 1.1, I'd like to run something by you lovely folks >> > > that I think we've talked about once or twice on the calls. It seems >> > > like it could reduce repetition and confusion if we fold nonces or >> > > hashes into the existing directives as another type of source >> expression. >> > > >> > > As a strawman, how would you feel about rewriting 'script-nonce >> > > ABCDEFG' as 'script-src nonce:ABCDEFG'? This would make an "or" >> > > relationship with 'script- src' clear on the one hand, and make room >> > > for something like 'script-src sha1:...' on the other. I think it >> > > would simplify the structure in a nice way, and seems more >> comprehensible >> > and reusable in general. >> > > >> > > I'm sure others of you will have ideas about syntax (perhaps it's a >> > > bad idea to replicate scheme-like structures... maybe '#' would be a >> > > better separator, since it's sometimes read as "hash" anyway), but I'm >> > > hoping the general idea is reasonable. >> > > >> > > >> > > -- >> > > Mike West <mkwst@google.com>, Developer Advocate Google Germany >> > GmbH, >> > > Dienerstrasse 12, 80331 München, Germany >> > > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 >> 91**** >> >> **** >> >> ** ** >> > >
Received on Tuesday, 19 March 2013 12:12:01 UTC