W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2016

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

From: <jeff.hodges@kingsmountain.com>
Date: Mon, 16 May 2016 10:26:19 -0600
Message-ID: <8528c2fcd8f004601e6a0ea45aa25ba8.squirrel@box514.bluehost.com>
To: jeff.hodges@kingsmountain.com
Cc: "W3C WebAppSec WG" <public-webappsec@w3.org>

added an item wrt webauthn to..
some comments on selected 'day 2' items...

> Day 1: 16-May-2016 / 9:00 AM - 5:00 PM
> Day 2: 17-May-2016 / 9:00 AM - 5:00 PM / Mozilla HQ, Mountain View, CA
> 09:00 - 10:30

[ held open for suggestions ? ]

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

[ Add Wendy Seltzer along w/myself :)  ]

WebAuthn had a F2F last Fri 13-May in Berlin. Minutes are here..

[minutes] 13 May F2F (Wendy Seltzer)

see also: Call for Consensus: Publish FPWD

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

WRT the above "Restrict Accept, Content-Language..." item -- Julian Reschke
<julian.reschke@gmx.de> definitely needs to be involved, and the approp
working group may well be the IETF HTTPbis WG..


also, all the refs above are to RFC2616, which has been superseded by RFCs
[7230..7237], where 7230 and 7231 are particularly relevant to the above..


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


dbound problem statement

note that the above "associated domains" scenario from John W is arguably
noted in the latter dbound prob stmt doc thusly..

   Linking domains together for merging
      It is frequently the case that domain names are aliases for one
      another.  Sometimes this is because of an ongoing merger (as when
      one company takes over another and merges operations).  A client
      encountering such a site needs to answer the question, "Is domain
      X just another name for domain Y?"

that said, technical solution work is progressing slowly for various reasons
which we can discuss...

> end
Received on Monday, 16 May 2016 16:27:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC