Re: CORS proxy - was: CORS security hole?

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

Henry, can you please raise this in another venue.

-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/
>
>

Received on Tuesday, 17 July 2012 21:17:09 UTC