Ian Hickson | 1 Jan 15:00 2008
Picon

RE: Comments on: Access Control for Cross-site Requests


On Mon, 31 Dec 2007, Close, Tyler J. wrote:
>
> 1. Browser detects a cross-domain request
> 2. Browser sends GET request to /1234567890/Referer-Root
> 3. If server responds with a 200:
>     - let through the cross-domain request, but include a Referer-Root 
> header. The value of the Referer-Root header is the relative URL /, 
> resolved against the URL of the page that produced the request. HTTP 
> caching mechanisms should be used on the GET request of step 2.
> 4. If the server does not respond with a 200, reject the cross-domain 
> request.

This is a very dangerous design. It requires authors to be able to 
guarentee that every resource across their entire server is capable of 
handling cross-domain requests safely. Security features with the 
potential damage of cross-site attacks need to default to a safe state on 
a per-resource basis, IMHO.

Furthermore, relying on a 200 OK response would immediately expose all the 
sites that return 200 OK for all URIs to cross-site-scripting attacks. 
(The high-profile case of the Acid2 test's 404 page returning a 200 OK 
recently should caution us against assuming that sites are all currently 
safe in this regard -- if even the Web Standards Project can run into 
issues like this, what hope is there for everyone else?)

(There is also the problem that any fixed URI has -- /robots.txt 
/w3c/p3p.xml, etc are all considered very bad design from a URI point of 
view, as they require an entire domain to always be under the control of 
the same person, whereas here we might well have cases where partitions of 
(Continue reading)

Picon

Re: [widgets] Open Ajax Alliance


Marcos, Jon,

Happy New Year!!

I was wondering why the OOA and the W3C are working on different specs 
regarding Widget descriptors, differentiating between "desktop widgets" 
and "web widgets". Perhaps I don't understand well the issue but at 
first sight I think that there should be only one Widget Descriptor 
format, which of course, could be extended to address the needs of 
different communities. But at least, the baseline should be common, 
shouldn't it?

Best Regards

Marcos Caceres escribió:
> Hi,
> During the previous face 2 face meeting in Boston, Jon Ferraiolo of
> the Open Ajax Alliance demonstrated a widget proposal and a set of
> adapters which may be of interest to the working group. The OAA specs
> are more closely aligned with "web widgets" (akin to iGoogle gadgets)
> rather than "desktop widgets".  However, there is plenty of potential
> for cross-pollination of ideas between the groups. Please see in
> particular:
>
> http://www.openajax.org/member/wiki/images/e/e8/OpenAjaxWidgets_IBM_20071019.pdf
> http://www.openajax.org/member/wiki/IDE_Widget_Metadata_Strawman_Proposal
>
> Kind regards,
> Marcos
(Continue reading)

Arthur Barstow | 2 Jan 14:21 2008
Picon

Fwd: Comments on: Access Control for Cross-site Requests


Hi Doug,

Tyler Close quotes you in the e-mail below (archived at [WAF- 
Archive]) regarding the W3C's Access Control for Cross-site Requests  
spec (see [AC] for the last publication by the W3C and [AC-Editor]  
for the latest version of the Editor's Draft).

Tyler's e-mail resulted in an interesting exchange (follow [WAF- 
Archive]). I invite your comments on this thread as well as an  
elaboration on "more elegant and reliable approaches to providing a  
safe alternatives to the script tag hack".

Regards, Art Barstow

[WAF-Archive] <http://lists.w3.org/Archives/Public/public-appformats/ 
2007Dec/0054.html>
[AC] <http://www.w3.org/TR/access-control/>
[AC-Editor] <http://dev.w3.org/2006/waf/access-control/>

Begin forwarded message:

> Resent-From: public-appformats <at> w3.org
> From: "ext Close, Tyler J." <tyler.close <at> hp.com>
> Date: December 19, 2007 8:17:29 PM EST
> To: "public-appformats <at> w3.org" <public-appformats <at> w3.org>
> Subject: Comments on: Access Control for Cross-site Requests
> Archived-At: <http://www.w3.org/mid/ 
> C7B67062D31B9E459128006BAAD0DC3D10BA654A <at> G6W0269.americas.hpqcorp.net>
>
(Continue reading)

