[Jim Washington]
> I'm still working on yet another parser for JSON (http://json.org). It's
> called minjson, and it's tolerant on input, strict on output, and pretty
> fast. The only problem is, it uses eval(). It's important to sanitize the
> incoming untrusted code before sending it to eval().
Here's the pyparsing rendition - about 24 lines of code, and another 30
for testing.
For reference, here's the JSON "bnf":
object
{ members }
{}
members
string : value
members , string : value
array
[ elements ]
[]
elements
value
elements , value
value
string
On Mon, 22 Aug 2005 22:12:25 +0200, Fredrik Lundh wrote:
> however, running a tokenizer over the source string and rejecting any string
> that contains unknown tokens (i.e. anything that's not a literal, comma,
> colon,
> or square or curly bracket) before evaluation might be good enough.
>
> (y
> Another thing you can do is use the compile message and then only allow
> certain bytecodes. Of course this approach means you need to implement
> this in a major version-dependent fashion, but it saves you the work of
> mapping source code to python. Eventually there will be another form
> ava
Jim Washington wrote:
> 4. List comprehensions might be troublesome, though it's not clear to me
> how a DoS or exploit is possible with these.
see item 1.
> Or is eval() simply too evil?
yes.
however, running a tokenizer over the source string and rejecting any string
that contains unknown t
Diez B. Roggisch wrote:
>> Does anyone know of any other "gotchas" with eval() I have not found? Or
>> is eval() simply too evil?
>
>
> Yes - and from what I can see on the JSON-Page, it should be _way_
> easier to simply write a parser your own - that ensures that only you
> decide what pytho
> Does anyone know of any other "gotchas" with eval() I have not found? Or
> is eval() simply too evil?
Yes - and from what I can see on the JSON-Page, it should be _way_
easier to simply write a parser your own - that ensures that only you
decide what python code gets called.
Diez
_
--
http:
On Mon, 22 Aug 2005 13:55:45 GMT,
Jim Washington <[EMAIL PROTECTED]> wrote:
> I'm still working on yet another parser for JSON (http://json.org).
See http://python.ca/nas/log/200507/index.html#21_001 for another parser. I
don't know if it uses eval() or not, but would bet on "not" becau
Jim Washington wrote:
> I'm still working on yet another parser for JSON (http://json.org).
Hi, Jim.
> The only problem is, it uses eval(). It's important to sanitize the
> incoming untrusted code before sending it to eval().
> Does anyone know of any other "gotchas" with eval() I have not found
