eval does not throw exceptions (Quite the opposite.)
Would "An attacker could supply input that would genereate compile and run-time errors inside a string eval" be a more appropriate wording?
Given those strings, undef will be returned, which sounds perfectly acceptable.
This sounds reasonable, and I will retract the comment that hints that returning undef might be undesirable. The problem is that tachyon's function does not always return undef on bad input, on the contrary, it can return quite interresting stuff, as my example has shown. I must admit that my example is a bit contrieved, but the OP did not supply any code to analyze. It's an illustration of what can be done.
It should also return undef when validation fails, but it doesn't.
You're right.
While this function returning a number in 0..99 doesn't sound dangerous
It's not too dangerous, in the sense that it's not an exploit that could make your computer run arbitrary code. It's dangerous in the sense that an attacker could infuse into a computation data gathered from an important variable which he should not have access to. Whether this is dangerous for your particular program or setting, you be the judge. For me it's dangerous enough to be concerned.
After all, the user isn't providing the regexp
Take a look at the code in my first reply - it contains a lot of leaning toothpicks and IS valid input to be fed to eval according to tachyon's m!^[\-\+\d\./ \t]+$!.
My point was that an untrusted user should not be allowed to inject regexps in your runtime, as a matter of principle. Yes, the regexps are from a limited set, but still an infinite set. There might be bugs or corner cases. It's just conservative security practice.
In reply to Re^4: Arithmetic with fractions
by calin
in thread Arithmetic with fractions
by algonquin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |