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)---------------------------

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

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