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

Re: On the Insecurity of Whitelists and the Future of CSP

From: Jim Manico <jim.manico@owasp.org>
Date: Thu, 8 Sep 2016 11:38:32 -1000
To: Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>
Cc: Artur Janc <aaj@google.com>, "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C Web App Security WG <public-webappsec@w3.org>, craig.francis@gmail.com
Message-ID: <a4257b9b-2d03-62fa-ab7f-82788c2325e9@owasp.org>

>
> On Thu, Sep 8, 2016 at 1:28 PM, Anne van Kesteren <annevk@annevk.nl
> <mailto:annevk@annevk.nl>> wrote:
>
>     On Thu, Sep 8, 2016 at 1:16 PM, Artur Janc <aaj@google.com
>     <mailto:aaj@google.com>> wrote:
>     > An attacker with an XSS can set any cookie they want to make the
>     exfiltrated
>     > data visible across the whole top-level domain, so they're not
>     bound by
>     > flags on any existing cookies.
>
>     That depends on whether or not we offer ways to restrict cookie APIs.
>     (I think there's a proposal for that somewhere.)
>
Yes. Mike West wrote draft-ietf-httpbis-cookie-alone
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01 which
updates RFC6265 by removing a non-secure origin's ability to set cookies
with a secure flag, and to overwrite cookies whose secure flag is set.
This deprecation improves the isolation between HTTP and HTTPS origins,
and reduces the risk of malicious interference.

There are a few vectors that need to be accounted for like cookie
forcing in addition to normal set-cookie calls that overwrite secure
cookies.

- Jim
Received on Thursday, 8 September 2016 21:41:38 UTC

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