Thread: 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
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
>
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