[Bese-devel] Re: read-from-client-string

Nathan Bird nathan at acceleration.net
Tue May 9 18:40:59 UTC 2006



>-----Original Message-----
>From: bese-devel-bounces at common-lisp.net [mailto:bese-devel-bounces at common-
>lisp.net] On Behalf Of Marco Baringer
>Sent: Tuesday, May 09, 2006 1:11 PM
>To: bese-devel at common-lisp.net
>Subject: [Bese-devel] Re: read-from-client-string
>
> [...]
>afaicr the only places ucw needs to use read-from-string are:
>
>1) the admin app. 'nuff said.
>
>2) parsing numbers. we really shouldn't be using the lisp reader for
>   this anyway, what we really want is just a floating point
>   parser. openmcl has ccl::parse-float, i'm sure other lisps have it
>   buryed somewhere. if not we could just cut 'n paste someone's
>   implementation into arnesi (though i'm loath to add more code we
>   have to maintain).

Yeah, that's pretty much the case, I had been using read in the forms number
parsing because that's how I saw someone else do it at some point. :-)

The aserve backend also has this in there a couple of times:
(read-from-string (format nil ":~A" header-name))
I take it this is just trying to get keyword symbols out of strings? Would a
better fix for that be using intern instead?

>> What about setting this up surrounding every request? Wrap a suitably
>> high-level handle-request function with a binding for *read-eval* to nil
>to
>> help prevent that class of vulnerability to begin with.
>
>personally it smells bad to me, i'd be happier if we didn't. [...]

Yeah, it does smell a bit, I'm just thinking if there are reads in there,
might be better to have that check on. That might just be false security
though.




More information about the bese-devel mailing list