Re: FAQ & Use Cases

Hi Anne,
The FAQ was very helpful in documenting the rationale behind some of the
approaches in the Access Control spec. However, I disagree with most of the
reasoning, as shown below. The use case are a step in the right direction,
and I have some feedback on them. (Further down)

>Access Control for Cross-site Requests DESIGN DECISION FAQ
>
>** Why is there a second check for non-GET requests?
>
>For non-GET requests two checks with Access-Control HTTP headers and
><?access-control?> processing instructions are performed. Initially a
>"permission to make the request" check is done on the response to the
>authorization request. And then a "permission to read" check is done on
the
>response of the actual request. Both of these checks need to succeed in
>order for success to be relayed to the protocol (e.g. XMLHttpRequest).

I appreciate the attention that the WG has put into trying to promote a
secure approach to deliverying POST requests, but IMO it would be better to
pursue a different technical strategy, such as what we see in JSONRequest
or something derivative of that. With JSONRequest, POSTs are allowed
without requiring a prior GET (or HEAD or OPTIONS). JSONRequest also can be
made available via a JavaScript implementation that works in today's
browsers. Its approach is simpler for everyone involved, both server-side
developers and client-side (i.e., JavaScript) developers. I'm not sure if
JSONRequest is perfect as is (e.g., only supports JSON and not XML), but it
was designed by Doug Crockford, who gives talks at Ajax conferences on web
security, and IMO he has a good handle on security issues.

>
>** Why are cookies and authentication information sent in the request?
>
>Sending cookies and authentication information enables user-specific
>cross-site widgets (external XBL file). It also allows for a user
>authenticated data storage API that services can use to store data in.

As I have said previously, I disagree that XBL (and XSLT) should impact
decisions about how to provide the best technology for cross-site data
access. The XBL and XSLT specs can say that user agents must allow
cross-domain access, just as is allowed for CSS stylesheets.

Where did the idea of user-specific widgets come from, anyway? IMO, that
would be a very, very low priority (approaching zero).

The negative with sending cookies is that it opens up CSRF attack
opportunities when web sites say allow "*", which I expect would be the
most common scenario. There are other approaches to sending data to a 3rd
party domain that are more secure and still achieve the same result. Once
again, JSONRequest does not send cookies. I assume that Doug Crockford
assumes that authenticated information (if necessary) would come from be
sent with the payload (rather than via cookies), which means that if domain
FOO wants to upload data to domain BAR, then domain FOO's web page would
require the user to someone enter their BAR authentication information
(which could be stored in FOO's cookies, not BAR's cookies). With such an
approach, the user will be told by FOO's web page that this web page needs
his BAR account information, so the user gets to opt-in to allowing the
cross-site POST, instead of the current approach in Access Control where
cookies (potentially with credentials) are always sent without the user
being aware.

>
>Cookies and authentication information is already sent cross-site for the
>HTML <img>, <script>, and <form> elements so this does not introduce a new
>attack vector. It simply makes use of the Web.

<img> and <script> only work with GET, so if a web server follows best
practices (i.e., only support POST when submitting data), then you aren't
subject to data submission attacks. There is no way to retrieve data via
<img>, so that doesn't allow data retrieval attacks. With <script>, the
only way to retrieve data is if the server supports JSON-with-callback.
Because of these factors, I don't think <img> and <script> should be used
to say that the web is already vulnerable.

It is true that <form> works with both GET and POST and does send cookies
to other domains, which means web site developers today indeed need to
protect against CSRF attacks via cross-domain use of <form>, where CSRF
protection is usually is accomplished by the server actually managing a
session with the user where a random token is maintained across the session
(without storing it within cookies). Right now, Access Control does not
have a good mechanism for achieving server-controlled session management
with such a random token, largely because it uses a client-side PEP
approach. In fact, Access Control gets in the way of the way most server
developers would implement CSRF protection.

>
>** Why can't cookies authentication information be provided by the script
>author for the request?
>
>This would allow distrubted cookie / user credentials search.
>
>** Why is the client the policy enforcement point?
>
>The client already is the policy enforcement point for these requests. The
>mechanism allows the server to opt-in to let the client expose the data.
>Something it currently does not do and something which servers rely upon
the
>client not doing.

This confuses "access control" with "policy enforcement point". Yes,
browsers today implement an access control policy that (currently) prevents
(among other things) XHR from talking to other domains and prevents frames
from different domains to see each other's DOM. But "policy enforcement
point" means deciding which particular users or which particular domains
should have the ability to retrieve data or change data.

With JSONRequest, the access control rules are loosened such that the new
mechanism (i.e., JSONRequest) is allowed to access other domains, and
therefore assumes that the policy enforcement point is the server who
receives the GET and POST requests. This approach makes more sense and
results in a simpler mechanism.

