
Hello everybody

I am a Ph.D student who just innocently upgraded from 7.1 to 7.2 his home
brewed content management system. 
The update went allright (datawise speaking) but once i fired up the site
again i was flooeded with errors.. what happened? simple
starting from 7.2 strings are not truncated silently anymore.

While this might be standard SQL (i dont know, i am not an expert and ,
quite honeslty, i dont care) i have a few notes which might be worth
considering:

IMHO silent truncation is a valuable feature to my sistem and i see no
easy way to get around it, how shold i do ?

a)replacing Char(x) with "text" type? a security hazard! now every new
user
can upload up to 8 MB in string for each text field I leave open! 

b)checking the lenght of EACH FIELD IN EACH QUERY? that means
specifically querying the DB for the metadata (performance nightmare) or
including metadata about the db in the application (software engineering
nightmare).

c)leave everything as it is.. maybe get those limits a bit larger and hope
that no user ever enters stuff that's too large .. else he'll get nasty
errors .. on the other hand that also requires me to handle all query
failures directly (put error handles) althought very sound and
conservative coding practices (as the postgres code itself , I
assume) require this to be done this is really not the case of web
scripting and i dont really thing it should be required.

To make a long story short

Silent truncation wasnt bad ad all.. can we have it back ? (via a switch
or something? ) i think a good idea would be to have it "field wise" like
create table foo(a char(120) silent_trunc).  

I do not foresee being able to use postgresql in a non hi-end web
development environment otherwise.

thanks for the attention
Giovanni Tummarello




Mon, 11 Feb 2002 17:50:16 +0100 (CET)
Giovanni Tummarello <tummarel@ascu.unian.it>
Serious 7.2 issue (non quiet string truncation)
Why can't you truncate the string yourself.

Take atleast one of these actions:

1.    Limit the forms themselves to the length in question:
<input type="text" size="50" />

2.    Use trim the string to length in the code (php below):
$string = substr($string, 0, 50);

3.    Have the INSERT truncate the string:
INSERT INTO table (col1) VALUES (substring('valuetoinsert', 1, 5));


Any of the above (or all of the above) will accomplish what you
require.  I personally suggest both 1 and 2.  But 3 can be used if
necessary.
--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Giovanni Tummarello" <tummarel@ascu.unian.it>
To: <pgsql-hackers@postgresql.org>
Sent: Monday, February 11, 2002 11:50 AM
Subject: [HACKERS] Serious 7.2 issue (non quiet string truncation)


>
> Hello everybody
>
> I am a Ph.D student who just innocently upgraded from 7.1 to 7.2 his
home
> brewed content management system.
> The update went allright (datawise speaking) but once i fired up the
site
> again i was flooeded with errors.. what happened? simple
> starting from 7.2 strings are not truncated silently anymore.
>
> While this might be standard SQL (i dont know, i am not an expert
and ,
> quite honeslty, i dont care) i have a few notes which might be worth
> considering:
>
> IMHO silent truncation is a valuable feature to my sistem and i see
no
> easy way to get around it, how shold i do ?
>
> a)replacing Char(x) with "text" type? a security hazard! now every
new
> user
> can upload up to 8 MB in string for each text field I leave open!
>
> b)checking the lenght of EACH FIELD IN EACH QUERY? that means
> specifically querying the DB for the metadata (performance
nightmare) or
> including metadata about the db in the application (software
engineering
> nightmare).
>
> c)leave everything as it is.. maybe get those limits a bit larger
and hope
> that no user ever enters stuff that's too large .. else he'll get
nasty
> errors .. on the other hand that also requires me to handle all
query
> failures directly (put error handles) althought very sound and
> conservative coding practices (as the postgres code itself , I
> assume) require this to be done this is really not the case of web
> scripting and i dont really thing it should be required.
>
> To make a long story short
>
> Silent truncation wasnt bad ad all.. can we have it back ? (via a
switch
> or something? ) i think a good idea would be to have it "field wise"
like
> create table foo(a char(120) silent_trunc).
>
> I do not foresee being able to use postgresql in a non hi-end web
> development environment otherwise.
>
> thanks for the attention
> Giovanni Tummarello
>
>
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>


Mon, 18 Feb 2002 15:28:15 -0500
"Rod Taylor" <rbt@zort.ca>
Re: Serious 7.2 issue (non quiet string truncation)
Giovanni Tummarello writes:

> IMHO silent truncation is a valuable feature to my sistem and i see no
> easy way to get around it, how shold i do ?

Add a trigger that truncates the value.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 18 Feb 2002 15:41:25 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: Serious 7.2 issue (non quiet string truncation)
On Mon, Feb 18, 2002 at 03:28:15PM -0500, Rod Taylor wrote:
> Why can't you truncate the string yourself.
> 
> Take atleast one of these actions:
> 
> 1.    Limit the forms themselves to the length in question:
> <input type="text" size="50" />

An attacker could circument this by not going through the webform.
While it's doubtful such an attack would cause an exploitable
condition in a language like PHP, it's still better to check
post-submission...

> 2.    Use trim the string to length in the code (php below):
> $string = substr($string, 0, 50);

like this.

> 3.    Have the INSERT truncate the string:
> INSERT INTO table (col1) VALUES (substring('valuetoinsert', 1, 5));
> 
> 
> Any of the above (or all of the above) will accomplish what you
> require.  I personally suggest both 1 and 2.  But 3 can be used if
> necessary.

1 and 2, as you say.

Otherwise some day you convert your code over to C and forget to
truncate, and you may be exploitable.

-- 
David Terrell            | "Science is like sex: sometimes
dbt@meat.net             | something useful comes out, but
Nebcorp Prime Minister   | that is not the reason we are
http://wwn.nebcorp.com/  | doing it" -- Richard Feynman

Mon, 18 Feb 2002 13:10:09 -0800
David Terrell <dbt@meat.net>
Re: Serious 7.2 issue (non quiet string truncation)