JSON and the cyclical data structures...

[VK]

Re: JSON and the cyclical data structures...

Luke Matuszewski wrote:[color=blue]
> Can you provide your jsFireReader ? I am interested ;-)[/color]

<snip> !! :-)

But do not blaim on me: I decided to wait just a bit with the Gecko
part because FF 1.5 is due to be realeased within days. And "release
candidtates" (3rd now) have their security and XPConnect details
roaming like a marchandising boat in the boot.

So I want to see the final decisions first. And I do not want to post
IE-only part: this is comp.lang.javas cript here, not some
microsoft.publi c.scripting.jsc ript

[David Wahler]

Re: JSON and the cyclical data structures...

Luke Matuszewski wrote:[color=blue]
> David Wahler napisal(a):[color=green]
> > 2) You can safely parse JSON without having to worry about security
> > vulnerabilities . eval() can only be used on data from trusted sources,
> > because anyone who has access to it can use it to get around the same
> > origin restriction.[/color]
>
> Can you point how to get around the same origin restriction ? (Can i
> use XmlHttpRequest open() URL parameter which is in different origin
> (domain) than my script/document when i do it via eval( ) ? )[/color]

Sorry, I didn't phrase that very well. eval() doesn't break
cross-domain security by itself; however, it increases the likelihood
of cross-site scripting (XSS) attacks. Let me use a quick example:
suppose you have a fancy, AJAXified database which stores records in
JSON format, like so:

// (this is just an example)
var rowString = '{
"id": "12345",
"foo": "bar"
}';
var row= eval('('+rowStr ing+')');
document.write( row.id);

If you use eval() to parse the rows, then anyone who can submit data
can inject code that runs in the context of your site. Since they're
running their code on your site, they're getting around the same origin
restriction, and they can then do all kinds of evil things:

var rowString = '(function() {
var req = new XMLHTTPRequest( );
req.open("POST" , "/messageboard/changepassword. cgi", false);
req.send("newpa ssword=haxxored ");
return {"id": "I just changed your password!"};
})()';
var row= eval('('+rowStr ing+')');
document.write( row.id);

This means that anyone who views that database row gets their password
changed, and their account compromised. If you don't think this type of
attack is plausible, MySpace--which had taken extensive security
precautions--had their security blown out of the water by a JavaScript
worm just over a month ago:

http://blog.outer-court.com/archive/2005-10-13-n73.html

If you don't want this to happen, you have (off the top of my head)
three options:
1) Use a real JSON parser on the client.
2) Use a real JSON parser on the server, that carefully verifies all
data that gets submitted.
3) Don't use JSON for client-to-server communications, but some other
protocol; this largely defeats the purpose of using JSON in the first
place, which is simplicity.
[color=blue][color=green]
> > I can imagine situations in which you would need eval() to dynamically
> > load code from a server, but it's not a great idea for static data,
> > especially since the JSON library is already freely available.[/color]
>
> And here you don't understand the concept. JSON site states that when i
> have stringified JSON data structure a can use eval to get it back as a
> reference in JavaScript so to use it as object/array/string etc....[/color]

I do understand the concept, but maybe I wasn't making myself clear (if
that is the case, I apologize). You can parse JSON with eval(), but
"can" is not the same as "should". The JSON site also states: "When
security is a concern it is better to use a JSON parser. A JSON parser
will only recognize JSON text and so is much safer."
[color=blue]
> (i can also use JSON.parse - but it is slower then eval - and i don't have
> to use parse if i know that received data from XmlHttpRequest object is
> JSON stringified data structure).[/color]

By all means, go ahead and use eval(), but bear in mind that you're
trusting your security to the integrity of that received data. If
you're confident that your data is trustworthy, that's your decision to
make.

-- David

[Luke Matuszewski]

Re: JSON and the cyclical data structures...


David Wahler napisal(a):[color=blue]
> This means that anyone who views that database row gets their password
> changed, and their account compromised. If you don't think this type of
> attack is plausible, MySpace--which had taken extensive security
> precautions--had their security blown out of the water by a JavaScript
> worm just over a month ago:
> http://blog.outer-court.com/archive/2005-10-13-n73.html[/color]
Well yes, because the XmlHttpRequest makes requests like real user -
so anyone that have access to web page source code can inject any
script that emulates user interaction...

- and after all the best solution is to disable scripting at all ;(
[color=blue]
> If you don't want this to happen, you have (off the top of my head)
> three options:
> 1) Use a real JSON parser on the client.[/color]

This will insure me that response data on client side is verified JSON
data (no direct code in it)
[color=blue]
> 2) Use a real JSON parser on the server, that carefully verifies all
> data that gets submitted.[/color]

This will insure me that request data send by client side(submitted) to
server side is verified JSON data - no functions (Perl has also eval
which can eval even some worst things that all of as could imagine).
[color=blue]
> 3) Don't use JSON for client-to-server communications, but some other
> protocol; this largely defeats the purpose of using JSON in the first
> place, which is simplicity.[/color]

