Re: FAQ & Use Cases

Jon Ferraiolo wrote:
> 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.

Using JSONRequest here would not fulfill requirement 7 from the spec as 
JSONRequest can only be used to POST JSON data.

Maybe we need to clarify that 7 applies to both POSTing and GETtin data. 
Anne, would you mind adding text to state that? We should probably 
expand 5 to include sending of data too.

I don't see how JSONRequest can be expanded to include posting XML data 
without violating requirment 1, especially the second pullet point.

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

I don't understand why you think XML data is unimportant? I don't 
believe that one-format-to-rule-them-all is ever going to work. It 
hasn't in the past.

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

Why? User specific data seems very useful. It would be great to be able 
to create mashups that pull my calender data from google calender as 
well as my addressbook from yahoo mail.

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

Without sending cookies we can't satisfy requirement 12. Especially in 
combination with requirement 3.

JSONRequest requires that I give my login data to the requesting site. 
That seems scary.

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

This is exactly how access control works too. You can issue GET requests 
that include cookies and auth information to 3rd party sites, but you 
can't retrieve data by default. You can only retrieve data if the server 
explicitly allows it.

 > Because of these factors, I don't think <img> and
 > <script> should be used to say that the web is already vulnerable.

I'm not sure what you mean by this. All we are saying is that it is 
already possible to issue GET requests that include cookies in a number 
of ways. Do you not agree with this?

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

Please elaborate as I don't understand what you mean here. If you think 
access control allows for any specific attacks please describe in detail 
the attack.

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

Sure, saying 'anyone can access the data' is simpler. It also seems to 
open new attack vectors. Requirement 1 states that we must not allow new 
attack vectors.

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

This is a result of requirements 4, 8 and 9 together.

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

I don't think that seems very far fetched that a set of servers want to 
collaborate. For example www.livejournal.com and user.livejournal.com 
might want to allow each other to read data. They are basically the same 
site, but use different domain names for various security reasons.

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

You are arguing that we shouldn't design a new standard because the new 
standard doesn't work out of the box in all existing browsers. This 
would seem to limit progress a whole lot. If we followed that we would 
put most of W3C out of business, no?

I've heard ample interest from all major browser vendors, with possible 
exception of microsoft, but I don't have as good personal connections 
with anyone on the IE team as I do with the other browser vendors.

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

This would seem to open very scary new attack vectors. Just because a 
spec is produced that says that it's ok to load new data types cross 
site doesn't mean that server administrators automatically protect 
themselves against that. Note that both XSLT and XBL can basically use 
any raw XML file. All XSLT needs is one magic attribute on the root 
element, and XBL might not even need 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.)

The flow is that example.org inc advertises that they have implemented a 
public REST API that provide certain services. Other sites then use that 
API and build functionality on top of that.

Such APIs have been announced by very many web vendors already. Here are 
some examples:

www.flickr.com/services/api
http://developer.yahoo.com/maps/simple/index.html
www.google.com/apis/adwords/
http://wiki.developers.facebook.com/index.php/API

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

I agree that banking is more scary and would generally require very 
strong security checks.

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

Yep, this exact use case would not need allow/deny rules.

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

As I've stated above, and many times before, JSONRequest fails to meet 
many of our requirements. Such as 4, 5, 7, 8 in combination with 4, 9 i 
think, 10, 11, and 12. And possibly even 1.

Best Regards,
Jonas Sicking

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

Received on Friday, 18 January 2008 19:09:14 UTC