Open clint317 opened 11 years ago
Same also goes for parameterized column names: select #tablename# from...
This is correct behaviour - the scanner searches for any hash expressions - it doesn't (cannot) know whether schema
/etc is a client-supplied variable that might contain an injection attack.
Possibly the best way to solve this would be to allow a comma-delimited list of known safe variables, but then again a variable that's safe in one file might not be safe in another, so will have to think a bit on a good way to resolve this.
It appears that the scanner reports false positives triggered by schema and/or table names when parameterized (scoped or not):
Is this not optimally acceptable^?