Re: CSP no-external-navigation

fwiw, if we have an iframe, and the iframe wants to redirect the top page
to another site, today it's probably not possible to know where its gonna
be redirected (I guess you could know if you open a popup and try to
inspect the opener's origin somehow).. so we should consider that before
implementing stuff.


On Thu, May 1, 2014 at 11:06 AM, Hill, Brad <bhill@paypal.com> wrote:

> David,
>
>   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.
>
> -Brad
>
> -----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
>
> Hi
>
> > 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.
>     http://www.ols.es
> ----------------------------------------------------------------
>
>
>
>
>
>