- From: <jeff.hodges@kingsmountain.com>
- Date: Sun, 27 May 2018 12:35:06 -0600
- To: Artur Janc <aaj@google.com>
- Cc: WebAppSec WG <public-webappsec@w3.org>
Innaresting, thanks for the analysis Artur. that helps (moi at least) in understanding sec-metadata and how it fits in The Big Picture. Quoting Artur Janc <aaj@google.com>: > Thanks for the links, Jeff! I hadn't seen the papers, they are interesting > and they indeed touch upon some of the same problems that we've been > discussing. > > The general CORP approach of not letting the server process a request > unless the initiator and context are explicitly allowed to access a given > resource (e.g. foo.example.org can request /images/foo.png as an image) is > similar conceptually to what Sec-Metadata aims to achieve. The two main > differences are: > - With Sec-Metadata, the decision about handling the request would be made > by the server rather than by a declarative policy. This allows for building > server-side reporting and is likely more flexible than a declarative > approach. > - CORP has a (predictable and likely unavoidable) problem of not having any > insight into the structure of the web application, and relies on paths to > define a hierarchy of resources and enforce security rules. In practice, > this is very difficult to retrofit into moderately complex applications, > which often serve different types of resources from the same endpoint, > frequently change the URL structure, etc. We've already seen problems with > this with CSP's path-based script-src whitelists. > > My main takeaway from reading the papers is that the approach they outline > is reasonable, but the mechanics of how they propose to enforce the > security restrictions wouldn't really work. But that's still an interesting > approach/result, the articles will be useful as a reference in future > discussions. > > Cheers, > -A > > > On Wed, May 16, 2018 at 6:37 PM =JeffH <Jeff.Hodges@kingsmountain.com> > wrote: > >> wrt cross-origin information leaks, I'm wondering whether folks here are >> aware of this relatively recent work that seems on-topic: >> >> A Formal Model of Web Security Showing Malicious Cross Origin >> Requests and Its Mitigation using CORP >> Krishna Chaitanya Telikcherla, Akash Agrawall and Venkatesh Choppella >> < >> https://pdfs.semanticscholar.org/5746/7a3d74556e8e7c50609e24aa081918b2d006.pdf >> > >> >> Abstract: >> >> This document describes a web security model to analyse cross origin >> requests and block them using CORP, a browser security policy proposed >> for mitigating Cross Origin Request Attacks (CORA) such as CSRF, >> Clickjacking, Web application timing, etc. CORP is configured by website >> administrators and sent as an HTTP response header to the browser. A >> browser which is CORP-enabled will interpret the policy and enforce it >> on all cross-origin HTTP requests originating from other tabs of the >> browser, thus preventing malicious crossorigin requests. In this >> document we use Alloy, a finite state model finder, to formalize a web >> security model to analyse malicious cross-origin attacks and verify that >> CORP can be used to mitigate such attacks. >> >> >> Also perhaps of interest: >> >> Mitigating Web-borne Security Threats by Enhancing Browser Security >> Policies >> KC Telikicherla (masters thesis) >> < >> http://web2py.iiit.ac.in/research_centres/publications/download/mastersthesis.pdf.9c510731811e394c.4b726973686e617468657369732e706466.pdf >> > >> >> >> CORP: A browser policy to mitigate web in ltration attacks (2014) >> https://link.springer.com/chapter/10.1007/978-3-319-13841-1_16 >> >> >> Mitigating browser-based DDoS attacks using CORP (2017) >> < >> https://pdfs.semanticscholar.org/17b0/50d9043e40af373335f0e2564257477aef11.pdf >> > >> >> >> >> HTH, >> >> =JeffH >> >>
Received on Sunday, 27 May 2018 18:35:43 UTC