Re: WebAppSec WG Mid-Year F2F 05/16-17 Agenda (plain text)

On 2016-05-16 16:27, jeff.hodges@kingsmountain.com wrote:
> In case other(s) might find this useful..

Jeff,
I can just reiterate my request for TAG or WebAppSec looking into native app access.

IMO it is a serious mistake mixing in-browser extensions (like Chrome extensions)
with schemes for accessing native applications from the Web:
https://www.w3.org/community/browserext

Why is that?  Because the use-cases and security implications are entirely different.

Anders



>
> WebAppSec WG
> Mid-Year F2F 05/16-17
>
>
> Day 1: 16-May-2016 / 9:00 AM - 5:00 PM
> Mozilla HQ, 331 E. Evelyn Ave Mountain View, CA
>
> ATTENDEES
> Dan Veditz, Mike West, Brad Hill, Francois Marier, Deian Stefan, Richard
> Barnes, Emily Stark, Joel Weinberger, Devdatta Akhawe, Tanvi Vyas, Wendy
> Seltzer, John Wilander, Frederik Braun, Arthur Janc, Jeff Hodges, Daniel
> Bates, Chris Palmer, Raymes Khoury
>
> Regrets
>
>
> 09:00 - 09:30 Welcome, introductions
> 09:30 - 10:30 CSP2 Feedback from Apple (Daniel Bates)
> 10:30 - 11:15 Secure Contexts and related
>
>       * Spec status update (Mike West)
>
>       * Synchronized Security State Between Tabs (John Wilander)
>
>          * Currently, failed security checks (cert validity, mixed
> content …) in one tab/window do not affect other tabs under the same
> origin. However, a compromise of one tab can harm other tabs since
> stateful mechanisms such as cookies and local storage are shared per
> origin. We would like to discuss synchronized security state, for
> instance removing padlocks for all open tabs under an origin if any tab
> under that origin loses its padlock. This of course raises the question
> "Has this origin ever lost its padlock?" and whether that should affect
> security status and stateful mechanisms.
>
>     * Disallow Mixed Trust for Extended Validation (John Wilander)
>
>        * The rules for being granted the Extended Validation (EV) “green
> bar” are fairly lax. You pay a CA, they check your identity, and then
> browsers signal to users that this is trusted content. We would like to
> discuss the issue of mixed trust where content is loaded from servers
> with a variety of identities and certificates. EV rules could for
> instance be restricted in three steps:
>
>           * Start with console warnings of mixed trust and evangelize
> the upcoming change in policy.
>           * Deny EV treatment for mixed EV+non-EV content.
>           * Deny EV treatment for mixed EV content. I.e. only display
> the green bar if all content is EV and from the same organization.
>           * This discussion needs to be synched with the CAB Forum down
> the road.
>
>
> 11:15 - 12:00 CORS and private IP address ranges
> (from Mike West, Crispin Cowan)
> https://mikewest.github.io/cors-rfc1918/
>
> Modifications to Fetch which are intended to mitigate the risks
> associated with unintentional exposure of devices and servers on a
> client’s internal network to the web at large.
>
> 12:00 - 13:00 Lunch
>
> 13:00 - 14:00 Guest speaker: Zach Tollman from Wired: Implementer report
> on adopting HTTPS
>
>
>
> 14:00 - 15:45 Permissions in Context (3 major related topics)
>
>     Permission Delegation to Iframes + CSP embedded enforcement (from
> Chris Palmer and Raymes Khoury)
>
>     * https://noncombatant.github.io/permission-delegation-api/
>     *
> https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit
>     *
> https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0041.html
>     *
> https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/thread.html#msg34
>     * https://w3c.github.io/webappsec-csp/embedded/
>
>
> Secure Context Components (from John Wilander)
>
>     The Secure Contexts spec could become an effective way to allow
> privileged execution in the browser. We’d like to discuss whether Secure
> Contexts could have “components" so that privileged APIs could require
> (named?) subsets of them. Specifically, we’d like to discuss the
> following concepts as such components, in no particular order:
>
>     * No mixed trust (across EV/non-EV/insecure context “same-origin”
> frames/tabs)
>     * Only subresources from associated domains as discussed above.
>     * Signed web app as discussed above.
>     * CSP in place without unsafe options.
>     * Subresource Integrity for all applicable subresources.
>     * Token binding in place
> (https://tools.ietf.org/html/draft-ietf-tokbind-protocol-05).
>
>
> Feature Policy
> https://igrigorik.github.io/feature-policy/
>
>
>
> 15:45 - 17:00 Survey of current WebAppSec Portfolio (from Mike West and
> Brad Hill)
>     * What are the priorities of in-flight work?
>     * What things have highest interest by user agent implementers? Are
> there things unlikely to see interoperable implementations?
>     * Do we have room for new areas of work?
>     * What threat models are we targeting?
>     * Signed Web Apps proposed work area by Apple
>     * HSTS priming
>
>
>
>
> AGENDA - Definite topics
>     * Suborigins
>     * Subresource Integrity
>     * COWL
>
>
> AGENDA - Potential topics
>     * Report from Web Authentication WG
>     * Referrer Policy
>     * UI Security / VisibilityObserver
>
>
>
>
> Day 2: 17-May-2016 / 9:00 AM - 5:00 PM / Mozilla HQ, Mountain View, CA
>
> ATTENDEES
> Dan Veditz, Mike West, Brad Hill, Francois Marier, Deian Stefan, Richard
> Barnes, Emily Stark, Joel Weinberger, Devdatta Akhawe, Tanvi Vyas, Wendy
> Seltzer, Frederik Braun, Jeff Hodges, John Wilander
>
> Regrets
>
>
> 09:00 - 10:30
>
>
> 10:30 - 11:00 CSP 3 ‘unsafe-dynamic’ and ‘unsafe-hash-attributes’
> proposals (Mike West)
>
>
> 11:00 - 12:00 Credential Management (Mike West) and report on the work
> of the Web Authentication WG / FIDO (Jeff Hodges)
>
>
> 12:00 - 13:00 Lunch
>
>
> 13:30 - 14:30 WebAppSec and the IETF
>
>     * Report on work in-flight at IETF today.  (Cookie policy by Mike West)
>
>     * Proposals which are on the border between these organizations:
>
>        * Restrict Accept, Content-Language, and Accept-Language (from
> John Wilander)
>           * Some standard request headers are currently not very
> restricted in what characters they can contain, for instance Accept,
> Content-Language, and Accept-Language. It varies between browsers but
> those three have few restrictions. Looking at RFC 2616 (HTTP 1.1) and
> the Header Field Definitions
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1) one
> gets the impression that the named headers are validated by the browser
> according to the grammar but they’re not.
>
>           *    Supposedly, browser vendors settled years ago on the more
> relaxed Ajax spec which refers to field-value production, specified in
> RFC 2616, Section 4.2:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2. A general
> web client that wants to be standards compliant will use the headers
> spec to restrict its values and a defensive server will use the spec for
> input validation. But browsers are not restricting these headers very
> much (at least not the last time I checked).
>
>           *    Since they are standard headers they can be set in
> non-preflight CORS requests and potentially trigger bad behavior
> server-side, including payloads for vulnerabilities like Shellshock.
>
>           *    Some other working group might be the right place but we
> wanted to start this discussion in WebAppSec.
>
>
>        * Associated Domains (from John Wilander)  (Jeff Hodges can
> discuss DBOUND work at IETF which is related)
>
>           * The technical notion of cross-origin differs significantly
> from the notion of ownership and control of domain names. A few examples
> are {apple.com, icloud.com, filemaker.com}, {google.com, google.ru,
> youtube.com, gmail.com}, {facebook.com, instagram.com, facebook.net},
> {microsoft.com, xbox.com, microsoftstore.com} and {mozilla.com,
> firefox.com}. Single sign-on, subresource integration, and user agent
> tracking is arguably very different within one of these sets than across
> them. If we could come up with a standardized way to state and validate
> associated domains we could enforce better cross-origin policies.
>
>
> 14:30-17:00 Spec updates on SRI, Suborigins and COWL, AOB
>
>     * SRI
>        * Require-sri-for
>        * Integrity for downloads
>        * Cross-origin caching
>        * Other v2 features?
>        * Of note: https://martinthomson.github.io/http-mice/ (Merkle
> Integrity Content Encoding)
>
>     * Suborigins
>        * Cookies
>
>     * COWL
>        * Welcome new editor Niklas Andréasson
>        * ServiceWorkers and Push
>
>
>
>
>
>
> end
>
>
>

Received on Tuesday, 17 May 2016 04:04:30 UTC