calling a function indirectly
jimd at vega.starshine.org
Mon Feb 25 08:09:44 CET 2002
In article <Vg%c8.4179$XT1.116344 at news1.east.cox.net>, Jeff Hinrichs wrote:
>for some info. Unless you have total control over what is being eval'd you
>are at risk.
>"Rajarshi Guha" <rxg218 at psu.edu> wrote in message
>news:a50udo$1dou at r02n01.cac.psu.edu...
>> On Wednesday 20 February 2002 01:24 in comp.lang.python Jeff Hinrichs
>>> If you wanted to get away from the dangerous eval, you could put your
>>> functions inside of a class and then,
>> Why is eval dangerous?
In THIS case it's not a problem. The string being eval'd is a
reference to be bit of code he wrote himself. However, if it was
being combined with a string from any untrusted source (esp.
user input, or data from a network connection or subprocess, even
filenames from an os.listdir() or some such, IF that was the case
then eval could be quite dangerous because it could be executing
arbitrary Python code (which could, in turn, execute arbitrary bits
of system code).
Regulars on this newsgroup display a knee jerk reaction to eval().
This could be construed as a healthy wariness in some cases. One
should always ask:
where did this data come from?
how did I validate it?
what are the risks of using/trusting this data in this way?
... but those questions should not be limited merely to strings
that we might be passing to eval, they must be constantly applied
throughout our coding if we intend to write robust code which
works across security contexts (handles any sort of foreign data)
and which is capable of enforcing the most basic implicit security
policy (don't get subverted to executing arbitrary code or tricked
into removing, or corrupting our data).
More information about the Python-list