Jon Ferraiolo | 2 Jan 17:09 2008
Picon

Re: [widgets] Open Ajax Alliance

Hi Jose,
Short answer, yes. Most of the people involved at OpenAjax and W3C agree that widget developers want a single set of requirements for their widgets that will provide maximum range of interoperability, whether the widgets are launched from a desktop OS (e.g., Apple Dashboard, Vista Sidebar), and mobile OS (e.g., Nokia Widgets), a mashup application (e.g., IBM's QEDwiki), or used as a component within an Ajax-powered RIA. This has caused me to participate in W3C WAF (at least on the public lists) and for Marcos to start the process of joining OpenAjax Alliance.

Long answer, maybe. At OpenAjax Alliance, we are looking at a transcoder technology approach which will allow mashup frameworks to use existing widget formats as they are today (e.g., Google Gadgets and Apple Dashboard widgets) by defining a standard XML infoset and a set of open source transcoders for popular (usually proprietary) gadget and widget formats. With the transcoder approach, W3C Widgets and OpenAjax Alliance Gadgets do not necessarily have to be exactly the same format because we can write a transcoder from W3C Widgets into the OpenAjax Alliance Gadgets format. However, the closer they are, the better the transcoder. The most important reason why we don't want to commit to grand unification is that the coordination process is likely to stretch out the time before either W3C or OpenAjax Alliance would have something that the community could use. It is hard enough for W3C to deliver a specification to its target constituency (desktop and mobile widgets such as for Opera and Nokia platforms) and hard enough for OpenAjax Alliance to herd all of the cats in the mashup space. Therefore, for the time being, W3C WAF and OpenAjax Alliance will be coordinating to attempt to keep the two specifications as close as possible, but we are assuming that there will be two separate specifications.

Jon Ferraiolo
IBM & OpenAjax Alliance

José Manuel Cantera Fonseca <jmcf <at> tid.es>


          José Manuel Cantera Fonseca <jmcf <at> tid.es>
          Sent by: public-appformats-request <at> w3.org

          01/02/2008 04:28 AM


To

Marcos Caceres <marcosscaceres <at> gmail.com>, Jon Ferraiolo/Menlo Park/IBM <at> IBMUS

cc

"public-appformats <at> w3.org (public)" <public-appformats <at> w3.org>

Subject

Re: [widgets] Open Ajax Alliance


Marcos, Jon,

Happy New Year!!

I was wondering why the OOA and the W3C are working on different specs
regarding Widget descriptors, differentiating between "desktop widgets"
and "web widgets". Perhaps I don't understand well the issue but at
first sight I think that there should be only one Widget Descriptor
format, which of course, could be extended to address the needs of
different communities. But at least, the baseline should be common,
shouldn't it?

Best Regards

Marcos Caceres escribió:
> Hi,
> During the previous face 2 face meeting in Boston, Jon Ferraiolo of
> the Open Ajax Alliance demonstrated a widget proposal and a set of
> adapters which may be of interest to the working group. The OAA specs
> are more closely aligned with "web widgets" (akin to iGoogle gadgets)
> rather than "desktop widgets".  However, there is plenty of potential
> for cross-pollination of ideas between the groups. Please see in
> particular:
>
> http://www.openajax.org/member/wiki/images/e/e8/OpenAjaxWidgets_IBM_20071019.pdf
> http://www.openajax.org/member/wiki/IDE_Widget_Metadata_Strawman_Proposal
>
> Kind regards,
> Marcos
>
> ps: this closes ACTION-142 [1].
> [1] http://www.w3.org/2005/06/tracker/waf/actions/142
>
>  




Close, Tyler J. | 2 Jan 19:26 2008
Picon

RE: Comments on: Access Control for Cross-site Requests


Hi Ian,

Ian Hickson wrote:
> On Mon, 31 Dec 2007, Close, Tyler J. wrote:
> >
> > 1. Browser detects a cross-domain request
> > 2. Browser sends GET request to /1234567890/Referer-Root
> > 3. If server responds with a 200:
> >     - let through the cross-domain request, but include a
> Referer-Root
> > header. The value of the Referer-Root header is the relative URL /,
> > resolved against the URL of the page that produced the request. HTTP
> > caching mechanisms should be used on the GET request of step 2.
> > 4. If the server does not respond with a 200, reject the
> cross-domain
> > request.
>
> This is a very dangerous design. It requires authors to be able to
> guarentee that every resource across their entire server is capable of
> handling cross-domain requests safely. Security features with the
> potential damage of cross-site attacks need to default to a
> safe state on
> a per-resource basis, IMHO.

Sure, but the question is: "Who's responsibility is it?". In my opinion, it is the server's responsibility
to ensure a safe default for each resource. You seem to have the perspective that it's the client's responsibility.

With the "OPTIONS *" request, or "GET /special/URL" request, I am just trying to establish that the client
and server know what the other is saying. We can then leave each to protect its own interests. This division
of labour requires the least amount of coordination between client and server and puts the enforcement
task with the party who most wants a policy enforced. In my opinion, these are the two high order bits when
judging a solution to this problem.

By giving the thumbs up to the client's query about understanding of the Referer-Root header, the server is
saying: "Yes, I've got a filter in place to control access to individual resources. Go ahead and send the
requests through, but label them with their originator information. I've got it covered from there." I
imagine the sysadmin for the server would setup this filtering and then provide some guidelines to web
page authors on how to activate cross-domain requests. These guidelines may very well look much like the
ones this WG has designed. The difference is that they are an agreement between web page authors and their
own server, not between web page authors and all client software for the Web. The former means Web content
publishers can develop their own policy and enforcement mechanisms, and have confidence in how they are
being used, regardless of which client software any user may have.

We can twiddle with the details of how client and server establish that both understand the meaning of the
new Referer-Root header. I've offered 2 possibilities: one that fits web-arch better, and one that fits
the WG's self-imposed rule of no modifications to server software. I only offered these possibilities to
show that the problem can be solved in this way. If the WG really needs me to design the exact details of this
handshake, I'll do so, but I imagine WG members are equally capable to this task. I suspect this handshake
can also be designed so as not to require modification of the server's software. I don't think this is a high
priority, but I undertand that this WG does. For example,

> Furthermore, relying on a 200 OK response would immediately
> expose all the
> sites that return 200 OK for all URIs to cross-site-scripting attacks.

Fine, so have the server respond with something unmistakeable. In the extreme, the server could be
required to respond with a text entity containing a large random number whose value is specified in the rec.

> (There is also the problem that any fixed URI has -- /robots.txt
> /w3c/p3p.xml, etc are all considered very bad design from a
> URI point of
> view, as they require an entire domain to always be under the
> control of
> the same person, whereas here we might well have cases where
> partitions of
> a domain are under the control of particular users, with the different
> partitions having different policies.)

In which case it is only necessary that whoever has control of the special URL has coordinated with the other
users of the host. These are all arrangements that can be made server side, without exposing the details to clients.

Again, I think the "OPTIONS *" request is the more acceptable design, since it doesn't use a well-known URL,
but I also don't think this issue is that big a deal.

> Furthermore, there is a desire for a design that can be applied purely
> static data where the user has no server-side control whatsoever. With
> your proposal, even publishing a single text file or XML file
> with some
> data would require scripting, which seems like a large onus to put on
> authors who are quite likely inexperienced in security matters.

Again, this is server-side setup. Particular servers may well choose to deploy technology much like what
this WG has created. We just don't have to say that everyone has to do it that way. We don't need that broad an
agreement. These technology choices can be confined to the server-side. We only need a way for client and
server to signal the presense of such a mechanism, in particular, declaring that each understands the
meaning of the Referer-Root header.

--Tyler

Anne van Kesteren | 2 Jan 19:39 2008
Picon

Re: Comments on: Access Control for Cross-site Requests


On Wed, 02 Jan 2008 19:26:03 +0100, Close, Tyler J. <tyler.close <at> hp.com>  
wrote:
> Sure, but the question is: "Who's responsibility is it?". In my opinion,  
> it is the server's responsibility to ensure a safe default for each  
> resource. You seem to have the perspective that it's the client's  
> responsibility.

Most XSS problems have been due to lack of knowledge of the authors. SQL  
injection is a big one for instance. Also script injection due to lack of  
escaping on the server side. Trusting the authors to do the right thing  
does not seem responsible at all.

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Close, Tyler J. | 2 Jan 19:45 2008
Picon

RE: Comments on: Access Control for Cross-site Requests


Anne van Kesteren wrote:
> On Wed, 02 Jan 2008 19:26:03 +0100, Close, Tyler J.
> <tyler.close <at> hp.com>
> wrote:
> > Sure, but the question is: "Who's responsibility is it?".
> In my opinion,
> > it is the server's responsibility to ensure a safe default for each
> > resource. You seem to have the perspective that it's the client's
> > responsibility.
>
> Most XSS problems have been due to lack of knowledge of the
> authors. SQL
> injection is a big one for instance. Also script injection
> due to lack of
> escaping on the server side. Trusting the authors to do the
> right thing
> does not seem responsible at all.

Who said anything about trusting web content authors? Like I said, a mechanism like the one this WG has
designed may well be deployed server-side. We just don't have to rely on the browser to understand the
mechanism and enforce it. This same program logic can reside server-side.

--Tyler

Anne van Kesteren | 2 Jan 20:55 2008
Picon

Re: Comments on: Access Control for Cross-site Requests


On Wed, 02 Jan 2008 19:45:02 +0100, Close, Tyler J. <tyler.close <at> hp.com>  
wrote:
> Who said anything about trusting web content authors? Like I said, a  
> mechanism like the one this WG has designed may well be deployed  
> server-side. We just don't have to rely on the browser to understand the  
> mechanism and enforce it. This same program logic can reside server-side.

It's the authors that need to deploy this on their server. The concept is  
based around that. To keep it safe per resource seems a whole lot better  
than per "server". It seems to me that we (fundamentally, maybe) disagree  
how this should work. I'll make sure your objection to the approach  
outlined in the specification and the proposed alternative are given  
consideration during the CR transition call; when we get there.

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Douglas Crockford | 2 Jan 18:58 2008

Re: Comments on: Access Control for Cross-site Requests


> > Below are comments from Doug Crockford:
>
> > [...] I believe there are more elegant and reliable approaches to  
> > providing a safe alternatives to the script tag hack.

> I'd be interested in hearing about such a proposal.

One such proposal is JSONRequest (http://json.org/JSONRequest.html). An implementation for FireFox
is available at http://crypto.stanford.edu/jsonrequest/.

JSONRequest does not allow the server to abdicate its responsibility of deciding if the data should be
delivered to the browser. Therefore, no policy language is needed. JSONRequest requires explicit
authorization. Cookies and other tokens of ambient authority are neither sent nor delivered.

JSONRequest has a significantly nicer programming model than XMLHttpRequest. 

JSONRequest only supports one encoding format: JSON. Some people see this as a disadvantage, but I think it
is not. It can be used to wrap any other format.

    {"xml": "<?xml..."}

Ric Johnson | 2 Jan 21:29 2008
Picon

Re: Comments on: Access Control for Cross-site Requests


I think JSON is great, but the main problem with JSONRequest is
implementations in other browsers.

Doug: Can you add any links to http://json.org/JSONRequest.html ?

Jon Ferraiolo:  I know you have been working with Microsoft on
OpenAjax - Do you know how IE8 _might_ support JSON natively?

Thanks,
Ric Johnson
http://json.Com

On Jan 2, 2008 12:58 PM, Douglas Crockford <douglas <at> crockford.com> wrote:
>
> > > Below are comments from Doug Crockford:
> >
> > > [...] I believe there are more elegant and reliable approaches to
> > > providing a safe alternatives to the script tag hack.
>
> > I'd be interested in hearing about such a proposal.
>
> One such proposal is JSONRequest (http://json.org/JSONRequest.html). An implementation for FireFox
is available at http://crypto.stanford.edu/jsonrequest/.
>
> JSONRequest does not allow the server to abdicate its responsibility of deciding if the data should be
delivered to the browser. Therefore, no policy language is needed. JSONRequest requires explicit
authorization. Cookies and other tokens of ambient authority are neither sent nor delivered.
>
> JSONRequest has a significantly nicer programming model than XMLHttpRequest.
>
> JSONRequest only supports one encoding format: JSON. Some people see this as a disadvantage, but I think
it is not. It can be used to wrap any other format.
>
>     {"xml": "<?xml..."}
>
>
>


Gmane