search

read-write-web / rww-play

read write web Play
59 stars 19 forks source link

update: headers for CORS #133

Open sylvainlb opened 9 years ago

sylvainlb commented 9 years ago

WARNING: this version doesn't take care of where the request is coming from, nor if the user actually wants it. I'm not sure how to ensure it in an open decentralized world. A few ideas:

Any ideas welcome

bblfish commented 9 years ago

There is a good answer from @michielbdejong on the WebID mailing list which messes up the proposed solution as far as browsers go, and leads me back to the idea that a full proxy answer is the correct one.

sylvainlb commented 9 years ago

I may agree with you that the proxy solution is more robust, but I'm pretty sure app developers will require to be able to trigger CORS request from the client. I think both need to be supported.

bblfish commented 9 years ago

In both my proposed solutions the CORS is triggered from the client. In the proxy the calls are just routed through a web proxy first. Without the CORS proxies you need to solve the problem described for resources that are non public. ( And for public resources there are issues of efficiency as each additional OPTIONS request is very time consuming )

sylvainlb commented 9 years ago

I agree with that, but it means that application designers are restrained in a certain design, and I'm not sure most will make their apps that way. My point is that RwwPlay! should support this design even if it's not the best one, as I expect most applications will be made this way.

bblfish commented 9 years ago

I asked on W3C Webapp-sec mailing list about wether they had a Simple Description of CORS. I think one needs to study those answers, to get a good understanding of what the security issues may be.

sylvainlb commented 9 years ago

Interesting discussion. I didn't read all the COWL papers, so I don't really understand how this model would work, but that might be a good answer. In the meantime, I don't see anything better than asking the user.

I have to add that although the proxy solution would bypass the CORS mechanism, I don't think it solves the security issue raised here. It could be even worse if it implies sharing some credentials with a proxy you don't necessarily trust.

bblfish commented 9 years ago

Mhh so according to an answer by @annevk on issue #118 it looks like the proposal of using WebID information to allow the server to specify the Origin for authenticated requests may in fact work. He wrote there:

It's totally fine to always allow CORS preflight from any origin and then do something different for the actual resource. All CORS preflight does is making sure that the URL "speaks" CORS, it doesn't really grant anything beyond that, just making sure no unsuspecting servers are compromised by complex requests.

sylvainlb commented 9 years ago

Alright, but we still need some mechanism for user decision about trusted origin right?

annevk commented 9 years ago

Please see http://en.wikipedia.org/wiki/Ambient_authority about putting trust in origins. On the face of it that doesn't seem like a good idea.

It's not entirely clear to me what you're trying to accomplish here though.