Re: text field constraint advice - Mailing list pgsql-general

From Jeff Davis
Subject Re: text field constraint advice
Date
Msg-id 1106726496.2886.830.camel@jeff
Whole thread Raw
In response to Re: text field constraint advice  (Michael Fuhr <mike@fuhr.org>)
Responses Re: text field constraint advice  ("Frank D. Engel, Jr." <fde101@fjrhome.net>)
List pgsql-general
On Wed, 2005-01-26 at 00:08 -0700, Michael Fuhr wrote:
> On Wed, Jan 26, 2005 at 12:27:17AM -0600, Dale Sykora wrote:
>
> >     I would like to use a text field in a table and limit the size to
> > reduce the chance of denial-of-service/buffer overflow/etc.  I assume I
> > can define table fields similar to the following
> > "field_name text check (len(field) < 160)" although my syntax is
> > probably wrong.
>
> You could use varchar(n) instead of text with a check constraint.

In this case I would advise using text instead of varchar(n). The reason
is that varchar(n) implies an intrinsic, unchangable rule that the field
never exceed a length of n. An example of that might be a state
abbreviation.

The check constraint is more able to adjust to changing needs.

In fact, I may go so far as to say that it's the application's
responsibility to verify the length (at the same time that it's escaping
the SQL special chars). The reason for that is because the database
wouldn't be corrupt or invalid in any way if the text field contained
(for example) 161 chars. So, it should really be more a matter of
security against DoS attacks, which is the domain of the application.
Also the application is the only one that knows what to do in case the
string is too long, so why bother sending it to the database to see if
it is too long?

But from a technical standpoint, it's really all the same, so he can use
whatever he feels comfortable with.

As for choosing a maximum number, you basically want it high enough that
no significant number of well-meaning people are thwarted by it (you
don't want someone with a long name being upset with you and going to a
competitor), and low enough to make an attacker realize that he's not
going to accomplish anything and go away. If the number is 1000, it
might make the attacker think he's accomplishing something and he might
hang around longer looking for other openings.

Regards,
    Jeff Davis



pgsql-general by date:

Previous
From: Sibtay Abbas
Date:
Subject: Re: working with multidimensional arrays in plpgsql
Next
From: "Magnus Hagander"
Date:
Subject: Re: EMBEDDED PostgreSQL