4 ms·

It's actually trivial to make evaluation safe for JSON input as seen in the very short `parseJSON` implementation in jQuery: https://github.com/jquery/jquery/b

by Rauchg 14y ago

It's actually trivial to make evaluation safe for JSON input as seen in the very short `parseJSON` implementation in jQuery: https://github.com/jquery/jquery/blob/master/src/core.js#L523 https://github.com/jquery/jquery/blob/master/src/core.js#L52... Also, for the JSONP technique to work, it _has_ to be valid JavaScript so the escaping is necessary.

chimeracoder 14y ago
I don't know enough Javascript to give the analogous exploit myself, but that approach looks dangerously similar to some attempts I have seen at making Python's "eval" safe - attempts which, I might add, all fail to capture corner cases that any sufficiently determined or motivated attacker would eventually discover.
- fforw 14y ago
  First of all, if native JSON parsing exists, jQuery will use that. The validation code they use in case there is no native JSON implementation available is borrowed from Douglas Crockford's json2.js ( https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L448 https://github.com/douglascrockford/JSON-js/blob/master/json... ) which was the inspiration for the native JSON implementations and should really be correct by now, both in terms of correctness but also circumventing regexp weaknesses in some engines.
  - JulianMorrison 14y ago
    It's still the Wrong Way™. You want to parse JSON, you write a lexer that recognizes its symbols and a parser that consumes them and spits the JS equivalent. Otherwise you are playing an eternal game of whack-a-mole with the JS eval parser. No. Just no.
    - fforw 14y ago
      If you can find a case in which the validator fails, it's wrong. Otherwise, if it's looks like a JSON parser and works like a JSON parser, i.e. is indistinguishable from a "proper" parser, it makes no sense but satisfying OCD to rework it. Note that the code is now only a work-around for older browsers. Every modern browser supports native JSON parsing anyway.

by Rauchg 14y ago

chimeracoder 14y ago

I don't know enough Javascript to give the analogous exploit myself, but that approach looks dangerously similar to some attempts I have seen at making Python's "eval" safe - attempts which, I might add, all fail to capture corner cases that any sufficiently determined or motivated attacker would eventually discover.

fforw 14y ago
First of all, if native JSON parsing exists, jQuery will use that. The validation code they use in case there is no native JSON implementation available is borrowed from Douglas Crockford's json2.js ( https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L448 https://github.com/douglascrockford/JSON-js/blob/master/json... ) which was the inspiration for the native JSON implementations and should really be correct by now, both in terms of correctness but also circumventing regexp weaknesses in some engines.
- JulianMorrison 14y ago
  It's still the Wrong Way™. You want to parse JSON, you write a lexer that recognizes its symbols and a parser that consumes them and spits the JS equivalent. Otherwise you are playing an eternal game of whack-a-mole with the JS eval parser. No. Just no.
  - fforw 14y ago
    If you can find a case in which the validator fails, it's wrong. Otherwise, if it's looks like a JSON parser and works like a JSON parser, i.e. is indistinguishable from a "proper" parser, it makes no sense but satisfying OCD to rework it. Note that the code is now only a work-around for older browsers. Every modern browser supports native JSON parsing anyway.