>
>Note however that the server is in full control. Based on the request it
can
>simply opt to return no data at all or not provide the necessary handshake
>(in form of the Access-Control HTTP headers and <?access-control?>
>processing instructions.
>
>** Why does the mechanism do both black- and whitelisting?
>
>In case the server and documents hosted on the server are in control by
>different people it is necessary that the server people are able to
override
>the document people (if the document wants to share access) and vice versa
>(if the server wants to share access).
>

I think that both whitelisting and blacklisting represent a major weakness
in the Access Control spec. I have yet to see important use cases where it
makes sense for a particular domain FOO to allow access to a particular
domain BAR. In the real world, when would http://www.facebook.com ever list
a particular domain to which it would provide access? As best as I can
tell, the primary use cases are * (i.e., allow everyone) and *.mydomain.com
(i.e., allow access to all of your own subdomains). For simplicity reasons,
the best way to go is to drop whitelisting and blacklisting entirely and
therefore just support *, which is what JSONRequest does.

>Access Control for Cross-site Requests USE CASES
>
>FOO in the scenarios below is a fictional person who lives in Havana and
>likes playing with Web technology that isn't implemented anywhere.

Of course, the "isn't implemented anywhere" is a bit of humor, but it does
point out a weakness with Access Control. It won't provide value to the
world until it is available in a majority of deployed browsers. Since MS
and Apple are not participating in the discussion so far, there is a worry
that their browser might never support Access Control. I have no insight
into what Apple is thinking regarding Access Control, but I hearing
security concerns from people at MS about Access Control within discussion
at OpenAjax. But let's suppose that Apple and MS do come around and
ultimately ship it, let's say in 3 years. It will then take roughly another
3 years or so before the majority of deployed browsers support the feature.
On the other hand, JSONRequest can be implemented in JavaScript and will
work with today's browsers, and therefore the community can use it
immediately.

What the above paragraph translates into is that I would like to see a
requirement that says something about it being highly desirable that the
mechanism can run in today's browsers as they exist today (without
requiring the addition of a new browser plugin).

>
>* FOO owns test.example.org and test2.example.org. FOO uses XSLT
extensively
>on both domains and because FOO doesn't want to use a pre-processing
script
>to duplicate XSLT files he puts them all on test.example.org and includes
a
><?access-control allow="test2.example.org"?> at the top of them.

IMO opinion, the XSLT and XBL specs should simply say that user agents
should allow cross-site access, just like what happens today with CSS and
JavaScript. Don't need Access Control for that.

>
>* FOO has implemented the fictional OPEN DATA REST API on test.example.org
>to store data so that services that help him keep track of bookmarks,
>friends, et cetera can store the info on FOO's domain instead of their
own.
>This allows FOO to switch to any other service provider taking his data
>easily with him. Using Access Control he enables 2del.icio.us.invalid and
>flickr2.invalid to access his data so they can store and manipulate data.
>To keep other people from messing with his data the API only works if
you're
>authenticated with test.example.org.

I didn't fully understand the above workflow. This I understand: FOO has a
web site at test.example.org that implements OPEN DATA REST API. But how is
it that del-icio.us or flickr would even know about test.example.org to
invoke the OPEN DATA REST APIs on that site? And why doesn't the web page
at test.example.org simply invoke flickr or del.icio.us APIs (probably
using dynamic script tag with JSON today using a particular API key) to
retrieve the data and then upload it to test.example.org? BTW - flickr does
have a rich set of APIs today (after all, it's part of Yahoo), but all I
could find for del.icio.us were a small number of APIs that seemed to work
only via server-side facilities. (Maybe I am missing something.)

>
>* FOO signs up for the personaldata.example.com Web service where you can
>enter all kinds of personal information, such as your address, credit card
>information, et cetera. Every shopping site that has a contract with
>personaldata.example.com can then easily extract data out of it as long as
>FOO is authenticated with personaldata.example.com which gives him a
better
>shopping experience.

Yikes! No way would any ecommerce site leverage the browser and access
control for anything involving credit card numbers. If there were such a
personaldata.example.com web service, then it would implement
server-to-server communications to deal with authentication and passing of
secure information on a case-by-case basis, with various legal documents
among the various parties. Therefore, I do not think this is a valid use
case.

>
>* FOO enables cross-site access to his FOAF file and hopes everyone will
>follow him so that the Tabulator http://www.w3.org/2005/ajar/tab becomes
>easier to use/write/etc.

This one needs more detail, such as would FOO allow everyone to have GET
access, everyone to have POST access, or what? (Note that if everyone is
given access, then there is no need for the complicated allow/deny syntax
for this particular use case.  In fact, the only use case here that might
leverage allow/deny features is the OPEN DATA REST API, but that one needs
to be fleshed out some more.)

Each of the use cases needs a small write-up about how the given use case
is accomplished today (or is not possible today) and what proposed
alternative technologies (e.g., JSONRequest) might be used instead of
access control to achieve the desired result.

Jon


public-appformats-request@w3.org wrote on 01/16/2008 05:23:06 AM:

>
> Hi,
>
> In the interested of moving forward and having to repeat myself a bit
less
> I created two documents:
>
>   * http://annevankesteren.nl/temp/access-control-faq
>   * http://annevankesteren.nl/temp/access-control-use-cases
>
> Feel free to ask questions if anything is unclear.
>
> Kind regards,
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>