Re: update phenomenom - Mailing list pgsql-general

From Steve Crawford
Subject Re: update phenomenom
Date
Msg-id 200306061252.19427.scrawford@pinpointresearch.com
Whole thread Raw
In response to update phenomenom  ("Henrik Steffen" <steffen@city-map.de>)
List pgsql-general
Anything is possible but I have never seen this come up as a known PostgreSQL
problem on these boards.

Without knowing the specifics of your code (are your using the DBD::Pg
interface or a system call to psql or ??) I recommend reading the articles
that Google returns for "sql injection attack" and then double-checking _all_
of your error verification code (an "attack" could in some cases be a user
typo that causes undesirable results).

Here's an example (I'm not claiming that your code works at all like this):

Suppose you carefully check $kundennummer but $daten is created by taking the
user's input and prepending "miano=". Then suppose you feed that to psql
using a system call. An unfortunately placed ; could ruin your day.

You might expect to generate:
update foo set minao=12345 where kundennummer = '071002883';
(should update one record)

but if someone types 12345; you will end up with:
update foo set minao=12345; where kundennummer = '071002883';
which will first update all records (first statement) and then generate a
parsing error on "where kundennummer = '071002883';"

Also, are you sure that the update came from the web app? Is it possible that
someone (who now wants to remain anonymous) screwed up a manual update in
psql?

Cheers,
Steve


On Friday 06 June 2003 1:58 am, Henrik Steffen wrote:
> Hello all,
>
> I have a table consisting of about 450.000 rows
> with a unique primary key char(9)
>
> kundennummer CHAR(9) unique primary key
> ... some fields...
> miano CHAR(6)
>
> Today someone issued an
>
> UPDATE table SET miano='071002' WHERE kundennummer='071002883';
>
> and managed to UPDATE all the 450.000 rows, updating
> the miano to the value '071002' by issuing this command.
>
>
> The update is generated through a web-based intranet-solution,
> unfortunately I didn't have a postgresql-logfile for this, but
> I can see from the webserver logfile, which scripts was run
> at the particular time.
>
> For me it's almost 99.9 % sure, that it's no error in the
> perl-program. There is only one command issuing exactly
>
> SQL("UPDATE $table SET $daten WHERE kundennummer='$kundennummer';");
>
> where $table is the table-variable
> $daten is what is to be set
> $kundennummer is the client-number, which is checked before to match
> exactly 9 digits.
>
>
> Could there be any postgresql-server-side explanation for this phenomenom ?
> Perhaps
> anything about corrupted indexes, or anything?
>
>
> --
>
> 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
> --------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html


pgsql-general by date:

Previous
From: Lynna Landstreet
Date:
Subject: Special characters in varchar/text fields
Next
From: Elein Mustain
Date:
Subject: Re: server process segfaulting