Re: CORS proxy - was: CORS security hole?

On 17 Jul 2012, at 23:16, Eric Rescorla wrote:

> This all seems out of scope for the work WebAppSec is chartered for.

All of it? Really?

Let me look at the charter of the working group. Areas of scope for this working group include:

[[
Secure Mashups: Several mechanisms for secure resource sharing and messaging across origins exist or are being specified, but several common and desirable use cases are not covered by existing work, such as: allowing child IFRAMEs to protect themselves from "clickjacking" or specify what characteristics a parent window must allow. The WG will design mechanisms and coordinate with existing and ongoing work in other forums to allow secure mashups.
]]

1.  Linked Data is all about mashups. It's about taking information from different sites and using semantic technology building a merge of different points of view. In Linked Data space we are having trouble with
merging data in JS tools ( WebApps ) because of limitations of where we can get information from. CORS helps, but perhaps it can be improved without harm to security?

I pointed out that unnecessary restrictions in CORS with GET-requests-without-authentication is forcing one to put up CORS proxies. 

2. CORS restrictions are based on very weak identity of the Origin JS. This means that a lot less mashups can happen that would otherwise be possible if JS were signed and more precisely identified. 

3. I proposed a minimal improvement to build trust in Origin JS, that could make mashups more easy, by allowing users to specify through their WebID profile (which they use for TLS authentication) which Origins they trust. At least as a thought experiment.

> Henry, can you please raise this in another venue.

Well I was just reporting here, in answer to a question by one of your members, that I had brought this up in another W3C WG that might want to look at how Apps and Linked Data can work together. Indeed I even pointed to an e-mail where this was brought up 

   http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html

Therefore my intervention even fit the section  "The WG will design mechanisms and coordinate with existing and ongoing work in other forums to allow secure mashups."


I hope that helps you see how this ties in with this groups Eric. We can all be mistaken. Indeed, I thought at the start of the thread that I had found a security in CORS. I then quickly excused myself as soon as I saw that I was wrong. 

All the best,

	Henry


> -Ekr
> 
> [As WG Chair]
> 
> On Tue, Jul 17, 2012 at 1:15 PM, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 17 Jul 2012, at 21:32, Dirk Pranke wrote:
>> 
>>> On Mon, Jul 16, 2012 at 11:22 PM, Henry Story <henry.story@bblfish.net> wrote:
>>>> Ok, I don't really have a browser to hack on. On the other hand a few of us
>>>> are working on building a CORS
>>>> proxy at the read-write-web community group to enable javascript linked data
>>>> agents to build up in the browser views of data distributed on the web.
>>>> There may be some interesting results this brings up that we can discuss at
>>>> TPAC in Lyon... :-)
>>> 
>>> Building a CORS proxy for any reason other than to prototype something
>>> sounds (at first blush) like a bad idea; as Adam says, you're
>>> basically changing the security policies the web is supposed to be
>>> using. It seems like if you're having to do this you're solving the
>>> wrong problem, and maybe there's something else that should be
>>> changed?
>> 
>> Well I have proposed to the Linked Data Profile WG today that it may be useful for them add  a use case that would take WebApps into account so as to look at some of the issues that are brought up in this space when WebApps interact with LinkedData. See the mail here:
>> 
>>   http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html
>> 
>> A lot of Linked Data providers do not support CORS (it's too new for them to have noticed, and too far from their use cases) yet we would like to build apps that use that data. As a result one cannot have a javascript application as described in that e-mail do a GET on such resources using CORS alone. One needs a proxy to get such resources.
>> 
>>   What I am not so clear about is whether there is any need for CORS to put any restrictions at all on resources that are fetched with GET - since GET is indempotent - especially when the GET request is done without any access control at all. That would at least make a lot of public linked data browseable without the need for a proxy using javascript. Furthermore a proxy is so easy to build, any such public data can be found anyway, so the CORS restriction on GET have no real effect, other than getting people to write CORS proxies....
>> 
>> Next since I mentioned this in the e-mail to the LDP WG, let me mention this here. I have an interesting suggestion for you on how to make it easier to work out when one could trust a JS Origin. So what is the issue? Currently there is a bit of a problem with the Origin header because the site receiving a request with an Origin header may not know anything about that Origin site at all. Currently that means it has to close the connection. But what if I the user who logged in really trust the origin site JS? (say because it is hosted on my FreedomBox). So lets say I have some JS on my FBox and that JS goes to the site of a friend of mine. How can that Friend know that I trust the JS coming from my FBox, and not trust say the JS from some other random site? Well if I log in with WebID and the WebID Profile is hosted on my FBox, then that seems like a good indicator that my friend should trust requests that come from JS that has the Origin of my FBox. One could even make this explicit with a relation in my profile such as
>> 
>> 
>>   :me trustsOrigin <http://bblfish.net/> .
>> 
>> 
>> Then my friends server could have confirmation from my profile that the origin is trustworthy.
>> 
>> Of course if the JS, was signed then things could be even more easy, because that would allow me to place signed JS on my site that I trust and we would not have the trouble of someone maliciously uploading JS in a blog post of mine also getting rights at the same time. That is why I thought JS signing would be a pretty useful feature to have.
>> 
>>        Henry
>> 
>>> 
>>> -- Dirk
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 17 July 2012 21:51:18 UTC