Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 86AA817655 for ; Thu, 19 Feb 2015 22:26:31 +0000 (UTC) Received: (qmail 91258 invoked by uid 500); 19 Feb 2015 22:26:26 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 91215 invoked by uid 500); 19 Feb 2015 22:26:26 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 91202 invoked by uid 99); 19 Feb 2015 22:26:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Feb 2015 22:26:25 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates 209.85.220.181 as permitted sender) Received: from [209.85.220.181] (HELO mail-vc0-f181.google.com) (209.85.220.181) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Feb 2015 22:26:01 +0000 Received: by mail-vc0-f181.google.com with SMTP id im6so2283080vcb.12 for ; Thu, 19 Feb 2015 14:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=R8cgvP7brqsw1sxQUpdN8SMw8wmnsAQaWhlhAERxidw=; b=gdxVuA7w1oKHVUOWmKfRIZW8BoxXChWzi2UEwuCLxiGWkxGLP6meBmejHh3On8Ldvm YfOetpllleaeh9rshPY4cA07Owd81A50c6IReYZJWI2qEXNY4kz+kdmsfQcu5u/iHkhD HssIf45v6aEYvKMxEEJsmkhMLPxSxM0S6GkUBJ1pzvOcoNGfn3cRzWW15vreWCfsi2Vj Cppy6kHT7/3YM1A+2xFHUHyn+gClQXY9z33Wbt4Zv6y/2gWqURtzz6m2W9ZnBBYmS6bk 4Z2ncLLkz7vCooN2XpZr7tWloRmGpY/xVjijkQ5gdKqrVa8G2+PMIaNGDJ7mVvkyRQXM hfeA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=R8cgvP7brqsw1sxQUpdN8SMw8wmnsAQaWhlhAERxidw=; b=MD8OCW5gbJOcyIRfsYmzu3kMrV911W3DkU+eCQtqeB+LbyuoaQ3a9JKW9xwKSMPmMI K30vHhXHfKXZAMLa2vQU0Y8l4T8rn0W/QlNZE10XFPbSeioai6312SdubCEliP8igVye OVF4PiulqHsUXbgwuyhi+T6cl6lkVZPbYcrTo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=R8cgvP7brqsw1sxQUpdN8SMw8wmnsAQaWhlhAERxidw=; b=HWzOK9mF+IyzA+94OmONueICdMFDMYQfkyRdu4XXz7mNVDiFv8vG6YAWjki8PuiIyv 8Bcj8VqBoYCXLIL1js1g4isAq/h+m5xvOOKNi1Js5HIFlNh0hD1k2CiGVV9LSz0vwz4Z yPUdMR6tQT4yvNMMRTUTgLNq9oKtSR8Bw+QHUoIik3/cjx4wCpfEYhSbmHJagMaUqsZ4 R75h7wQPuyuRZ8AC0LWdSwMR/NAtqsiCWGpsDiT32ecAZzlTI3RWY7SaMJTPuI5psN4q OSQOO/WHT7e40QqkSU0Cp4RNueyThrS6IZ9sku3S4LuhAaB/hR8Y5wpLVRKtL8BrVDgr GzQQ== X-Gm-Message-State: ALoCoQkMUjzvnS5bG60NOtzy0bWUbB5/XxzsmRMNS3WU2IBa2y546jMKbG0p55Pf1U1XkQX+ydM9 X-Received: by 10.52.243.41 with SMTP id wv9mr3640830vdc.20.1424384714181; Thu, 19 Feb 2015 14:25:14 -0800 (PST) MIME-Version: 1.0 Sender: mmocny@google.com Received: by 10.52.1.229 with HTTP; Thu, 19 Feb 2015 14:24:54 -0800 (PST) In-Reply-To: References: From: Michal Mocny Date: Thu, 19 Feb 2015 17:24:54 -0500 X-Google-Sender-Auth: DGFCbAhRu1iG-QD8oEv8TT7y5aQ Message-ID: Subject: Re: Proposal for CSP support To: dev Content-Type: multipart/alternative; boundary=001a11340138e9a3e2050f786803 X-Virus-Checked: Checked by ClamAV on apache.org --001a11340138e9a3e2050f786803 Content-Type: text/plain; charset=UTF-8 Thanks for this clear outline. Jason, I know you've been working on the short-term items for a while as part of your investigation, fixing things as you went -- what is the current state of CSP support in platforms / plugins? What portion already has fixes (or PR for them), what work is known but undone, and what hasn't been investigated much at all? -Michal On Thu, Feb 19, 2015 at 4:55 PM, Jason Chase wrote: > I'm interested in full-blown support for CSP (Content Security Policy) in > Cordova. While we're close to having new and improved whitelist > functionality, there are gaps in what the whitelist is able to protect > against. In particular, inline script and eval() are higher risks that are > not addressed by whitelists. > > Many Cordova apps may use only static content, or not include any > third-party content. However, there are certainly examples of apps that > need to include user input/third-party content, mixed with the app's own > HTML content. In some cases, platforms may even restrict functionality > (see [1]). I think CSP is a compelling answer for these scenarios, and for > security in general for apps. > > Assuming CSP support is valuable, the question is how to implement? > Support for CSP is not universal across platforms. It is known to be > supported on Android (KitKat and later), iOS (since 7.1), and Firefox. > Where supported, it is typically via a HTTP response header, or a META tag > in the document. > > I've done some investigation into feasible approaches. As a result, I'm > proposing as below. > > Long term goal: > Cordova supports CSP in apps *and* plugins, and is enabled/secure by > default. Ideally, CSP rules can be configurable and automatically applied > to all content (i.e. so developers can fall into the pit of success) > > Achieving this goal will likely require incremental progress over a number > of releases. At a high level, first make changes so developers can > manually apply CSP to their apps. Longer term, add support for > configurability and automatic application of CSP. > > Short term plan: > - Change new app template to contain CSP meta tag with a default, secure > policy (i.e. no inline script, eval(), only local app content) > - Remove any blockers to default policy from framework and core plugins. > This would be a continuation of the work in CB-8210, applied to other > platforms. For example, this would fix any framework code that relies on > sending javascript to be executed inline, from the native side > - Deprecate any framework APIs that allow less secure practices. Many > already are marked as deprecated (at least on Android) > - Update docs/samples to include CSP, and clearly state that use of inline > javascript is deprecated > > Long term plan: > - In a future major release, remove the previously deprecated framework > APIs > - Define/implement a configuration model for CSP rules > - Implement a build/package step to apply configured CSP rules to all > content as meta tags. Run-time support involves re-writing content, and/or > intercepting resource requests. The feasibility of intercepting requests > is highly variable across platforms, at greater cost/complexity than > build-time. > > I'm very interested in any comments on this proposal. This includes > questions around use cases (missing or otherwise), different requirements, > technical concerns, .etc. > > Thanks, > Jason > Google Cordova Team > > [1] http://callback.markmail.org/thread/yxmmya2o2lc26tpi > --001a11340138e9a3e2050f786803--