Re: Are Jon's comments from IBM, the OAA, citizen Jon, ...? [Was: Re: Review of http://www.w3.org/TR/2007/WD-access-control-20071126/]

I expect there are others on this list who can respond better to your
question than me, but seeing no other responses so far, here goes.

Some leading web servers work with dynamic SCRIPT tags by wrapping their
JSON data within a function call. For example, instead of simply returning
a JSON object literal such as:

  { a:"aaa", b:"bbb" }

the web service gets invoked by passing the name of a callback function
(e.g., http://example.com?callback=MyCallBack) and then returns a response
that wraps the JSON content inside a function call, as in:

  MyCallBack({ a:"aaa", b:"bbb" });

For how Yahoo services work with JSON, see
http://developer.yahoo.com/common/json.html.
Google offers both the callback approach and the direct JSON approach, but
note that you can only access cross-domain data via the callback approach.
See: http://code.google.com/apis/gdata/json.html.

The callback approach uses syntax that would be an error according to the
JSONRequest specification. I expect that web services that support the
direct JSON approach for same-domain access would work as is, which means
Google and other service providers would have to change their service to
handle JSONRequest requests differently. Because of this, maybe the
JSONRequest spec should require that the content has the content has some
standard string at the beginning (for example, "/jsonrequest/") that
prevents direct assignment via eval(). A similar approach is recommended
anyways with JSON data in order to prevent JavaScript/JSON hijacking per
http:/www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking
.pdf .

Jon




                                                                           
             Brad Porter                                                   
             <bwporter@yahoo.c                                             
             om>                                                        To 
             Sent by:                  Jon Ferraiolo/Menlo Park/IBM@IBMUS  
             public-appformats                                          cc 
             -request@w3.org           public-appformats@w3.org,           
                                       public-appformats-request@w3.org    
                                                                   Subject 
             01/09/2008 02:26          Re: Are Jon's comments from IBM,    
             PM                        the OAA, citizen Jon, ...? [Was:    
                                       Re: Review   of                     
                                       http://www.w3.org/TR/2007/WD-access 
                                       -control-20071126/]                 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Thank you, this was a very helpful clarification.

Do webservers today default to rejecting requests that contain the extra
JSONRequest header?  That's effectively what you need to preserve the same
restrictions that are expected today.

Brad

Jon Ferraiolo <jferrai@us.ibm.com> wrote:
 public-appformats-request@w3.org wrote on 01/09/2008 09:54:38 AM:

 > > I believe there are a straightforward waysto extend JSONRequest to
 > > accommodate XML in addition to JSON.
 >
 > I'd like to understand better what this mechanism might look like as
 > I'm not sure I agree that you could extend it without doing
 > something nearly equivalent to what the access-control specification
 > requires.

 One approach that I suggested in an earlier email was that the JSONRequest
 implementation support XML by examining the content that comes back within
 the HTTP response. If it is a JavaScript object (e.g., first
 non-whitespace character is "{"), then parse it with a JSON parser.
 Otherwise, parse it with an XML parser. In both cases, strict parsing is
 required. Invalid content (e.g., executable JavaScript or markup that is
 not well-formed) would produce an error. In both cases, the JSONRequest
 implementation produces a JavaScript object to remove the temptation to do
 a JavaScript eval() on the JSON content or innerHTML on the XML content.

 >
 > JSONRequest seems to be operating under the assumption that current
 > browsers don't have access to any protected JSON data inside
 > protected network zones.  This works because corporate IT
 > departments aren't typically storing confidential information in
 > JSON blobs sitting on their web-server.  The universe of existing
 > JSON data that relies on existing protection mechanisms is small
 > (and the protection mechanisms don't exist.)

 I wouldn't say that exactly. I have heard of Enterprise companies using
 JSON for large datasets because of the performance advantages, sometimes
 with approvals required do the worry about using eval().

 Existing JSON servers wouldn't work if JSONRequest is implemented properly
 on the client because the server is required to add a new HTTP header that
 sets the content type to application/jsonrequest. This is parallel to the
 "opt-in" approach for Access Control. In both cases, something new has to
 be done on the server for cross-domain access to work.

 >
 > The universe of existing XML data that needs protection is large and
 > there are well-established protection mechanisms already in place
 > that need to continue to work.

 I agree, but I don't think either Access Control or JSONRequest impact
 existing XML data because both require the server to be changed in order
 to use either of the proposed new features.

 > > 3) I have lots of concerns about Access Control as currently
 formulated.
 > > Others share these concerns, which seems likely to inhibit adoption if
 the
 > > spec stays as it is. If it does get adopted in its current form, I'm
 not
 > > sure how much the industry benefits from the new features and how much
 it
 > > will be harmed by the security issues and other costs.
 > I have to admit I'm not clear at this point as to what "the security
 > issues and other costs" you're referring to are.  I've seen an
 > argument that you disagree with the process and that you disagree
 > with the solution, but I'm missing what the security issues and
 > costs that concern you with the solution as proposed are?

 The main security worry is due to passing cookies, which opens up the
 possibility of CSRF attacks. I described one such scenario in a previous
 email.
 http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0072.html

 In terms of costs, I was referring to industry-wide cost/benefit analysis.
 There are large industry-wide costs whenever a new technology is added to
 the web world in terms of implemeentation within browsers, changes to web
 servers to take advantage of the technology, and educational costs. I'm
 not sure that Access Control as currently defined would benefit the
 industry sufficiently to justify these costs.

 >
 > I'm trying to understand if you're saying "access-control is a bad
 > idea for technical reason X and Y" or if you're just saying "this
 > solution is a better solution" to which I'm trying to point out that
 > enabling access to XML documents is a well-stated goal that
 > JSONrequest doesn't seem to support and preserving the current
 > border-protection security mechanisms that rely on browser
 > sandboxing and are widely employed by most corporations is still
 > necessary for the time-being.

 Access Control isn't bad, but I don't like some of the ways that it is
 designed today. I believe that policy enforcement belongs on the server,
 not the client. I don't understand why there is a language for
 whitelisting and blacklisting domains that are allowed and expect most
 people would use either * (allow everyone) or allow other subdomains
 within their own domain. I think it would be better if cookies were not
 transmitted to domain B from a web site on domain A because of CSRF risks.
 Because of these various issues, I'm not sure that Access Control as it is
 designed today is a win for the industry.

 Recent discussion has shined the light on JSONRequest as an alternative. I
 have looked again at JSONRequest because of that discussion, and my
 analysis it that it looks more attractive to me as the basis for allowing
 cross-site access to data. One big advantage with JSONRequest is that it
 is possible to deliver an implementation of it via JavaScript today, where
 the implementation can look at the browser to see if JSONRequest is
 implemented natively, and if not, then insert a dynamic script tag under
 the hood to accomplish the same result. That means that if the community
 rallied around JSONRequest as the right way forward, then they could start
 posting web services that supported JSONRequest as soon as a JSONRequest
 JavaScript library were made available. (Probably about 100 lines of
 JavaScript.) Kris Zyp has a JavaScript implementation of JSONRequest at
 http://code.google.com/p/crosssafe/. Access Control as currently designed,
 on the other hand, can't be used on a broad basis until it ships with
 high-marketshare browsers and large numbers of the communities upgrade to
 those browsers.


 >
 > --Brad
 >