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

RE: CSP no-external-navigation

From: Hill, Brad <bhill@paypal.com>
Date: Thu, 1 May 2014 18:06:44 +0000
To: David Saez Padros <david@ols.es>, Mike West <mkwst@google.com>
CC: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E35DA883F@DEN-EXDDA-S12.corp.ebay.com>

  We've added an issue to consider injected META tags.  Scripted redirects should be covered under the many things you must protect against by forbidding unsafe-inline and specifying a correct set of script-src locations.
  Generally we have considered header injection (like 3xx redirects) out of scope for CSP because those  kinds of vulnerabilities usually lead to response-splitting that can separate a response from even the original CSP header and break all defenses.  

  If you want to prevent something like an ad from navigating or redirecting the host page, you can use a sandboxed iframe.


-----Original Message-----
From: David Saez Padros [mailto:david@ols.es] 
Sent: Wednesday, April 23, 2014 8:20 AM
To: Mike West
Cc: Daniel Veditz; public-webappsec@w3.org
Subject: Re: CSP no-external-navigation


> 2. What kinds navigations would you consider "automated redirects"?

mainly window.location and meta http-equiv="refresh", server 3xx rediretcs  and any other scripted redirect (not sure if java, flash or similar can make redirects)

> It
> seems like we'd need an exhaustive list of navigations that we can 
> agree upon in order to determine whether this sort of directive makes 
> sense for 1.2.

maybe it will be better to define those redirects as any non human initiated redirect

> 3. What is the threat model that you expect this directive to address?

we have seen several malicious code injected in web pages that redirect the visitors to pay per click affiliate programs or to pages with dangerous code intended to infect the visitor, please note that this does not only use eval or inline scripting but can also infects server js files or add meta refresh tags

> It seems like scripted navigations would be more or less completely 
> subsumed under 'script-src', for example. What can't you cover with 
> current directives that this directive would take care of?

i cannot see any way to forbid redirects in CSP 1.1 script-src, at least in http://www.w3.org/TR/CSP11/#script-src

> --
> Mike West <mkwst@google.com <mailto:mkwst@google.com>>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany 
> Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: 
> Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm 
> legally required to add this exciting detail to emails. Bleh.)
> On Wed, Apr 23, 2014 at 11:00 AM, David Saez Padros <david@ols.es 
> <mailto:david@ols.es>> wrote:
>     Hi
>         We have avoided dealing with navigation up to now, in part
>         because it's
>         a big implementation can of worms (lots of ways to trigger a
>         navigation), and in part because it could be used maliciously to
>         trap a
>         user on a site -- and we already see scam sites that try to do that
>         using other browser features.
>     FF already has a user option to warn on redirects
>         I suppose we could mitigate the bad effects by saying such a
>         directive:
>         1) never applies to user choices made through browser UI
>         (back/forward
>         buttons, bookmarks, typing urls)
>     of course, this should be mainly intended for automated redirects
>     (javascript, meta tag, or maybe even server redirects, but not for user
>     actions)
>         We've tended to avoid binary directives like "no-script" or
>         "no-navigation". something along the lines of
>         "allowed-navigation:" with
>         a host list (where 'none' and 'self' are valid options) would
>         fit the
>         existing spec better.
>     sounds better

Salu-2 y hasta pronto ...

    David Saez
    On-Line Services 2000 S.L.


Received on Thursday, 1 May 2014 18:07:18 UTC

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