- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 09 Jan 2008 00:40:37 -0800
- To: Jon Ferraiolo <jferrai@us.ibm.com>, "WAF WG (public)" <public-appformats@w3.org>
Jon Ferraiolo wrote: > I guess that PEP = policy enforcement point > > Regarding PEP in the client, I agree with David Baron that there has to > be a security policy in the client, and in fact there already is such a > policy (i.e., the same-domain policy). However, I also agree with David > Orchard that enforcement of which domains should be allowed to access > which data (i.e., the policy as expressed in Access Control's processing > instruction) more naturally belongs on the server, not the client. > > But I would go further and question the whole approach of listing a set > of domains that are allowed or denied. I have a hard time seeing which > workflows make sense from whitelisting or blacklisting discrete domains, > with the possible exception of "*" (i.e., everyone) or a list of > subdomains within a company's intranet (although this would be fragile). > I much prefer the approach in JSONRequest, which does not include a list > of allowed/denied domains. The JSONRequest approach matches the > requirements of public/unprotected web services, which I believe is the > most important use case for cross-domain data access. JSONRequest > assumes that the server will decide who has access to the data, which > aligns with David O's recommendation. (But as I have said before, I > would like to see JSONRequest support XML payloads in addition to JSON > payloads.) I don't think something like JSONRequest can ever satisfy the requirements access-control has. First off starts with a very different starting point security wise, which is that anything that looks like javascript can be read by any site. This is due to the fact that browsers currently let you do cross-site loading of any data that is parseable as javascript. However access-control is trying to solve the problem for other data types as well, such as HTML and XML. These data types can currently not be loaded cross site, which means that there likely is documents out there containing sensitive information which must not be exposed cross site. And note that not including cookies and other auth credentials does not solve this problem due to content behind firewalls. While I can agree that relying solely on the fact that a server lives behind a firewall is not the best protection strategy, I expect this is currently in widespread use (it's something I've seen myself a lot) and so not something that we can ignore. I would also like to note that JSONRequest also uses the clinent as a PEP. JSONRequest uses the Content-Type header to indicate that data should be accessible cross site and relies on the client to enforce that. Access-control uses the <?access-control?> PI or the Access-Control header instead. Which of these two headers are more secure can of course be debated, but the fact remains that the client is a PEP in both cases. I agree that the whitelisting/blacklisting feature does not add that much value compared to the simple "*" case. However I do think especially whitelisting does add some value, and in fact the spec that access-control originated from had that as requirement. Also, the whitelisting/blacklisting in itself so far hasn't received much negative feedback, but rather the fact that the decision is made by the client. I don't see how JSONRequest can be adjusted to work for any content type without turning it into something that looks a lot like access-control since it both relies on the content looking like javascript, and uses the Content-Type header to control access. / Jonas
Received on Wednesday, 9 January 2008 08:40:54 UTC