On Fri, Feb 13, 2015 at 12:29 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Feb 13, 2015 at 12:13 PM, Eduardo' Vela" <Nava> <evn@google.com> > wrote: > > I spent some time trying to make a poor-man EPR with ServiceWorkers and > it > > didn't work. Since ServiceWorkers dont get invoked on resource requests > > (XHR, <img>, etc) then one can't use them to protect against CSRF. > > Service workers are involved in those fetches. As long as the service > worker is controlling the client (document/worker) that initiates > them. > Yes I know. > That said, ServiceWorkers can be used effectively to "break linking in the > > web". Since it's already possible to "break linking on the web" with > > ServiceWorkers, we need to either fix SWs, or allow EPR. > > That's not how it works. > > > Even if Referer or service workers were an effective mechanism, that > doesn't mean that we need to add another mechanism. And so far it's > still unclear what is being solved in terms of XSS that CSP does not > address. And in terms of XSRF, it seems we should prioritize work on > cookies. > I mean, EPR fulfills Brad's addendum, in specific (see bolded text): > Restricting deep-linking for non-security purposes is not a goal of > this deliverable, and *it should give resource owners no additional * *> ability to do so beyond current abilities of the web platform*, e.g. by > providing a simple to deploy mechanism using client-side state to > supplement what can already be accomplished by a less-scalable > web application firewall. Preserving the ability to link on the web > platform will be prioritized." As per the specific reasons on why CSRF/XSS are solved by EPR, that's a bit unrelated to this thread (there's another thread about it). > > > -- > https://annevankesteren.nl/ >
Received on Friday, 13 February 2015 11:33:22 UTC