Is DBI prepare() statement enough for SQL injection?

Discussion in 'Perl Misc' started by howa, Feb 25, 2008.

  1. howa

    howa Guest

    I have just found a simple cases, which is not, e.g.

    #--------------------------------------------------

    use strict;
    use DBI;
    use Data::Dumper;

    my $dbh = DBI-
    >connect("DBI:mysql:database=information_schema;host=localhost","root","",

    { RaiseError => 1, AutoCommit => 1 });

    my $input = "%a"; # User hack by using wildcard

    my $sth = $dbh->prepare("SELECT * FROM `CHARACTER_SETS` WHERE
    `CHARACTER_SET_NAME` LIKE ? ") ;
    $sth->execute( $input . "%") ; # Originally you let the user search by
    prefix

    while ( my $data = $sth->fetchrow_hashref() ) {
    print Dumper $data;
    }

    #--------------------------------------------------

    So we should not 100% believe in prepare() which make you100% SQL
    injection free.

    Any other cases want to share?

    Howard
     
    howa, Feb 25, 2008
    #1
    1. Advertising

  2. howa

    Guest

    howa <> wrote:
    > I have just found a simple cases, which is not, e.g.
    >
    > #--------------------------------------------------
    >
    > use strict;
    > use DBI;
    > use Data::Dumper;
    >
    > my $dbh = DBI-
    > >connect("DBI:mysql:database=information_schema;host=localhost","root",
    > >"",

    > { RaiseError => 1, AutoCommit => 1 });
    >
    > my $input = "%a"; # User hack by using wildcard


    That is not SQL injection.

    >
    > my $sth = $dbh->prepare("SELECT * FROM `CHARACTER_SETS` WHERE
    > `CHARACTER_SET_NAME` LIKE ? ") ;
    > $sth->execute( $input . "%") ; # Originally you let the user search by
    > prefix


    What do you mean by "originally"? You have shown us only one version
    of your code, there is no "originally".


    > So we should not 100% believe in prepare() which make you100% SQL
    > injection free.


    There is no SQL injection. The submitted value did not escape from what
    was intended to be a data value out into general SQL syntax. It stayed in
    the data value. The fact that that data value can be something you don't
    want does not make an SQL injection.

    > Any other cases want to share?


    There are thousands of ways to be incompetent. You want a listing of
    all of them?

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    The costs of publication of this article were defrayed in part by the
    payment of page charges. This article must therefore be hereby marked
    advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    this fact.
     
    , Feb 25, 2008
    #2
    1. Advertising

  3. howa <> writes:

    > my $sth = $dbh->prepare("SELECT * FROM `CHARACTER_SETS` WHERE
    > `CHARACTER_SET_NAME` LIKE ? ") ;
    > $sth->execute( $input . "%") ; # Originally you let the user search by
    > prefix


    That's no different from cases where you pass values to SQL predicates
    or functions: placeholders only make sure your values are passed as is,
    IOW they only take care of quoting. They don't prevent you from passing
    values that you don't like.

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
     
    Joost Diepenmaat, Feb 25, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Cardwell
    Replies:
    4
    Views:
    170
    Anno Siegel
    Feb 22, 2004
  2. Ulrich Herbst

    SQL Injection and DBI placeholders

    Ulrich Herbst, Jun 15, 2004, in forum: Perl Misc
    Replies:
    4
    Views:
    140
    Vetle Roeim
    Jun 16, 2004
  3. DBI prepare and fetch

    , Aug 30, 2005, in forum: Perl Misc
    Replies:
    5
    Views:
    151
  4. Replies:
    12
    Views:
    312
  5. Replies:
    7
    Views:
    164
Loading...

Share This Page