Re: [whatwg] JSONRequest

[Lachlan Hunt]

Gervase Markham wrote:

Douglas Crockford wrote:

I have modified the JSONRequest proposal so that the Content-Type in
both directions must be application/json/request.


Er, why? Having two slashes in a content type is either extremely weird
or completely illegal (glancing at the RFC, I'm not certain which).
http://www.mhonarc.org/~ehood/MIME/2046/rfc2046.html


RFC 2616 states:

   media-type = type "/" subtype *( ";" parameter )
   type   = token
   subtype= token

   token  = 1*
   separators = "(" | ")" | "<" | ">" | "@"
  | "," | ";" | ":" | "\" | <">
  | "/" | "[" | "]" | "?" | "="
  | "{" | "}" | SP | HT

And RFC 2045 says something very similar.  So the second '/' is indeed 
illegal.


If application/json isn't acceptable (though I don't know why it 
wouldn't be), then try a hyphen instead: application/json-request


--
Lachlan Hunt
http://lachy.id.au/

Re: [whatwg] JSONRequest

[Anne van Kesteren]

Quoting Douglas Crockford <[EMAIL PROTECTED]>:
The central idea with the JSONRequest is that it is exempted from the 
Same Origin Policy. It allows for exchanging data with a server in 
any domain that specifically accepts JSONRequests.


In order to be exempted from the Same Origin Policy, there are 
several restrictions on JSONRequest in order to avoid data leakage or 
authorization leakage.


JSONRequest is not intended to replace XMLHttpRequest. It is intended 
to be an alternative to the use of dynamic script tags to access data 
from other domains.


Given that it can't be used today anyway I'd rather have that the WHATWG, W3C
came up with a more broader solution to the cross domain security problem.
(AFAIK some work is going on at the W3C in that area.)


--
Anne van Kesteren

Re: [whatwg] JSONRequest

[Henri Sivonen]

On Mar 30, 2006, at 17:21, Douglas Crockford wrote:

The central idea with the JSONRequest is that it is exempted from  
the Same Origin Policy. It allows for exchanging data with a server  
in any domain that specifically accepts JSONRequests.


Why is it necessary to allow this in the browser? When would you be  
able actually use the feature even if Opera, Apple and Mozilla  
shipped support today?


What's wrong with having the browser talking to the origin server  
using XMLHttpRequest and the server talking to the third party  
(sanitizing data as necessary before passing it to the browser)?


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] JSONRequest

[S. Mike Dierken]

Wow. Pretty, uh, interesting.
Why not just have XmlHttpRequest configurable to not share cookies, not
share auth, not accept anything but xml, etc.?

> Does this allow improperly secured applications to be accessed?
> Application that are looking GET cannot be accessed because JSONRequest
only uses POST.
So you would use POST rather than GET just in case an unsecured web
application were contacted?
In the situation that an unsecured web application were contacted, how often
would a POST potentially modify data compared to a GET? (like
http://www.sillyexample.org/folder?id=27&operation=delete - often no content
body is required, and likely the content-type is unchecked anyway).
A poorly written server-side application is doomed no matter what, so you
might as well use a safe HTTP request method.

> If the HTTP status code is not 200 OK, then the request fails. 
That doesn't sound good. What particular situations are bad? Re-direction
makes servers easier to support and maintain.

> Any cookies in the response header are discarded. 
That makes sense, no information leakage.

> JSON messages are never cached.
And you wouldn't use caching but you'd like to avoid a denial-of-service
style attacks?

> By switching to a policy of responding only to well-formatted JSONRequest,
applications can be made more secure.
Do you mean client-side applications (the browser) or the server side?

> JSONRequest is designed to support duplex connections. 
Pretty standard stuff - I've done the same with XmlHttpRequest, and I think
lots of folks have.


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Douglas 
> Crockford
> Sent: Wednesday, March 29, 2006 7:41 PM
> To: [EMAIL PROTECTED]
> Subject: [whatwg] JSONRequest
> 
>  > If application/json isn't acceptable (though I don't know 
> why it wouldn't be), > then try a hyphen instead: 
> application/json-request
> 
> I like application/json-request. That is a good suggestion.
> 
> The issue is to provide a way of identifying JSONRequest 
> transactions that cannot be confused with legacy applications.
> 

Re: [whatwg] JSONRequest

[Lachlan Hunt]

Douglas Crockford wrote:
If application/json isn't acceptable (though I don't know why it 
wouldn't be), then try a hyphen instead: application/json-request


The issue is to provide a way of identifying JSONRequest transactions 
that cannot be confused with legacy applications.


To me, this just feels like misuse of the MIME type.  It should describe 
the content type of the message body, not the protocol/method used to 
access it.  Maybe a parameter could be used instead.


i.e.  application/json;param=value

Though, as I'm still not exactly sure what the new MIME type idea is 
supposed to express, I've got no idea what the parameter could be called.


--
Lachlan Hunt
http://lachy.id.au/

Re: [whatwg] JSONRequest

[Gervase Markham]

Douglas Crockford wrote:
> I have modified the JSONRequest proposal so that the Content-Type in
> both directions must be application/json/request.

