[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
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(). Because eval() is
evil h
10 matches
Mail list logo
