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
