Or we could...not...evaluate random code potentially coming from hostile environments. That would also be cool and good.

And, yes, it's possible to have vulnerabilities in a JSON parser--but it is orders of magnitude easier to have them in an arbitrary language parser.

If you evaluate it in an environment where only the functions you choose are defined, the security risk is nil.

Validating a document is a complex, domain-dependant problem. It is far easier to create a secure Domain-Specific Language to handle this than to end up with an accidentally Turing complete abomination like XSLT: http://www.unidex.com/turing/utm.htm

>If you evaluate it in an environment where only the functions you choose are defined, the security risk is nil.

Oh. So all you have to do is write perfectly secure code and run it in a perfectly secure environment, and nothing bad can possibly happen.

Well shit, why didn't anyone else ever think of that?

> When I need to parse or validate S-expressions, I just write the functions (here message, to, from, timestamp, etc.) so that eval()ing the S-expressions either validates it or returns whatever data structure I need.

facepalm

As soon as you've decided to call an eval() function on potentially untrusted data, you've lost to an attacker.