Re: Limiting requests from the internet to the intranet.

As a relevant example, Elasticsearch (a popular full-text and analytics
search engine) disabled CORS by default in 2014, to prevent internet sites
from raiding locally running instances:

https://github.com/elastic/elasticsearch/issues/7151

The use of CORS was fine, it was having it be the default that was the
problem. It was important to ensure that developers knew what was going on
and had a chance to opt in to the behavior.

One takeaway for me at the time, while discussing it at my organization,
was that few web developers (myself included until then) realized that
JavaScript could easily break the internet-intranet barrier. It never
factored into their own code, or how they thought about running local
services on their machines.

I'm also bringing this up to mention that user-side opt-in is needed in
addition to server-side opt-in, since some services may still have CORS on
by default, or have it enabled inside an enterprise without realizing the
broader implications.

-- Eric

On Mon, Jan 4, 2016 at 8:10 AM, Mike West <mkwst@google.com> wrote:

> Happy new year, WebAppSec! This seems like a lovely time to rekindle the
> fire under the public/private origin restriction that we removed from Mixed
> Content way back in 2014 (
> http://www.w3.org/TR/2014/WD-mixed-content-20140722/#private-origin).
>
> I've put together a kinder, gentler take on hardening the user agent
> against the kinds of attacks that such requests enable:
> https://mikewest.github.io/cors-rfc1918/. It's pretty rough, as I've only
> poked at it sporadically over the holidays, but I think there's enough
> there to get a conversation going.
>
> In a nutshell, the proposal is to require a CORS-preflight request for
> requests initiated from the public internet which target private IP space.
> This preflight requires an opt-in on the part of the intranet server via a
> new CORS header, but doesn't block the requests entirely (which was a
> failing of the initial proposal). I imagine this server-side opt-in being
> combined in some intelligent way with a user-side opt-in (Presto-style
> interstitial? permission request?), but I haven't explored anything in that
> direction.
>
> CCing a few folks who've commented on the topic in the past; I imagine
> you'll have opinions. :)
>
> -mike
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>