Re: [Python-ideas] List Revolution
On Sep 10, 2011, at 2:22 PM, Matt Billenstein wrote:
agreed
And eval generally has high "code-smell" -- it can lead to code injection exploits.
Not in this example. So why not? Any code can introduce vulnerabilities if incorrect.
Not in this example. So why not?
Yes it did in this example. You introduced a vulnerability in your first attempt, and it was found by somebody else. eval makes accidental vulnerabilities way easier than they should be, even for people that are trying to be careful. Even your modified version had something that in some circumstances would be DoS-attackable because your verification still allowed for unintended operations. But yeah, if you can guarantee that there won't be any ill-effects from using eval, _of course_ it's OK. The problem is that these guarantees are too easy to get wrong, or to forget, or to misunderstand. Devin On Sat, Sep 10, 2011 at 3:27 PM, Massimo Di Pierro <massimo.dipierro@gmail.com> wrote:
First, the "vulnerability" was fixed. (*) Second, the parser could also have vulnerabilities. In fact I the vulnerability in the eval code was easy to find. How do you know there is no bug in the parser loop that I implemented that will cause some strings to go into an infinite loop?The explicit parser may still have a vulnerability, it is just more difficult to debug. Perhaps I put both there on purpose to see which one you could find. Massimo (*) I put it in quote because the possible values in name are already limited by the fact that name was an attribute (can only contain alphanumeric characters, no ".", no spaces, etc. The fact that the regex had a typo does not imply a vulnerability, although I will not exclude it either. It just was not proved although I acknowledge the regex needed fixing. On Sep 10, 2011, at 2:37 PM, Devin Jeanpierre wrote:
Not in this example. So why not?
Yes it did in this example. You introduced a vulnerability in your first attempt, and it was found by somebody else. eval makes accidental vulnerabilities way easier than they should be, even for people that are trying to be careful. Even your modified version had something that in some circumstances would be DoS-attackable because your verification still allowed for unintended operations. But yeah, if you can guarantee that there won't be any ill-effects from using eval, _of course_ it's OK. The problem is that these guarantees are too easy to get wrong, or to forget, or to misunderstand. Devin On Sat, Sep 10, 2011 at 3:27 PM, Massimo Di Pierro <massimo.dipierro@gmail.com> wrote:
First, the "vulnerability" was fixed. (*) Second, the parser could also have vulnerabilities. In fact I the vulnerability in the eval code was easy to find. How do you know there is no bug in the parser loop that I implemented that will cause some strings to go into an infinite loop?The explicit parser may still have a vulnerability, it is just more difficult to debug. Perhaps I put both there on purpose to see which one you could find. Massimo (*) I put it in quote because the possible values in name are already limited by the fact that name was an attribute (can only contain alphanumeric characters, no ".", no spaces, etc. The fact that the regex had a typo does not imply a vulnerability, although I will not exclude it either. It just was not proved although I acknowledge the regex needed fixing. On Sep 10, 2011, at 2:37 PM, Devin Jeanpierre wrote:
participants (2)
-
Devin Jeanpierre -
Massimo Di Pierro