[Webappsec] Automatically detecting injections

[silky]

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.

i'm done.



>  Roberto
>



-- 
http://lets.coozi.com.au/