-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
detect sql string modification #11
Comments
Hi Victor, The difficult part of this problem is the scope of variables. It's very easy to find all the occurrences of a variable named $x using a PPI tree, however PPI does not distinguish reused variable names or variables with the same name but in separate scopes. I have not seen any CPAN modules where I could pass a PPI tree and a variable name, and get a list of all the occurrences of that variable broken down by scope. I think the most promising path to solving this problem is to create such a module, then use the output to look at the context of each occurrence within the same scope to determine whether the modifications represent an injection risk. On the other hand, maybe the variable reuse problem is addressed by Perl::Critic::Policy::Variables::ProhibitReusedNames. As long as both plugins are used then maybe ignoring variable reuse is an acceptable trade-off? Your second case is beyond the scope of PPI, but fortunately I'm going to keep this ticket open and think a bit further on how to divide the problem space. |
another idea. if we can find all assigments to particular variable, then:
current behaviour: will warn about $y unsafe. (that should be recursive) My real use case: very often (in more than 50% case) I have the following code:
and $where_cond is a variable, with many many assigments and modifications above this line. |
this
and even that:
(possibly 1st case more common and 2nd is pretty complex)
p.s.
Great project ! Thanks!
The text was updated successfully, but these errors were encountered: