Re: Rechartering WebAppSec -- call for input

Hi all,

I haven't contributed too much to the group so my opinion doesn't carry
much weight, but I would like to suggest a couple of areas which I think
will be important for developers, but aren't explicitly captured in the
current charter.

1. A mention of script injection / XSS and ways to prevent exploitation or
reduce its impact. In a way it's implicit from the discussion of isolation
and restricting dangerous features, but it's a large enough concern for
many applications that it might be worth calling out more directly.

2. Providing features to replace current injection-prone DOM APIs or
provide other security functionality in the browser. This touches on the
previously discussed concept of SafeNode and in-browser HTML sanitization
as well as ideas to provide the equivalent of strict contextually
autoescaping templates (http://queue.acm.org/detail.cfm?id=2663760), and
other features to mirror the capabilities of server-side mechanisms.

3. Tackling some of the long-standing problems of the web platform such as
cache sniffing and various other cross-origin data leaks and side channels
(e.g. detection of HTTP response sizes or other sensitive information from
authenticated responses). I don't think we're anywhere near solving these
problems, nor am I convinced that we can do so, but a man can dream ;-)

Just my two cents...

Cheers,
-Artur

On Wed, Oct 19, 2016 at 11:53 PM, Wendy Seltzer <wseltzer@w3.org> wrote:

> Hi WebAppSec,
>
> The group's current charter expires at the end of 2016, so we in the W3C
> team want to help you to scope a new one to continue work.
>
> We should look at the current scope and deliverables in
> https://www.w3.org/2015/03/webappsec-charter-2015.html
> If the existing scope continues to capture the work we want to do, we
> don't need to change it, but we at least need to update the list of
> deliverables and milestones.
>
> Thanks!
> --Wendy
>
> 2015-16 Scope:
> Modern Web Applications are composed of many parts and technologies.
> They may transclude, reference or have information flows between
> resources at the same, related or different origins. Due to the
> historically coarse-grained nature of the security boundaries and
> principals defined for such applications, they can be very difficult to
> secure.
>
> In particular, application authors desire uniform policy mechanisms to
> allow application components to drop privileges and reduce the chance
> they will be exploited, or that exploits will compromise other content,
> to isolate themselves from vulnerabilities in content that might
> otherwise be within the same security boundaries, and to communicate
> securely across security boundaries. These issues are especially
> relevant for the many web applications which incorporate other web
> application resources (mashups). That is, they comprise multiple origins
> (i.e., security principals).
>
> Areas of scope for this working group include:
>
> Attack Surface Reduction
> The WG will design mechanisms to allow applications to:
>
> Restrict or forbid potentially dangerous features which they do not
> intend to use
> Govern information and content flows into and out of an application
> Isolate themselves from other content which may contain unrelated
> vulnerabilities
> Sandbox potentially untrusted content and allow it to be interacted with
> more safely
> Uniquely identify application content such that unauthorized
> modifications may be detected and prevented
> Secure Mashups
> Several mechanisms for secure resource sharing and messaging across
> origins exist or are being specified, but several common and desirable
> use cases are not covered by existing work, such as:
>
> Allowing child IFRAMEs to protect themselves from "clickjacking"
> Providing labeled information flows and confinement properties to enable
> secure mashups. This is especially relevent for, e.g. applications
> communicating between security principals with different user-granted
> permissions (e.g. geolocation)
> Manageability
> Given the ad-hoc nature in which many important security features of the
> Web have evolved, providing uniformly secure experiences to users is
> difficult for developers. The WG will document and create uniform
> experiences for several undefined areas of major utility, including:
>
> Treatment of Mixed HTTPS/HTTP Content and defining Secure/Authenticated
> Origins for purposes of user experience, content inclusion/transclusion
> and other information flows, and for features which require a verifiably
> secure environment
> Providing hinting and direct support for credential managers, whether
> integrated into the user-agent or 3rd-party, to assist users in managing
> the complexities of secure passwords
> Application awareness of features which may require explicit user
> permission to enable.
> In addition to developing Recommendation Track documents in support of
> these goals, the Web Application Security Working Group may provide
> review of specifications from other Working Groups, in particular as
> these specifications touch on chartered deliverables of this group (in
> particular CSP), or the Web security model, and may also develop
> non-normative documents in support of Web security, such as developer
> and user guides for its normative specifications.
>
>
> --
> Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
> Strategy Lead, World Wide Web Consortium (W3C)
> https://wendy.seltzer.org/        +1.617.863.0613 (mobile)
>
>
>
>