Re: Review of http://www.w3.org/TR/2007/WD-access-control-20071126/

public-appformats-request@w3.org wrote on 01/09/2008 12:40:37 AM:

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

It's hard to say whether access-control meets its requirements since
requirements weren't listed beforehand.

> First off starts with a very different
> starting point security wise,

Without use cases and requirements it is hard to determine what the
security strategy is for Access Control. There does seem to be a
client-side PEP involved in Access Control, but some people on this list
have said that it is better to have an approach where the server decides,
not the client. (I agree with the server PEP approach versus the client.)

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

As you point out, many sites today support JSON-based web services which
are can be sent from anywhere on the web. To me, one of the chief virtues
of JSONRequest is that it is an incremental improvement over existing
JSON-based workflows in use today. The fact that JSONRequest allows anyone
to make a request to any site is OK with me today because:

* That's already the case with today's JSON-based web services, where
dynamic SCRIPT can access any site
* It is better if the server decides who gets access to data, not the
client
* Servers already have to worry about random requests from random sites
because it is easy for hackers to manufacture whatever HTTP request they
want to and send it to whatever URL they want to

>
> However access-control is trying to solve the problem for other data
> types as well, such as HTML and XML.

It looks straightforward to me to enhance JSONRequest to support XML (and
thus XHTML) in addition to JSON. One way would be to say that if the
payload is an JavaScript object, then it is JSON up/down the pipe, else if
a string then it is XML. In either case, the browser must parse the
response using an appropriate parser (i.e., JSON or XML) into JavaScript
objects. If JSON is used for the data, then only JSON object literals are
supported, not the full JavaScript language (that's what the JSON subset of
JavaScript is about). On the XML side, the conformance requirement should
be that the browser convert the response automatically into JavaScript
objects to prevent web developers from doing an innerHTML assignment on
content that might contain a SCRIPT tag. In either case, strict parsing is
a conformance requirement and errors are generated if the data is not
properly "well-formed".

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

I wouldn't call that PEP. That's just a data integrity feature, not
enforcement of who gets access to the data.

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

If whitelisting/blacklisting does not add much value, then why do we have
it at all?

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

The lack of strong feedback on the whitelisting and blacklisting might be
due to the fact that people have only started to focus on providing
detailed feedback. Personally, even when roughly skimming early drafts, I
have felt that the whitelisting and blacklisting approach was very fishy,
but only since October have I started to focus on the spec in enough detail
to feel that I can send feedback on the spec.

Which leads me once again to hammer on the process by which the spec was
developed. It is usually more efficient to develop a standard in a manner
such that the community can provide feedback at the earlier possible point.
One way to make this happen is to develop use cases and requirements
upfront, announce them to the community, and then seek feedback. Then it is
incumbent on the WG to perform due diligence of existing industry practice
against those use cases and requirements to see if there already exists
something that works. Failure to take these early steps results in the
messy situation that is happening right now, where people push back on the
specification at a late point in the specification timeline, challenging
some of the key assumptions that represent the foundation of the spec.

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

See above from my proposal for allowing JSONRequest to support XML in
addition to JSON. Also, the Content-Type header is a data integrity feature
(i.e., ensure that the server supports the JSONRequest protocol) and not an
access control mechanism.

>
> / Jonas
>