Client-to-server communications was always a problem - because of
actions that server can take on client http request.
[color=blue][color=green][color=darkred]
> > > I can imagine situations in which you would need eval() to dynamically
> > > load code from a server, but it's not a great idea for static data,
> > > especially since the JSON library is already freely available.[/color]
> >
> > And here you don't understand the concept. JSON site states that when i
> > have stringified JSON data structure a can use eval to get it back as a
> > reference in JavaScript so to use it as object/array/string etc....[/color]
>
> I do understand the concept, but maybe I wasn't making myself clear (if
> that is the case, I apologize). You can parse JSON with eval(), but
> "can" is not the same as "should". The JSON site also states: "When
> security is a concern it is better to use a JSON parser. A JSON parser
> will only recognize JSON text and so is much safer."[/color]

Yep - but there is no eval in Java which will 'execute' recieved data
(or maybe there is but it must be used with advanced class loading
mechanism or methods that runs scripts on the command shell).
[color=blue][color=green]
> > (i can also use JSON.parse - but it is slower then eval - and i don't have
> > to use parse if i know that received data from XmlHttpRequest object is
> > JSON stringified data structure).[/color]
>
> By all means, go ahead and use eval(), but bear in mind that you're
> trusting your security to the integrity of that received data. If
> you're confident that your data is trustworthy, that's your decision to
> make.
>[/color]

Thanks for arumentation and answer.

In security the only one thing will never change:
- the security is always as secure as the weakest element of the
security model (which in common are humans).

[Douglas Crockford]

Re: JSON and the cyclical data structures...

> This means that anyone who views that database row gets their password[color=blue]
> changed, and their account compromised. If you don't think this type of
> attack is plausible, MySpace--which had taken extensive security
> precautions--had their security blown out of the water by a JavaScript
> worm just over a month ago:
> http://blog.outer-court.com/archive/2005-10-13-n73.html
>
> If you don't want this to happen, you have (off the top of my head)
> three options:
> 1) Use a real JSON parser on the client.
> 2) Use a real JSON parser on the server, that carefully verifies all
> data that gets submitted.
> 3) Don't use JSON for client-to-server communications, but some other
> protocol; this largely defeats the purpose of using JSON in the first
> place, which is simplicity.[/color]

4) Use a real JSON encoder on the server.

A Samy attack is only possible with JSON if there are two blunders in
the server implementation:

A) Don't properly validate data from the client.
B) Don't properly encode the JSON text.

If you avoid either one of those, JSON is safe. You should always
validate and encode properly. For example, taking a string from the
database and simply concatenating quotes to it does not properly
encode a JSON string. It is necessary to make sure that quotes within
it are properly escaped.

Had MySpace used JSON for its messaging, we would not be talking about
Samy today.

http://www.JSON.org

[VK]

Re: JSON and the cyclical data structures...


David Wahler wrote:[color=blue]
> MySpace--which had taken extensive security[/color]

I'm sorry but the case description shows that MySpace had zero security
and this is why the case might happened.
* You cannot allow any real tags / style attributes in a public forum.
Only a preset set of pseudo-tags. *
This baby lore is being taught in sysadmin kindergardens.

But yes, you always have to be careful with a food you cannot know
anything about until you eat it - and eval() is such food.

[Luke Matuszewski]

Re: JSON and the cyclical data structures...


Douglas Crockford napisal(a):[color=blue][color=green]
> > If you don't want this to happen, you have (off the top of my head)
> > three options:
> > 1) Use a real JSON parser on the client.
> > 2) Use a real JSON parser on the server, that carefully verifies all
> > data that gets submitted.
> > 3) Don't use JSON for client-to-server communications, but some other
> > protocol; this largely defeats the purpose of using JSON in the first
> > place, which is simplicity.[/color]
>
> 4) Use a real JSON encoder on the server.
>
> A Samy attack is only possible with JSON if there are two blunders in
> the server implementation:
>
> A) Don't properly validate data from the client.
> B) Don't properly encode the JSON text.
>
> If you avoid either one of those, JSON is safe. You should always
> validate and encode properly. For example, taking a string from the
> database and simply concatenating quotes to it does not properly
> encode a JSON string. It is necessary to make sure that quotes within
> it are properly escaped.
>[/color]

JSON.parse is for that - to be sure that received data (both on
client-side or server-side) are JSON data and nothing more.

Using JSON on client-side is extremly easy with JavaScript (and with
Perl on server-side - since Perl has very similar structures) <- it is
the main argument for me to use JSON in HTTP response which will land
in XmlHttpRequest responseText property. Using XML would require to
build algorithm to traverse data/build object. So i asked myself what
for ? if i have JSON then there it is - on one hand !

Yes, using JSON parse every time when i receive data on responseText
would be nessesery to build code that will not break or even do
somthing that i would not want it to do (see all replies above).

Another thing which made me to use JSON is its Java Implementation - i
can build JSONObject in Java code and build structures around it so as
a final step i use toString() - to post string to the client (UA) to
land in responseText... .

And that two main reasons to use it - simplicity (XML need parsing and
require to use DOM methods to access its data - well or parse it
manually :))) ).

Best Regards.
Luke.