W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2018

Re: Formal Model of Malicious Cross Origin Requests Mitigation using CORP (was: A primer on cross-origin information leaks

From: <jeff.hodges@kingsmountain.com>
Date: Sun, 27 May 2018 12:35:06 -0600
Message-ID: <20180527123506.Horde.7okYcMefCVH1aWME6J4g4hA@box514.bluehost.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:03 UTC