Er, why? Having two slashes in a content type is either extremely weird
or completely illegal (glancing at the RFC, I'm not certain which).
http://www.mhonarc.org/~ehood/MIME/2046/rfc2046.html

Gerv

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/21/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Chris Holland wrote:
> > That's where the extra HTTP header would come-in:
> > "X-Allow-Foreign-Hosts": Forcing developers who expose such a service,
> > to make the conscious choice to expose data to the world, what Jim
> > refers to as "OPT-IN".
>
> I believe the usual objection to this (which was raised when I suggested
> something similar) is that some services respond to requests by doing
> something ]

The flaw in that argument is that img.src="..." is equivalent.  If the
initial challenge request is a GET, which it of course the spec can
require.

>- therefore, a model which allows cross-site requests has to
> check that the request is permitted before making it, not before
> processing the result.

Certainly, that's one of the issues with the header approach - the GET
and check for header or check magic URL for an XML doc, then make the
request should be safe from such issues. Both Mozilla dand Flash
already have that deployed and working.

Jim.

Re: [whatwg] JSONRequest

[Chris Holland]

Tell me whether I'm understanding correctly the issue you're mentioning:

For example I have a service at:

http://myIntranetUtilityServer/utilities/rotateAllServerLogs

If I was evil and knew the various services living at that intranet, I
could craft a document on my web site hoping to lure employees,
calling this service thru a CAXHR, or JSONRequest, even if I wasn't
able to read the payload of the request, because the
X-Allow-Foreign-Hosts (or X-Allow-Foreign-Documents-To-Read-This-Data,
heh) header was never sent.

This would cause all server logs to rotate! yargh!

But today, i'm already able to trigger such security hole in many
ways, using existing HTML and DOM constructs:

- I can create a hidden form, whose target is a hidden iframe
- as soon as the form and iframe are rendered, i can have a script
simply formObject.submit()

Now, thanks to cross-frame scripting policy, i won't be able to READ
the results of the request, which live in the hidden iframe. But the
request has already been made. Harm has already been done to a
badly-secured service.

I could also likely trigger a similar HTTP request by simply pointing
an image to that URL. I could have actually just made that service URL
the source of my hidden iframe. I could have made that service URL the
src attribute of a script tag. I could have opened that URL in a
pop-up window, before closing it on a timer ...

etc.

But the end result remains, i can't read or access the data that the
service returned. Even though I have caused evil: all log files got
rotated!

Due to the fact that CAXHR and JSONRequest are pretty adamant about
not sending any cookies or cached basic authentication credentials,
attackers would likely resort to those methods last, likely preferring
an iframe, an image, a script, a form as first vectors of attack.

On 3/20/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Chris Holland wrote:
> > That's where the extra HTTP header would come-in:
> > "X-Allow-Foreign-Hosts": Forcing developers who expose such a service,
> > to make the conscious choice to expose data to the world, what Jim
> > refers to as "OPT-IN".
>
> I believe the usual objection to this (which was raised when I suggested
> something similar) is that some services respond to requests by doing
> something - therefore, a model which allows cross-site requests has to
> check that the request is permitted before making it, not before
> processing the result.
>
> I believe the Mozilla Foundation has done some work in this area using a
> top-level site-wide XML document to specify what services can be
> accessed cross-domain; but I don't know the details. Perhaps someone
> else can chime in with them.

I believe this might be it:

http://lxr.mozilla.org/seamonkey/source/extensions/webservices/docs/New_Security_Model.html

As suggested by Doron Rosenberg in this message:
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-March/003156.html



--
Chris Holland
http://chrisholland.blogspot.com/

Re: [whatwg] JSONRequest

[Gervase Markham]

Chris Holland wrote:
> That's where the extra HTTP header would come-in:
> "X-Allow-Foreign-Hosts": Forcing developers who expose such a service,
> to make the conscious choice to expose data to the world, what Jim
> refers to as "OPT-IN". 

I believe the usual objection to this (which was raised when I suggested
something similar) is that some services respond to requests by doing
something - therefore, a model which allows cross-site requests has to
check that the request is permitted before making it, not before
processing the result.

I believe the Mozilla Foundation has done some work in this area using a
top-level site-wide XML document to specify what services can be
accessed cross-domain; but I don't know the details. Perhaps someone
else can chime in with them.

Gerv

Re: [whatwg] JSONRequest

[Chris Holland]

Yeah, my main issue with JSONRequest right now is that we're coupling
two things:

1) protocol specifications to cater to various business needs.
2) security of that protocol.

Doug, you're basically making the assumption that

1) because JSONRequest will work in entirely different ways currently
not implemented by any service
2) it will be secure

I would *love* to be able to use a clean JSONRequest from within the
same host, and have access to cookies and basic http auth, to
transparently conduct transactions, because it's more elegant and
lightweight than some 

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/20/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
>  > Or indeed wrote your script before this JSONRequest was invented.
>
> I think I see where you are confused. A pre-JSONRequest JSON application
> will be using GET, or POST with a conventional POST body.

What exactly is a "conventional POST body"

> JSONRequest cannot generate a GET, so those interfaces are
> safe,

Many webservers will return data in response to a POST even if
expecting a GET, a bug perhaps, but there's no specification which
prevents it.

> and it cannot generate a conventional POST
> body, so those applications are safe, too.

I have lots of applications that POST json to the server, and return
more JSON, for exactly the reason your proposing this interface now.

> If an application is so badly implemented that it accepts dangerous POSTs (we
> already determined that JSONRequest is safer than form.submit in this regard)

Where did we determine this?   Please start sharing your security
analysis, it seems rather lacking to me, so I'm not really prepared to
trust blanked statements of what you've determined.

> So, is this a problem? No. First, JSONRequest will reject the response and not
> return to the script because the Content-Type is not application/json.
> application/json is only now being registered as MIME media type. Legacy
> applications should not have been using it.

_SHOULD_  see, you're relying on perfect systems everywhere, that is
not an appropriate reliance, and as there are other methods - opt-in
methods - that allow cross domain scripting to be done more securely,
I simply don't see the point of not using them, and go for these poor
security methods you're advocating.

Also, someone using a application/vnd.someone.json will likely change
their server configuration to application/json as soon as it's
registered, so legacy apps will be using the appropriate mime-type.

> So, to repeat, JSON introduces no new security vulnerabilities for the legacy
> JavaScript data formats of six years ago.

You just admitted, that it did, so please stop repeating that phrase,
you may want to use a phrase such as "few" or "rare" or "only in
certain situations" are new security vulnerabilities present, but
there are certainly not none, and your refusal to admit this in the
document, when you do here suggests that you do not want your
specification to be reviewed fairly by all concerned.

> I would very much like to see the details of a specific attack in which a 
> legacy
> application which depends solely on firewall locality for its security is
> compromised by JSONRequest.

I have some where all that would be needed is a
application/x--jl-message-result becomes a application/json -
something that is likely to happen (without me knowing) once the the
mime-type is registered.  Of course it's behind a firewall, so I can't
direct you to it, but it meets all of the other restrictions on JSON
you've listed above.  The data protected is pretty innocuous, but I'd
be crazy to think I was the only person doing it, why do you think I
am?

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Lachlan Hunt]

Gervase Markham wrote:

Douglas Crockford wrote:

The JSONRequest does only one thing:



Are you planning to take the excellent advice from 
to change the name? 


That was me.  Nice to see I'm quite memorable :-)


The name XmlHttpRequest sucks because it doesn't
necessarily return XML, and it doesn't have to be over HTTP.


I agree, but considering we're stuck with it...


Why not just call it "Request",


Why not just reuse XMLHttpRequest?


and have an API to set the Accept: header,


XHR already does.

var r = new XMLHttpRequest();
r.open("post", "http://example.org/json";)
r.setRequestHeader("Accept", "application/json");
r.setRequestHeader("Content-Type", "application/json")
r.send(jsonData);

To make XMLHttp as secure as JSONRequest claims to be (assuming for the 
moment that the proposal can be made completely secure), we would just 
need to find a way to tell the UA to allow cross domain access for XHR 
under certain conditions by meeting the criteria in Security section of 
the JSONRequest proposal.


e.g. Don't send cookies, usernames, passwords, etc., prevent access to 
detailed error messages from other domains, help prevent DoS attacks to 
other domains using random delays between requests and address any other 
security concerns raised.


That way, if the conditions are met by both the script and server, the 
UA could allow access to the response, otherwise treat it as an XSS 
attack of some sort and deny it.


--
Lachlan Hunt
http://lachy.id.au/

Re: [whatwg] JSONRequest

[Gervase Markham]

Douglas Crockford wrote:
> The JSONRequest does only one thing:


Are you planning to take the excellent advice from  to
change the name? The name XmlHttpRequest sucks because it doesn't
necessarily return XML, and it doesn't have to be over HTTP. Let's not
tie the name of a new thing solely to the way we use it at the moment.

Why not just call it "Request", and have an API to set the Accept:
header, so people can set it to "application/json"? You could even make
that the default.

Gerv

Re: [whatwg] JSONRequest

[Martin Atkins]

Douglas Crockford wrote:
> I am proposing a new mechanism for doing data transport in Ajax/Comet
> applications. It is called JSONRequest. It is a minimal communications
> facility that can be exempted from the Same Origin Policy.
> 
> You can read about it here: http://json.org/JSONRequest.html

This proposal seems to have a similar purpose to my (much less complete
and detailed) proposal here:



The main differences that I see are:
* My proposal deals in interfaces rather than in data. It's possible to
implement a data source completely client-side, or (since the
instantiated object runs in the context of the remote site) provide a
restricted wrapper around XMLHttpRequest on the remote site.
* My proposal primarily lives within the client, while yours is to do
with clients talking to servers.

The thinking behind my propsal was based on the practice of "data
hiding" in OO languages; rather than exposing the data directly, just
expose an interface to the data. You can then change how it all works
later as long as the interface remains consistant.

One thing my proposal is lacking is a way to limit/alter responses based
on the caller. However, I think this could be achieved by adding an
object to the global scope of the remote script that contains
information about the caller such as hostname. This would be provided by
the UA and so is presumably trusted. (as much as the user trusts his UA.)

I'm aware that my proposal may also have some troubles when used under
other languages such as VBScript. It really needs a more
XMLHttpRequest-like API with event-based callbacks in order to be
portable. All that stuff can be figured out; I'm just throwing the idea
out there for now.

Re: [whatwg] JSONRequest

[Douglas Crockford]

> Or indeed wrote your script before this JSONRequest was invented.

I think I see where you are confused. A pre-JSONRequest JSON application will be 
using GET, or POST with a conventional POST body. JSONRequest cannot generate a 
GET, so those interfaces are safe, and it cannot generate a conventional POST 
body, so those applications are safe, too.


If an application is so badly implemented that it accepts dangerous POSTs (we 
already determined that JSONRequest is safer than form.submit in this regard) 
and does no validation of the POST data before issuing a JSON response, there is 
the concern that JSON data can be sent to the browser. This is a thing that 
JSONRequest can do that form.submit cannot.


So, is this a problem? No. First, JSONRequest will reject the response and not 
return to the script because the Content-Type is not application/json. 
application/json is only now being registered as MIME media type. Legacy 
applications should not have been using it.


If the legacy application was misusing application/json in a speculative way, 
the data might still be delivered. However, it will still be blocked if any of 
the pre-JSON conventions are used:


   Using a character encoding other than ASCII or UTF-8.

   No quotes on keys.

   Single quotes on keys.

   Single quotes on string literals.

   \x sequences.

   Unusual values such as undefined or NaN.

   Expressions or functions.

So, to repeat, JSON introduces no new security vulnerabilities for the legacy 
JavaScript data formats of six years ago. The dangers of POST are already 
existent. In that respect JSONRequest is strictly an improvement. The formats of 
the POST bodies are not compatible. The Content-Type is not compatible.


I would very much like to see the details of a specific attack in which a legacy 
application which depends solely on firewall locality for its security is 
compromised by JSONRequest. I believe that the string of errors would have to be 
so long as to be completely implausible.

Re: [whatwg] JSONRequest

[Jim Ley]

> My intention with JSONRequest is to make it minimal because being minimal will
> make it easier to understand and easier to implement correctly.

Making caching behave completely differently for
http://example.org/json.rjs in two different situations is not easy to
understand.

Making caching behave differently for requests made via a different
call are not easier to implement.

Jim.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/19/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
>  > The mimetype you're defining, because it is new, pretty-much ensures
>  > no existing service behind an intranet could be affected.
>
>  > I could still envision one day developers setting-up JSON syndication
>  > services behind an intranet, not quite grokking the fact that their
>  > data is now accessible from outside of their intranet. Silly, i know
>  > but ...
>
> It is a concern. The only solution to that that I can see is education.

No, the solution is pretty clear, all cross domain activity is
designed to be OPT-IN, just like all other current methods, then
concious effort needs to be made to allow your data onto other peoples
sites.

> A con with JSONRequest is
> that if your are incompetent in determining your authentications, then data 
> may
> leak.

Or indeed wrote your script before this JSONRequest was invented.

Please remove your false and misleading "introduces no new security problems".

Jim.

Re: [whatwg] JSONRequest

[Chris Holland]

what did you think of forcing implementers of JSON http services to be
consumed by JSONRequests, to send an extra HTTP header called
X-Allow-Foreign-Hosts, per what we discussed in past threads with
caxhr to address similar issues. As a developer, there'd be no way
you'd set this extra header without understanding the consequences of
exposing the service?

On 3/18/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
>  > The mimetype you're defining, because it is new, pretty-much ensures
>  > no existing service behind an intranet could be affected.
>
>  > I could still envision one day developers setting-up JSON syndication
>  > services behind an intranet, not quite grokking the fact that their
>  > data is now accessible from outside of their intranet. Silly, i know
>  > but ...
>
> It is a concern. The only solution to that that I can see is education. When
> choosing a technology for a service, whether SOAP or REST or JSONRequest or
> whatever, you need to understand the pros and cons. A con with JSONRequest is
> that if your are incompetent in determining your authentications, then data 
> may
> leak. For that reason, some people might choose to not use JSONRequest, and I
> could support such a decision. But for people who want to use it (and that
> includes me), we must be prepared to design our systems correctly. I know this
> is a controversial position.
>
> http://www.JSON.org/JSONRequest.html
>


--
Chris Holland
http://chrisholland.blogspot.com/

Re: [whatwg] JSONRequest

[Douglas Crockford]

> Please explain your use cases for making no JSONRequest cacheable, it
> really is completely silly to me and an absolute deal breaker, I
> assume it's because working for yahoo you need not worry about such
> things as bandwidth and cost.

Caching is a deal with the devil, in which reliability is traded off for 
performance. For some applications, such as the delivery of static documents and 
images, it can be a pretty good bargain. As you move to the dynamic end of the 
spectrum, it becomes a very bad bargain.


I see JSONRequest as a device for delivering the most dynamic of data. In such 
applications, I see caching diminishing reliability, and with reliability goes 
security.


My intention with JSONRequest is to make it minimal because being minimal will 
make it easier to understand and easier to implement correctly.


It is not my intention to replace anything. All of the existing document 
delivery mechanisms continue to have a mission. JSONRequest's mission is to 
deliver dynamic data. Currently, there is no good mechanism for do that.


Your assumption about Yahoo is at best misinformed.

Re: [whatwg] JSONRequest

[Douglas Crockford]

> The mimetype you're defining, because it is new, pretty-much ensures
> no existing service behind an intranet could be affected.

> I could still envision one day developers setting-up JSON syndication
> services behind an intranet, not quite grokking the fact that their
> data is now accessible from outside of their intranet. Silly, i know
> but ...

It is a concern. The only solution to that that I can see is education. When 
choosing a technology for a service, whether SOAP or REST or JSONRequest or 
whatever, you need to understand the pros and cons. A con with JSONRequest is 
that if your are incompetent in determining your authentications, then data may 
leak. For that reason, some people might choose to not use JSONRequest, and I 
could support such a decision. But for people who want to use it (and that 
includes me), we must be prepared to design our systems correctly. I know this 
is a controversial position.


http://www.JSON.org/JSONRequest.html

Re: [whatwg] JSONRequest

[Chris Holland]

Douglas,

your proposal looks interesting. To address similar issues, I had
started defining a "ContextAgnosticXmlHttpRequest" (caxhr) (
http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
) a while back, but i'm very-much liking JSON to obtain data
structures from the server.

JSON would make the syndicated data readily consumable via scripting.
Not to mention lightweight payloads.

The mimetype you're defining, because it is new, pretty-much ensures
no existing service behind an intranet could be affected.

I could still envision one day developers setting-up JSON syndication
services behind an intranet, not quite grokking the fact that their
data is now accessible from outside of their intranet. Silly, i know
but ...

Perhaps the old "X-Allow-Foreign-Host" idea this list was throwing
around while discussing caxhr, might also be useful in a JSON request?
A developer would have to explicitly set this header for their data to
be readable by a JSONRequester ?

Your Domain HTTP header seems similar in principle to my stressing the
importance of the requester sending an accurate "Refer[r]er" header. I
could see use cases for leveraging document.domain and Refer[r]er in
instances where you want to restrict access to your service to
individual originating URIs, or to hosts or domains.

I could see myself using caxhr in instances where i want to embed
(X)HTML-esque content within my own document, from a 3rd-party source.
For example, eBay allows their affiliates to embed javascript in their
page to retrieve auctions that match certain keywords, directly from
ebay's site. The payload basically document.writes a bunch of HTML. It
works ... but is rather clumsy, because any latency from ebay's server
will cause *my page* to interrupt its rendering. Not to mention i'm
allowing a foreign script to run on my document [EMAIL PROTECTED] In those
instances, I wish i could have the end-user's browser retrieve a "blob
of HTML" from eBay, and cloneNode(true)-insert it at a specified
location my DOM. caxhr would work well in this instance.

There are other instances where I just want a lightweight way to get
data structures from the server, and JSONRequest sounds best suited
for this.


Eh Jim,
i don't work at yahoo, but have met developers from there, they're
pretty rabid about bandwidth saving, caching, and effective content
delivery, and whatnot, precisely because they're *that* big with high
traffic. I was told there's a semi-official  title of Chief Caching
Officer held by someone somewhere in some department. You'll find all
images served by their akamaized us.*.yimg.com have their Expires
header set to expire in like ... a while, their last-modified set to
"a long time ago", which more or less indicates to me they at least
care about caching :) :

chris% telnet us.i1.yimg.com 80
Trying 72.246.50.14...
Connected to a943.yimg.com.georedirector.akadns.net.
Escape character is '^]'.
GET /us.yimg.com/i/us/my/b/myma_5l.gif HTTP/1.1
Host: us.i1.yimg.com

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 1340
Last-Modified: Fri, 15 Apr 1994 00:00:00 GMT
X-N: S
Date: Sat, 18 Mar 2006 01:43:29 GMT
Connection: keep-alive
Expires: Thu, 15 Apr 2010 20:00:00 GMT

On 3/17/06, Jim Ley <[EMAIL PROTECTED]> wrote:
> On 3/17/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
> > > The cache rules are unworkable, please remove these and use standard
> > > HTTP methods for suggesting the cacheability of a resource, forcing
> > > them to be uncacheable is unworkable w.r.t. to proxy caches and
> > > extremely unwelcome within the browser.
> >
> >   Applications must not cache responses to a POST request because the
> >   application has no way of knowing that the server would return an
> >   equivalent response on some future request.
>
> Of course the application can know that, that's what HTTP cache
> control headers are for, the cacheability of a resource is easy to
> advertise, and all browsers should know it.
>
> Please explain your use cases for making no JSONRequest cacheable, it
> really is completely silly to me and an absolute deal breaker, I
> assume it's because working for yahoo you need not worry about such
> things as bandwidth and cost.
>
> Jim.
>


--
Chris Holland
http://chrisholland.blogspot.com/

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/17/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
> > The cache rules are unworkable, please remove these and use standard
> > HTTP methods for suggesting the cacheability of a resource, forcing
> > them to be uncacheable is unworkable w.r.t. to proxy caches and
> > extremely unwelcome within the browser.
>
>   Applications must not cache responses to a POST request because the
>   application has no way of knowing that the server would return an
>   equivalent response on some future request.

Of course the application can know that, that's what HTTP cache
control headers are for, the cacheability of a resource is easy to
advertise, and all browsers should know it.

Please explain your use cases for making no JSONRequest cacheable, it
really is completely silly to me and an absolute deal breaker, I
assume it's because working for yahoo you need not worry about such
things as bandwidth and cost.

Jim.

Re: [whatwg] JSONRequest

[Douglas Crockford]

> The cache rules are unworkable, please remove these and use standard
> HTTP methods for suggesting the cacheability of a resource, forcing
> them to be uncacheable is unworkable w.r.t. to proxy caches and
> extremely unwelcome within the browser.

   Applications must not cache responses to a POST request because the
   application has no way of knowing that the server would return an
   equivalent response on some future request.

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/17/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > Please can you provide more information on how raw JSON is available
> > from script elements?
>
> Apologies; it was the Array constructor, and I was slightly wrong in the
> details. Here is the exploit:
> http://www.webappsec.org/lists/websecurity/archive/2006-01/msg00087.html

Yeah, only applies to Array, and I'm of the belief this is a Mozilla
security flaw anyway, hopefully it'll be fixed soon.

Thanks for including the URL in the thread too, illustrates exactly
why there are security concerns introduced with this JSONRequest.

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Gervase Markham]

Jim Ley wrote:
> I can't reproduce this, in IE and Opera, there's no effect whatsover
> playing with Object constructors, in Mozilla there is however it is
> not called unless you have an expression:
> 
> {chicken:true} // doesn't call it.
> donkey={chicken:true} // does call it.
> 
> Please can you provide more information on how raw JSON is available
> from script elements?

Apologies; it was the Array constructor, and I was slightly wrong in the
details. Here is the exploit:
http://www.webappsec.org/lists/websecurity/archive/2006-01/msg00087.html

Gerv

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/16/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Hallvord R M Steen wrote:
> > You are right, if no variables are created one can't see the data by
> > loading it in a  SCRIPT tag. Are you aware of intranets/CMSes that use
> > this as a security mechanism?
>
> That's not actually right. I'm pretty sure this came across a public
> security list, so...
>
> You can override the constructor on the prototype of the Object object
> and get access to JSON objects before the JavaScript engine throws them
> away when it realises they don't get assigned to a variable.
>
> Or something like that, anyway. I can't remember exactly how it worked.
> But I'm pretty sure that it's true that you can get JSON data if it's
> not protected.

I can't reproduce this, in IE and Opera, there's no effect whatsover
playing with Object constructors, in Mozilla there is however it is
not called unless you have an expression:

{chicken:true} // doesn't call it.
donkey={chicken:true} // does call it.

Please can you provide more information on how raw JSON is available
from script elements?

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Gervase Markham]

Hallvord R M Steen wrote:
> You are right, if no variables are created one can't see the data by
> loading it in a  SCRIPT tag. Are you aware of intranets/CMSes that use
> this as a security mechanism?

That's not actually right. I'm pretty sure this came across a public
security list, so...

You can override the constructor on the prototype of the Object object
and get access to JSON objects before the JavaScript engine throws them
away when it realises they don't get assigned to a variable.

Or something like that, anyway. I can't remember exactly how it worked.
But I'm pretty sure that it's true that you can get JSON data if it's
not protected.

Gerv

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/16/06, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> > > If you today embed data on an
> > > intranet in JavaScript I can create a page that loads that script in a
> > > SCRIPT tag and steal the data.
> >
> > Could you please describe how exactly?  the contents of remote script
> > elements are not typically available (and if they are it's a large
> > security hole today) unless valid javascript objects are produced to
> > be queried, that is not the case with bare JSON.
>
> You are right, if no variables are created one can't see the data by
> loading it in a  SCRIPT tag. Are you aware of intranets/CMSes that use
> this as a security mechanism?

Yes, I've shipped systems, and seen many others where the only
protection on the internal side is IP based, and use JSON data
retrieved by XHR and new Function'd into JS objects.  It's quite
common in fact.

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Hallvord R M Steen]

> > If you today embed data on an
> > intranet in JavaScript I can create a page that loads that script in a
> > SCRIPT tag and steal the data.
>
> Could you please describe how exactly?  the contents of remote script
> elements are not typically available (and if they are it's a large
> security hole today) unless valid javascript objects are produced to
> be queried, that is not the case with bare JSON.

You are right, if no variables are created one can't see the data by
loading it in a  SCRIPT tag. Are you aware of intranets/CMSes that use
this as a security mechanism?

--
Hallvord R. M. Steen

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/16/06, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> On 3/11/06, Jim Ley <[EMAIL PROTECTED]> wrote:
>
> > Accessing JSON resources on a local intranet which are
> > secured by nothing more than the requesting IP address.
>
> While this is a valid concern I think the conclusion "no *new*
> security vulnerabilities" is correct. If you today embed data on an
> intranet in JavaScript I can create a page that loads that script in a
> SCRIPT tag and steal the data.

Could you please describe how exactly?  the contents of remote script
elements are not typically available (and if they are it's a large
security hole today) unless valid javascript objects are produced to
be queried, that is not the case with bare JSON.

Jim.

Re: [whatwg] JSONRequest

[Hallvord R M Steen]

On 3/11/06, Jim Ley <[EMAIL PROTECTED]> wrote:

> Accessing JSON resources on a local intranet which are
> secured by nothing more than the requesting IP address.

While this is a valid concern I think the conclusion "no *new*
security vulnerabilities" is correct. If you today embed data on an
intranet in JavaScript I can create a page that loads that script in a
SCRIPT tag and steal the data.

Of course if this is implemented in UAs, it will encourage intranets
to publish JSONRequest services, so the situation may well get worse.

> The "not ok" needs to be refined to deal with proxy caches that may
> return other codes, e.g. 304 or 206.

> The cache rules are unworkable, please remove these and use standard
> HTTP methods for suggesting the cacheability of a resource, forcing
> them to be uncacheable is unworkable w.r.t. to proxy caches and
> extremely unwelcome within the browser.

You missed the fact that every request in this proposal seems to be a
POST request. No UA or proxy should cache POST anyway.
--
Hallvord R. M. Steen

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/13/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
> > " It provides this highly valuable service while introducing no new
> > security vulnerabilities. "
>
> > is false, please remove it to avoid any confusion.
>
> It would be very helpful if you could list the situations that
>you have determined are lacking.

I did in the paragraph after the part you quoted.

Jim.

Re: [whatwg] JSONRequest

[Gervase Markham]

Darin Fisher wrote:
> Keep in mind that there is also the problem that the POST request may
> have undesirable side-effects.  The web app probably needs a request
> header from the browser to tell it what domain is sending it data.  The
> Referer header is not sufficient since the browser will not send a HTTPS
> referrer-URI over plaintext.

And Referer, of course, is optional. And having something which is
compulsory might raise privacy issues.

> We need to restrict READs as well as WRITEs when it comes to XSS ;-)

Good point; I'd forgotten that.

Gerv

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/13/06, Darin Fisher <[EMAIL PROTECTED]> wrote:
> Moreover, if HTTP auth and cookies are not supported, then how does
> someone restrict access to their JSON service?  For example, it is
> common practice to use Kerberos to implement HTTP auth on intranets.

If you know you might be susceptible to the intranet attack, then all
you need to do is use SSL and have the  security within the JSON
string, of course doing this opens you up to seperate problems, and
it's far from easy.

>  I don't think this is a new idea as
> several specifications have been attempted along these lines.  Mozilla
> even implements one of them for its SOAP and WSDL implementation.

Yep, whilst I'm not overly happy with the approach, it's certainly
better than the let's hope people don't know our urls of the above
proposal.

Cheers,

Jim.

Re: [whatwg] JSONRequest

[Darin Fisher]

Douglas Crockford wrote:

I am proposing a new mechanism for doing data transport in Ajax/Comet
applications. It is called JSONRequest. It is a minimal communications
facility that can be exempted from the Same Origin Policy.

You can read about it here: http://json.org/JSONRequest.html


This looks like an interesting proposal.  Some comments:

I'm not sure how JSONRequest solves (or even avoids) the problem of 
XSS.  For example, suppose some intranet deploys a JSON service.  What 
is to prevent an employee's browser from being used to gain access to 
that JSON service?  All the attacker (a.k.a. disgruntled employee) needs 
to do is know the URL of the JSON service and then trick employees to 
visit an external page under the attackers control.


Moreover, if HTTP auth and cookies are not supported, then how does 
someone restrict access to their JSON service?  For example, it is 
common practice to use Kerberos to implement HTTP auth on intranets.


Backing up a second, I think what we need is a way to grant websites the 
ability to control who may access their resources.  It'd be ideal if the 
browser had a way to ask the server for the list of hosts (or domains) 
that are permitted to access it.  I don't think this is a new idea as 
several specifications have been attempted along these lines.  Mozilla 
even implements one of them for its SOAP and WSDL implementation.


-Darin

Re: [whatwg] JSONRequest

[Douglas Crockford]

>> I am proposing a new mechanism for doing data transport in Ajax/Comet
>> applications. It is called JSONRequest. It is a minimal communications
>> facility that can be exempted from the Same Origin Policy.
>>
>> You can read about it here: http://json.org/JSONRequest.html

> Unfortunately your security analysis is lacking some situations,
> Indeed the statement

> " It provides this highly valuable service while introducing no new
> security vulnerabilities. "

> is false, please remove it to avoid any confusion.

It would be very helpful if you could list the situations that you have 
determined are lacking.

Re: [whatwg] JSONRequest

[Gervase Markham]

Darin Fisher wrote:
> Backing up a second, I think what we need is a way to grant websites the
> ability to control who may access their resources.  It'd be ideal if the
> browser had a way to ask the server for the list of hosts (or domains)
> that are permitted to access it.  I don't think this is a new idea as
> several specifications have been attempted along these lines.  Mozilla
> even implements one of them for its SOAP and WSDL implementation.

My idea for that (bit of a one-track mind, me) was a Use-Domain: HTTP
header. The JSON data would be served with "Use-Domain:
www.mydomain.com", and the browser would refuse to give any page not
from that domain access to the data.

You could also use it to prevent image bandwidth stealing.

Gerv

Re: [whatwg] JSONRequest

[Darin Fisher]

Gervase Markham wrote:

Darin Fisher wrote:
  

Backing up a second, I think what we need is a way to grant websites the
ability to control who may access their resources.  It'd be ideal if the
browser had a way to ask the server for the list of hosts (or domains)
that are permitted to access it.  I don't think this is a new idea as
several specifications have been attempted along these lines.  Mozilla
even implements one of them for its SOAP and WSDL implementation.



My idea for that (bit of a one-track mind, me) was a Use-Domain: HTTP
header. The JSON data would be served with "Use-Domain:
www.mydomain.com", and the browser would refuse to give any page not
from that domain access to the data.

You could also use it to prevent image bandwidth stealing.

Gerv
  


Keep in mind that there is also the problem that the POST request may 
have undesirable side-effects.  The web app probably needs a request 
header from the browser to tell it what domain is sending it data.  The 
Referer header is not sufficient since the browser will not send a HTTPS 
referrer-URI over plaintext.


We need to restrict READs as well as WRITEs when it comes to XSS ;-)

-Darin

Re: [whatwg] JSONRequest

[Alexey Feldgendler]

On Sun, 12 Mar 2006 04:11:28 +0600, Douglas Crockford  
<[EMAIL PROTECTED]> wrote:



I am proposing a new mechanism for doing data transport in Ajax/Comet
applications. It is called JSONRequest. It is a minimal communications
facility that can be exempted from the Same Origin Policy.

You can read about it here: http://json.org/JSONRequest.html


Please correct me if I have misunderstood, but I think that JSONRequest  
can be implemented in today's user agents as a JavaScript library basing  
on XMLHttpRequest.



-- Opera M2 9.0 TP2 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station at SW-Soft, Inc. [ICQ: 115226275]  
<[EMAIL PROTECTED]>

Re: [whatwg] JSONRequest

[Lachlan Hunt]

Douglas Crockford wrote:

I am proposing a new mechanism for doing data transport in Ajax/Comet
applications. It is called JSONRequest. It is a minimal communications
facility that can be exempted from the Same Origin Policy.

You can read about it here: http://json.org/JSONRequest.html


It's an interesting concept, I just have a few issues with it.

You neglected to define the character encoding to be used for the POST 
request sent by the browser.  You mention that it can send 250,000 
Unicode characters and that the response must be UTF-8, does this mean 
that the request must also be UTF-8?


I agree that it's a good idea to ignore cookies and that is a major 
security feature of this proposal, but would it not be possible to 
introduce that same feature into XMLHttpRequest?  Wouldn't it be better 
to address the security concerns with XMLHttpRequest in order to allow 
it limited access to any domain, than to introduce a new function?


I don't like the name "JSONRequest".  It was a mistake to include "XML" 
and "Http" in XMLHttpRequest, since the name unnecessarily describes the 
format and the protocol used by the function, although we are stuck with 
the name for backwards compatibility reasons.  In reality XMLHttpRequest 
is used for many different formats and the protocol is defined by the URI.


Although, as it currently stands, this proposal is limited to JSON, what 
exactly makes JSON a more secure format than XML or anything else; and, 
therefore, why must it be restricted to that format and thus included in 
the function name?


--
Lachlan Hunt
http://lachy.id.au/

Re: [whatwg] JSONRequest

[Jim Ley]

On 3/11/06, Douglas Crockford <[EMAIL PROTECTED]> wrote:
> I am proposing a new mechanism for doing data transport in Ajax/Comet
> applications. It is called JSONRequest. It is a minimal communications
> facility that can be exempted from the Same Origin Policy.
>
> You can read about it here: http://json.org/JSONRequest.html

Unfortunately your security analysis is lacking some situations,
Indeed the statement

" It provides this highly valuable service while introducing no new
security vulnerabilities. "

is false, please remove it to avoid any confusion.

Accessing JSON resources on a local intranet which are secured by
nothing more than the requesting IP address.  Indeed you actually skip
over this pretending that there would only be legacy
data/documents/scripts available in such a situation, despite the
number of people who've been shipping such products for 6 years or
more.

In other non security areas, you don't define how the delay product is
reset - is it per window, per host, per instance?  That needs
defining.

The "not ok" needs to be refined to deal with proxy caches that may
return other codes, e.g. 304 or 206.

The Duplex claim is misleading, and you should specifically mention
that if you do use 2 connections, no other content would be
downloadable from the site in a conforming HTTP 1.1 implementation.

The cache rules are unworkable, please remove these and use standard
HTTP methods for suggesting the cacheability of a resource, forcing
them to be uncacheable is unworkable w.r.t. to proxy caches and
extremely unwelcome within the browser.

Most importantly is to actually make it safe to use.

cheers,

Jim.