W3C home > Mailing lists > Public > public-web-security@w3.org > September 2011

RE: lcamtuf on the subtle/deadly problem with CSP

From: Hill, Brad <bhill@paypal-inc.com>
Date: Wed, 31 Aug 2011 22:44:29 -0600
To: Michal Zalewski <lcamtuf@coredump.cx>, Daniel Veditz <dveditz@mozilla.com>
CC: Adam Barth <w3c@adambarth.com>, "sird@rckc.at" <sird@rckc.at>, "public-web-security@w3.org" <public-web-security@w3.org>
Message-ID: <213E0EC97FE58F469BB618245B3118BB552DA0A9FB@DEN-MEXMS-001.corp.ebay.com>
> > By "exploitable" you mean "it might be possible to work around the CSP
> > restrictions on a case-by-case basis and continue exploiting some of
> > the sites that are already exploitable without CSP protection," right?
> >

Agreed.  Though ROP and finding "gadgets" has become somewhat of a science, that hardly means that DEP/NX hasn't provided a significant increase in the security of applications that opt-in to the protection.

The JSONP issue is one I've heard from multiple people, though, including CSP early adopters.   Is it time to standardize a safer way to use JSONP?  Perhaps independent of CSP, perhaps in concert with it and add a jsonp-src directive to allow its use without taking on all the attack surface other script content hosted at such a domain might afford?   CORS offers an alternative, but there is a huge deployed base of JSONP APIs that aren't going anywhere.

I've seen the proposal at http://json-p.org/, but am thinking something more like:

jsonp.load(callbackName, uri);

It should be relatively simple to recognize a "safe" (named callback + JSON data only) response as an AST at that point, no?
Received on Thursday, 1 September 2011 04:44:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC