Re: update phenomenom - Mailing list pgsql-general

hi,

I tried both:

 $command="UPDATE table SET miano='12345'; commit; ' WHERE ... ;";


and

 $command="UPDATE table SET miano='12345'; -- ' WHERE ... ;";


neither worked.

it just gives an error and dies.
no update done.

you are right: I should do more input-checking.

however, I would like to first see, how exactly this
attack was done... otherwise I won't be able to
defend it.

I looked at man DBI, but couldn't find any restriction
for $dbh->prepare() .... I am not sure, if it's possible
to pass multiple statements to the prepare-method.


--

Mit freundlichem Gruß

Henrik Steffen
Geschäftsführer

top concepts Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - Germany
--------------------------------------------------------
http://www.topconcepts.com          Tel. +49 4141 991230
mail: steffen@topconcepts.com       Fax. +49 4141 991233
--------------------------------------------------------
24h-Support Hotline:  +49 1908 34697 (EUR 1.86/Min,topc)
--------------------------------------------------------
Ihr SMS-Gateway: JETZT NEU unter: http://sms.city-map.de
System-Partner gesucht: http://www.franchise.city-map.de
--------------------------------------------------------
Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
--------------------------------------------------------

----- Original Message -----
From: "Jan Wieck" <JanWieck@Yahoo.com>
To: "Henrik Steffen" <steffen@city-map.de>
Cc: "pgsql" <pgsql-general@postgresql.org>
Sent: Saturday, June 07, 2003 5:34 PM
Subject: Re: [GENERAL] update phenomenom


> Henrik Steffen wrote:
> > yes, input is coming from a web form.
> >
> > my SQL() function uses DBD::Pg in Perl
> >
> > and it does the following:
> >
> > sub SQL {
> >     my $command=shift;
> >     ...
> >     $sth=$db->prepare($command);
> >     $sth->execute();
> >     ...
> > }
> >
> >
> > Now I tried the following:
> >
> > $command="UPDATE table SET miano='12345';' WHERE kundennummer='12345';";
> >
> > note the inner ; !  so I am trying an SQL injection attack
> >
> > But this just delivers an Error from DBD::Pg. And no update at all is
done.
> >
>
> Autocommit off? Try this injection attack:
>
>      $command="UPDATE table SET miano='12345'; commit; ' WHERE ... ;";
>
> It should lead to an error message as well, but this time doing the
update.
>
> >
> > However, I believe it still has got to be a kind of attack, though the
user
> > certainly didn't know this... so, probably something that was entered
> > unconsciously into the web-form.
> >
> > It was certainly no psql user who did this, because I can trace it back
> > to a certain perl-script 100% sure. furthermore, I am the only one who
> > actually has got psql-access....*lol*
> >
> > I looked at the perl-script more detailed now:
> >
> > Not only the field 'miano' should be updated but also 6 other fields.
> >
> > Four of these columns have been updated in all 450.000 rows, two others
> > have NOT been updated. This leads me to the conclusion, that
> > there has probably been a '; entered into form-fields four, so the
> > where-clause was not executed - this would explain, why the other
> > 2 columns were not update at all.
> >
> > I wonder, if there might have been a kind of comment-character after
> > the ';. Because trying it manually, I keep getting an error. But
> > is there a way to send a ';# to comment out the rest of the line?
>
> That would be '; --
>
> >
> > Or a ';\n or ';\0 or any special character?
> >
> > Very strange, very strange.
> >
> > BTW: I remember that I have had the same error once before, a few
> > months ago. What strikes me, is , that the same function is triggered
> > 50 times every day, and only every 5th month this strange error occurs.
> >
> > This led me to the thought, that maybe there could be some database
> > corruption or something.... but it looks very much like an attack, don't
> > you believe?
>
> Absolutely. This possiblity of SQL injection is one of the biggest
> security holes. Some programmers do check input but fail to realize that
> they do it on the wrong system, on the client side. So even if you have
> JavaScript of whatever checking the content of input fields, someone can
> handcraft a POST HTTP request. The best way to avoid this is to put
> EVERY input from forms into properly quoted string literals "in the
> middleware" and cast them from there to their correct data type.
>
>
> Jan
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #================================================== JanWieck@Yahoo.com #
>