In article <email@example.com>,
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>Andy "Krazy" Glew wrote:
>> Listening to an old "Security Now" podcast while doing my morning
>> (http://www.unixwiz.net/techtips/sql-injection.html provides examples,
>> as does wikip[edia.).
>You had me until this point Andy, that's a pretty good explanation of
>> The general solution to this is "quotification": take the user input,
>And here is where you go wrong:
>The general solution is to totally separate parsing from user input,
>i.e. in your example above you would first parse the SELECT statement,
>using question marks as placeholders for where you expect input.
Indeed. As telecom learned the hard way with blue boxing etc;
never have in-band command and signalling.
If it is in-band someone will find a way to unravel the protection.
>Later on you execute that prepared (i.e. parsed) statement, substituting
>the actual user input for the placeholders:
>I.e. in perl this looks like this:
> # Let the DB parser see only static strings like this:
> my $sth =
> $dbh->prepare("SELECT FIELDLIST FROM TABLE WHERE NAME = '?'");
> # Get the possibly poisonous user input
> my $user_input = param('name');
>> Perhaps better to make taintimg the default. To flip the polarity of the
>> special bit. And to require that language syntax, keywords, etcv., be
>> set only if the special bit is set.
>Perl actually has 'taint' as a builtin feature. :-)
Morten ';update taxes set tax = 0.0 where name like "morten%reistad";'
|All times are GMT. The time now is 04:41 PM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.