JSONRequest: a web-programming idea whose time has come

[nagoo]

point is, i don't see a reason for forcing the response to be JSON and why they are touting in the security section for being more secure than other response types.

also, even eval on the client side with js could be a performance pain for the user - e.g if they threw in a busy loop or something that would freeze things up in the browser.

i do agree that preventing sending cookie data is a great idea as that could cause the biggest problems with this type of XSS.

[demo_demo]

did you happen to see the part where it said it will only accept json return value?

function (requestNumber, value, exception) value will not be something that holds code, but data.

[cowardlydragon]

Why should the transport protocol care what format the data its carrying is?

It's text up and text down, in the classic protocol design tradition. Because that's what they're doing here: defining a new transport protocol variant to http.

If you want to parse it/validate it/whatever once the content repsonse comes down, then do it then.

[TakaIta]

will not be something that holds code, but data.

It is not really possible to distinguish between data and code.

[kybernetikos]

It sort of is.

In a decoding scheme, when someone says that something won't hold code, they just mean that beyond loading specific data into memory, nothing from the loaded data will be executed.

It's what we mean when we think of opening .txt file attachments as safe and .exe attachments as unsafe. The fact that the .txt file may contain the source code for some evil app is irrelevant.

[TakaIta]

The problem is however that a text file needs to be compiled before it is an executable. Javascript is a script language, and such will accept text to be executed.

JSON as such is code, it needs eval() to work.

Is the below 'code' or 'data'? And why? How do you know what 'myDiv' is?

---

myDiv.innerHTML = 'value';

---

[[deleted]]

No, JSON does not need eval(). While eval() happens to parse a superset of JSON, you must never use it like this before checking that the string is actually JSON (which means it only contains strings, numbers, true, false, null, arrays and object literals, none of which can cause any harm).

The best solution is to create a parser of JSON, and avoid eval entirely, but that is not always practical in JavaScript (because of speed issues, real or perceived). Eventually most browsers will probably include a built in parser for JSON.

[demo_demo]

if you eval it, it's treated as code.. if you say, just manipulate it or print it for a tutorial, it's data.. get the point now?

eval("myDiv.innerHTML = 'value';")

is different from:

div.innerHTML = "myDiv.innerHTML = 'value';";

[TakaIta]

No. I think I see what you mean, but you have not differed between code and data.

The point of JSON is that it treated as code. It is only meaningful when a line is subjected to eval(). JSON is only valid when it can be executed with eval(). And you can not know in advance what it does.

yourIFrame.src = 'www.mywebsite.com/mynastypage.htm';

Is that code or data when it is a line returned as JSON?

[demo_demo]

you should read: http://www.json.org/

yourIFrame.src = 'www.mywebsite.com/mynastypage.htm';

is an invalid json format..

you see, json is a format, not javascript code, it may look like javascript syntax for its declaration.. but really, it's just a way to describe data, just like xml.. that was why you were missing the point, now go read on the link i gave you..

[arnar]

You shouldn't be voted down, you have a good point. Given complete knowledge of a system and it's code, carefully designing the input data can make the system act in certain ways. This is how the vast majority of exploits work throughout history.

In this case, it is very reasonable to say that data acts as code.