[Webappsec] Automatically detecting injections
michaelslists at gmail.com
Tue Apr 29 18:05:30 EDT 2008
On Tue, Apr 29, 2008 at 9:57 PM, Roberto Mansfield
<robertom at sas.upenn.edu> wrote:
> >> >> To me, the core of any injection vulnerability is that the meaning of
> >> the
> >> >> query or command is changed before it gets to the interpreter. Here,
> >> the
> >> >> meaning is unchanged.
> >> >
> >> > Eh? It's valid to have someone enter a SQL command via a website. Just
> >> > because the code doesn't process it for sql commands doesn't mean they
> >> > should. Your argument here is nonsense. The queries original context,
> >> > if the context is to only execute the 'assumed' statement, as written
> >> > by the coder, and not allow other statements to be injected, is
> >> > broken. To pretend that it's not 'injection' is just plain weird.
> >> I think there is a difference in the two types of vulnerabilities that's
> >> worth distinguishing. On the one hand, changing the meaning of the query is
> >> what I would call injection. Changing a data value (in this case the
> >> command to be exec'ed) to an unauthorized value is a validation problem. It
> >> makes a difference to the developer that has to fix the problem.
> > yes of course it's worth distinguishing, but it's still injection.
> > just at a different level.
> No, it isn't. I think it is important to stick with established
> definitions so we can be clear about these issues. Jeff makes pretty
> clear the difference between data validation and sql injection. Let's
> not confuse the two.
okay now you're wrong too.
More information about the Webappsec