|
This page contains all of the posts and discussion on MemeStreams referencing the following web page: X-JSON in Prototype. You can find discussions on MemeStreams as you surf the web, even if you aren't a MemeStreams member, using the Threads Bookmarklet.
|
X-JSON in Prototype by Acidus at 11:32 am EST, Dec 29, 2006 |
new Ajax.Request('?url=backend',{onSuccess:responseHandler}); var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));
eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face. Quoting from the great Douglas Crockford: However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted. 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:
|
|
RE: X-JSON in Prototype by Lost at 1:03 pm EST, Dec 29, 2006 |
Acidus wrote: new Ajax.Request('?url=backend',{onSuccess:responseHandler}); var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));
eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face. Quoting from the great Douglas Crockford: However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted. 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:
var jsonObject = eval('(' + jsonString + ')'); You mean like that? Ducks. I should be doing like prototype's evalJSON, instead, which does this: return eval(this.header('X-JSON')); } catch (e) {} ? |
|
| |
More on: X-JSON in Prototype by Acidus at 5:41 pm EST, Dec 29, 2006 |
Jello wrote: Acidus wrote: new Ajax.Request('?url=backend',{onSuccess:responseHandler}); var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));
eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face. Quoting from the great Douglas Crockford: However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted. 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:
var jsonObject = eval('(' + jsonString + ')'); You mean like that? Ducks.
As Crockford (the man who invented JSON) states, eval give access to the full JavaScript compiler. Using eval to parse JSON can be attacked 2 ways: 1- You have a mashup or data from other sources that you cannot trust. 2- Unvalidated user input is placed inside the object being returned by JSON. Consider receiving/processing a JSON object which is an Array of someone name. ["Alice", "Eve", "Bob"] Eve makes her name ""]; alert('xss');// Now what gets evaled is ["Alice", ""];alert('xss');//", "Bob"] Eve has achieved code execution! Once again something that an be solved if all user input is properly validated, included data from 3rd party sites. However, the big reason I made this most is that Prototype (and thus Script.aculo.us) has a built in feature, to always eval the contents of an HTTP header! I doubt most people using the framework know this exists, and short of modifying the framework, it doesn't appear that you can turn it off. At what point does a feature become a backdoor? |
|
| | |
RE: More on: X-JSON in Prototype by Lost at 9:56 pm EST, Dec 29, 2006 |
Acidus wrote: Jello wrote: Acidus wrote: new Ajax.Request('?url=backend',{onSuccess:responseHandler}); var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));
eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face. Quoting from the great Douglas Crockford: However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted. 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:
var jsonObject = eval('(' + jsonString + ')'); You mean like that? Ducks.
As Crockford (the man who invented JSON) states, eval give access to the full JavaScript compiler. Using eval to parse JSON can be attacked 2 ways: 1- You have a mashup or data from other sources that you cannot trust. 2- Unvalidated user input is placed inside the object being returned by JSON. Consider receiving/processing a JSON object which is an Array of someone name. ["Alice", "Eve", "Bob"] Eve makes her name ""]; alert('xss');// Now what gets evaled is ["Alice", ""];alert('xss');//", "Bob"] Eve has achieved code execution! Once again something that an be solved if all user input is properly validated, included data from 3rd party sites. However, the big reason I made this most is that Prototype (and thus Script.aculo.us) has a built in feature, to always eval the contents of an HTTP header! I doubt most people using the framework know this exists, and short of modifying the framework, it doesn't appear that you can turn it off. At what point does a feature become a backdoor?
I'm thinking about this as it pertains to my application... Everything is through user authentication via https, so there's not likely to be a man in the middle. And... the client can only mess up the presentation of our data. So, what can happen if code execution is actually achieved, and how would that happen? Just wondering if I need to fix my code. Sounds like not, since i trust the source of the JSON. Interesting, though. Do I still deserve a punch in the face? :) |
|
|
|