WebAppSec Teleconference 3-Nov-2014 -- 03 Nov 2014

<bhill2> zakim aadd is jww

<bhill2> scribenick: dev

<bhill2> scribe: Devdatta Akhawe

Minutes Approval

<bhill2> RESOLVED by unanimous consent: minutes from TPAC are approved

Agenda Bashing

<bhill2> bhill2 adding item: David Ross and Terri Oda to follow up on EPR

TPAC Summary

EPR follow-up from David Ross and Terri Oda

EPR / dross

<bhill2> scribenick: bhill2

<dev> does david have a irc handle ?

dross: Spent some time going thru web app manifest

<mkwst___> dev: drx-goog

dross: we could use that

<mkwst___> or dross. :)

<dev> ok .. bhill2 is scribing .. sorry :)

dross: but would still need a header to tell the browser that EPR is enabled for this site
... currently this works by sending a synchronous request
... lots of pushback on that by browsers for perf reasons
... thinking about ways to work around that
... started discussion of that, just moved it to webappsec list
... can discuss further there, possible to avoid any synchronous requests
... idea there is basic level policy that comes with the header
... mitigates xss in scenario where manifest is not yet loaded
... overall manifest spec makes a lot of sense to hold EPR manifest
... still requirement for a response header, whatever it is called

terri: talked to folks at sysapps about implementation of manifest
... one thing holding up implementation was knowing exactly when and how it
... needs to be loaded so we should talk to them about that, whether it should be
... sync for package apps
... similar proposal dead in water b/c of this, will probably be pushback

devditz: earlier version of CSP had synchronous fetch of policy-uri
... got booted for similar concerns

dev: for CSRF, reasonable to say it's only needed once you've visited site and have a cookie

drx-google: no way to do anything in that case anyway, no info at all when first request is sent
... not authN until actually interacting, should have manifest by then

dev: we already have CSP...
... no story for CSRF, EPR can help there

terri: we do have Origin header

dev: is anyone implementing?

<inserted> scribenick: mkwst___

bhill2: Origin header is mandatory for CORS.

dveditz: CORS has different behavior when you do redirects, useful for CSRF.

<bhill2> dveditz: problem is that cors truncates on redirects, so not useful for other things

bhill2: regarding XSS. of that 20% which could be prevented by EPR, how much could be prevented by CSP?

dross: Lots of overlap there.
... reflected XSS can be mitigated with CSP.

dveditz: how does EPR help for stored XSS?

<bhill2> dveditz: does EPR help for stored XSS?

dross: It does not.

dveditz: CSP can help with stored XSS.
... CSRF mitigations are valuable, as we have XSS mitigations with CSP.

bhill2: should give clear guidance to authors as to which (EPR or CSP) they should use and why, given overlap.

dross: Can determine what that guidance should be.
... In packaged applications, if you want unsafe-eval, you could do that and still use EPR to mitigate the threat.
... There's value in having another option.

<bhill2> dveditz: other thing is to consider how this works with priority of constituencies

<bhill2> ... have run into issues with CSP on that, EPR could be worse

<dveditz> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

bhill2: <explains PoC> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
... How much of EPR should live in this group?
... joint deliverable with sysapps/webapps?
... would like to get away from the tradition of monkeypatching.

terri: not entirely clear how the manifest spec is working.

bhill2: dross, can you introduce your proposal to Marcos, et al?
... how would they feel about adding this to Manifest? which venue would they prefer?

dross: sure.

Re: Frame Ancestors and Referrer

bhill2: objecting generally to idea of a "none" referrer policy.

<dev> no

bhill2: does anyone else object to "none"?

dveditz: I have some concerns
... but everywhere folks rely on referrer, they're already unhappy.

bhill2: don't want to close it out here, if no one wants to represent that side, let's punt back to the list.

Re: [SRI] To trust or not to trust a CDN

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0238.html

bhill2: <summarizing thread>
... trending towards conclusion that defense in depth is a good thing.
... punted the idea of applying hash source to out-of-line content.
... investigate for CSP vNext?

dveditz: SRI spec uses ni:/// syntax, why couldn't we treat those as a scheme source expression?

<bhill2> dveditz: can we use ni:// url as a construct like we do blob: or data: ?

<bhill2> dev: question is do we need to to it right now?

dev: do we need to do it right now?

<bhill2> dev: what is size of the policy at that point... keep adding hashes too?

<bhill2> dveditz: have to whitelist CDN, so whitelist specific path, ...

<bhill2> .. or just put the hash in

<bhill2> ... it'd be long, and icky, but if you care that's what you could do

<bhill2> jww: there is currently a way to handle all these cases

<bhill2> ... we don't need to worry about it yet

bhill2: does the URL production for level 2 forbid NI?

<bhill2> mkwst: fairly certain ni:// scheme could be used in a source expression and that would work

mkwst: ni would work as a scheme source expression

<bhill2> bhill2: just a scheme source?

<bhill2> mkwst: triple slashes would cause problems, no authority section

<bhill2> ... only could whitelist all ni: as a scheme

bhill2: will create an issue to track the idea.

<bhill2> ISSUE can we produce a full ni:/// uri as a CSP source?

CfC: Mixed Content to Last Call?

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0182.html

bhill2: there's a CfC. discussion on the mailing list.
... any questions for folks who like to talk and not type?
... note that last call means there's still room for comments.

<dveditz> why does rfc 6920 introduce '///' for ni:?

<dveditz> it's not a hierarchical scheme

dveditz: it can be.

ni: //[authority]/[digest]

we're not using that.

but there's no reason we couldn't...

Minimum viable SRI

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0184.html

<dveditz> ah, didn't read far enough

FYI: Starting on CSP Next.

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0176.html

Do we want a way to hash data: and blob: uris?

<terri> not an objection, but I want to note that I was hearing a lot of hopes for SRI outside of webappsec and some of the use cases may be broken in the minimum-viable. should be interesting as we trim things down.

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0171.html

<dveditz> terri: can you send a summary of those use cases?

bhill2: will let us know what we should focus on for next iteration.
... manifest. blob: data:. they want to whitelist a specific data URI in CSP without whitelisting data as a scheme.
... perhaps we could use hash sources for data: or blob: contents.

<inserted> scribenick: bhill2

dev: ties into how do we specify ni:/// etc... presumably their use case would be solved

bhill2: could be simpler....

dveditz: if there is hash in policy, would have to hash all data: uris?
... potentially a perf hit for all script attributes
... would be useful, most obvious is with SRI integration

ISSUE explore how to identifiy specific data: uris, etc. more granular than scheme

dveditz: more worried about blob

ACTION-196: Remove intranet/internet section

from Mixed Content spec

http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0155.html

mkwst: would be unfortunate to let this drop on the floor, interest from Chrome in blocking access to private networks
... lot of things problematic about allowing that access
... more to consider than blanket restrictions than were in MIX
... so not a problem to remove it from MIX
... but would be a problem to remove it without a plan to resolve it.

terri: talking to folks about web of things there is more of a need than people realize
... we can reopen perhaps?

bhill2: we can bring this to attention of web of things interest group
... possibly get requirements or problem defintion from them

[CSP] Implementer differences: window.open

http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0237.html

kevinHill: does window.open for about:blank inherit origins?

mkwst: this is a bypass and I'll need to look at chrome's impl to match what FF is doing

- DRAFT -

WebAppSec Teleconference 3-Nov-2014

03 Nov 2014

Attendees

Contents