Jon Ferraiolo wrote:
[EMAIL PROTECTED] wrote on 01/06/2008 12:30:32 AM:
>
> Jon Ferraiolo wrote:
> > > You failed to reply to the XSLT and XBL remarks that the JSON
thingie
> > > does not address. These are important use cases.
> >
> > IMO the JSON use case is a couple of orders of magnitude more
important
> > than the XSLT or XBL requirements. JSON is a primary format for
> > cross-site data exchange today, and is likely to grow in usage in the
> > coming years as more people discover its virtues.
>
> It's very hard to do a fair comparison between JSON and cross-site XHR
> given that only JSON actually works today. So of course it's going to be
> the primary format today.
There are various people in the Ajax community, such as Doug Crockford,
who promote JSON instead of XML for data delivery. In fact, Doug
designed JSONRequest to only work with JSON. My opinion is that I would
like to see both XML and JSON as first class options, but if I had a
choice between the two, I would pick JSON because it is the technology
used today for cross-site data delivery by the leading edge developers
and because a JSON-based approach offers incremental approaches to the
community whereby web sites can deliver JSON to support today's dynamic
SCRIPT tag hack in today's browsers while also supporting newer browsers
later that support JSONRequest. Therefore, JSON/JSONRequest allows
immediate adoption because there is a straightforward fallback for old
browsers (i.e., dynamic SCRIPT tag).
Therefore, I would expect one of the Access Control requirements to say
"MUST support JSON as a primary data delivery format for web-based
services" versus what the spec does today, which is treat JSON as a
second-class format to XML. (I say "second-class" because it is possible
with the current Access Control spec to send access control PIs within
the XML content but with JSON the web site developers can only provide
access information via HTTP headers.)
>
> > Overall, I would prefer it if browsers would adopt JSONRequest rather
> > than Access Control. JSONRequest was designed carefully from a
security
> > perspective, such as the random delay feature. It achieves its results
> > *without* sending cookies (the cookie feature in Access Control scares
> > lots of us because of CSRF issues). I recognize that the WAF committee
> > has spent lots of time and effort on the existing Access Control,
but I
> > think the community would be better served by having browsers
implement
> > JSONRequest instead. (JSONRequest would be even better if it
allowed XML
> > data in addition to JSON data.)
>
> I'm not sure why you think there's an either-or scenario here. Firefox 3
> will most likely support both JSONRequest (or some variant thereof, I'm
> not directly working on that part) as well as cross-site XHR using
> access-control.
Please let's not develop two new features that address the same
objective. The community needs to unify around one and only mechanism,
be it Access Control or JSONRequest or minor enhancements to the SCRIPT
tag or something else. The key objective is community-wide
interoperability which is best served by a single standard, not multiple
standards. Besides confusing and dividing the community with multiple
features trying to address the same thing, you double the extra hacker
attack service.
If you go along with the single standard argument, then the question
which one standard (Access Control vs JSONRequest vs other) should be
used? It might be time for the WAF WG to take time to query the browser
vendors and the rest of the community for feedback on Access Control in
general, but in particular how it relates to JSONRequest. It is clear
that Opera and Mozilla are engaged in the Access Control spec, but what
about the Safari team and (probably more importantly) the IE team,
particularly with regard to security? What do the big web service
providers think (Yahoo, Amazon, Google, Salesforce, etc.)? Doug
Crockford is with Yahoo and he invented JSONRequest, but that was last
year and I don't know whether he represents Yahoo's entire position.
I don't actually agree that a single standard is all we need. At least
none of the standards I've heard proposed I think would cover all needed
scenarios.
First of all JSONRequest is clearly not well suited for things like XSLT
or XBL or any other scenario where you want to use an XML resource. Yes,
JSON can be used to envelope XML data, but you couldn't put:
<?xml-stylesheet type="text/xsl"
href="http://example.org/jsonrequest/xslt.js";>
at the top of an XML document and have it work.
Incidentally, I am still not yet convinced that the community benefits
from any of the above, and that "none" might be the best answer. This
gets back to my question from a couple of weeks ago about what are the
target use cases for Access Control. Is it attempting to allow POST
operations to sensitive web sites such as banks? (I hope not.) Is it
attempting to allow multiple-sub-domain intranets to talk to talk with
each other in a convenient manner (that is more reasonable)? Is it
attempting to support read-only (GET) access to non-sensitive web
services, such as government weather services (more reasonable)? Is it
attempting to support read-write (GET/POST) access to non-sensitive
community sites (e.g., Facebook or MySpace)? It is hard to provide solid
feedback unless we have a clear understanding of what are the target
workflows for the specification.
I agree that making banks use this would make me nervous too. But then
again, banks always make me nervous :)
The use cases I have in mind is to allow simple cross-site communication
to allow mash-up style services. Including use of user specific data
such as calendars.
Also to allow reusable resources like XBL2 widget sets, XSLT stylesheets
etc. Ideally CSS, javascript and images would have used something like
this to allow cross-site use of resources. If that had been done
originally we wouldn't have the problem of hot-linked images.
> A lot of people has said that sending cookies and auth credentials
> 'scares' them, however no one has been able to show that it does in fact
> introduce new attack vectors.
If Access Control becomes a standard and gets widely adopted, there are
definitely going to be new CSRF attack vectors if cookies are sent. I
believe one of the reasons the community has been too worried about
Access Control and CSRF is that many of us doubt that it will get widely
adopted, so therefore the risk is minimal.
But if it *were* widely adopted, here is one attack vector. There will
be tons of Web2.0 community sites using XHR and Ajax, and if Access
Control is popular, then a significant percentage of these web site will
opt-in to Access Control. It is human nature to take the easy route and
develop web sites that choose to Allow every web site (i.e., "*") for
GET and/or POST because many community-site web developers have little
imagination about the value of the information at their site. For
example, DalmationLovers.org might be advertising supported (with the
advertisements isolated in IFRAMEs) and might feel that the information
in their database is harmless. Now, let's suppose that one of the ads
comes from evil.com and includes a mouseover event handler that invokes
XHR to the DalmationLovers.org site, leveraging the session cookie for
that site. Users often post personal information (email, phone number,
login, password) within community web sites, and the web site might
offer a POST service that allows the email address to be changed and
then another POST service that will send your account information,
including password, to be sent to the designated email address. Using
this information, the hacker can try to login to various banks using the
same login and password because many people use the same logins and
passwords for multiple sites.
This does not seem like a new attack vector. If DalmationLovers.org has
a service that lets you POST an email address to which all your personal
data is sent, then they are hosed already. Anyone can write a web page
with a <form action="dalmationlovers.org/personaldata.cgi"> that POSTs
data to the DalmationLovers.org service. This POST will include the
users cookies and auth credentials. That is how the web already works.
In fact, by not including cookies and auth credentials you are just
giving yourself a false sense of security. Just like many sites use
cookies or http auth to authenticate a user, other sites simply use the
fact that you can reach the server as authentication. There are many
servers sitting behind firewalls that don't use any means of
authentication, but simply assume that as long as you can reach the
server you are an employee or otherwise trusted party. So if JSONRequest
relies on the lack of cookies and auth credentials to protect the user
or server, how are these firewalled servers protected?
> > For XSLT and XBL, shouldn't browsers allow cross-site (GET) access in
> > the same way it does for CSS stylesheets and SCRIPT tags?
>
> Now *that* if anything would introduce new attack vectors, no? I
> personally hate the fact that CSS and SCRIPT can load data cross site
> and I would love to disable that ability in firefox and replace it with
> something more secure. Unfortunately that would break the web :(
Yes, those would be new attack vectors, but at least they have
functional similarities to existing features (XSLT ~= CSS, XBL ~=
SCRIPT) and, most importantly, these are GET operations only.
Yes, they are GET operations, but they let you read the result of the
GET which is of huge importance. As a server operator I would be very
upset if this was allowed.
Server vendors are already required to know that all of their content
can be read cross server if the contents happen to look like javascript.
I'd hate for the same to be true if their contents looked like XSLT
(which only requires a single attribute to turn any arbitrary XML file
into a stylesheet) or XBL.
But I fully agree that there should be some way that *new* web sites
could tell browsers to go into a strict security mode that would
disabled cross-domain access, including disabling existing cross-domain
support for SCRIPT, IMG and other things. That way a mashup web site
developer could be sure that the only cross-site requests that were made
were accomplished only via approval from the mashup container logic
rather than some nasty hidden logic within one of the mashup components.
Something like that would be nice indeed. Though you could never be
suare that only cross-site requests are made via approved mechanisms as
older browsers are always going to be out there.
/ Jonas
