Professional Web Applications Themes

text field constraint advice - PostgreSQL / PGSQL

PostgreSQL users, 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. Is checking text length considered a good idea? If so, what would be a reasonable limit? I was thinking about 10 * average_field_char_length (if avg value is 16 char, set limit to 160 char). Thanks in advance for your opinions. Thanks, Dale ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster...

  1. #1

    Default text field constraint advice

    PostgreSQL users,
    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. Is checking text length considered a good idea? If so,
    what would be a reasonable limit? I was thinking about 10 *
    average_field_char_length (if avg value is 16 char, set limit to 160
    char). Thanks in advance for your opinions.

    Thanks,

    Dale



    ---------------------------(end of broadcast)---------------------------
    TIP 4: Don't 'kill -9' the postmaster

    Dale Sykora Guest

  2. #2

    Default Re: text field constraint advice

    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.
    > Is checking text length considered a good idea?
    That depends on the application and the trustworthiness of the data
    source. If you know that values should never exceed a certain
    length and you want to prevent obviously bad values from being
    inserted, then enforcing a length limit makes sense.
    > If so, what would be a reasonable limit? I was thinking about
    > 10 * average_field_char_length (if avg value is 16 char, set
    > limit to 160 char).
    Again, that depends on the application. If you're storing product
    part numbers then most of them will probably fall close to the
    average length, so allowing ten times the average length would be
    unnecessary. On the other hand, if you're storing product descriptions
    then you might need to allow for greater variation. Use whatever
    makes sense for the type of data you're storing.

    --
    Michael Fuhr
    [url]http://www.fuhr.org/~mfuhr/[/url]

    ---------------------------(end of broadcast)---------------------------
    TIP 3: if posting/reading through Usenet, please send an appropriate
    subscribe-nomail command to [email]majordomopostgresql.org[/email] so that your
    message can get through to the mailing list cleanly

    Michael Fuhr Guest

  3. #3

    Default Re: text field constraint advice

    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



    ---------------------------(end of broadcast)---------------------------
    TIP 1: subscribe and unsubscribe commands go to [email]majordomopostgresql.org[/email]

    Jeff Davis Guest

  4. #4

    Default Re: text field constraint advice

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Well, that's all fine as long as the hacker does not connect directly
    to the database server when attempting his attack. Check it in the app
    yes, but if this is really a genuine concern, it should be reinforced
    by the server as an added precaution.

    On Jan 26, 2005, at 3:01 AM, Jeff Davis wrote:
    > 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?
    - -----------------------------------------------------------
    Frank D. Engel, Jr. <fde101fjrhome.net>

    $ ln -s /usr/share/kjvbible /usr/manual
    $ true | cat /usr/manual | grep "John 3:16"
    John 3:16 For God so loved the world, that he gave his only begotten
    Son, that whosoever believeth in him should not perish, but have
    everlasting life.
    $
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (Darwin)

    iD8DBQFB95gk7aqtWrR9cZoRAvk0AJwPM0obldPGktkjJWkBC1 1iMrPtTQCgiQfa
    WbG/Bdj+yG9DSaTbSvRUlT0=
    =c4+z
    -----END PGP SIGNATURE-----



    __________________________________________________ _________
    $0 Web Hosting with up to 120MB web space, 1000 MB Transfer
    10 Personalized POP and Web E-mail Accounts, and much more.
    Signup at [url]www.doteasy.com[/url]


    ---------------------------(end of broadcast)---------------------------
    TIP 1: subscribe and unsubscribe commands go to [email]majordomopostgresql.org[/email]

    Frank D. Engel, Jr. Guest

  5. #5

    Default Re: text field constraint advice

    Generaly network security suggests that your database server should
    not allow connections from external addresses (including for services
    like ssh as well as pgsql). iptables can help acheive this if your
    servers are all on public IPs (also not a very good idea), otherwise
    the best place to configure this is at your firewall/router.

    Alex Turner
    NetEconomist


    On Wed, 26 Jan 2005 08:16:19 -0500, Frank D. Engel, Jr.
    <fde101fjrhome.net> wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Well, that's all fine as long as the hacker does not connect directly
    > to the database server when attempting his attack. Check it in the app
    > yes, but if this is really a genuine concern, it should be reinforced
    > by the server as an added precaution.
    >
    > On Jan 26, 2005, at 3:01 AM, Jeff Davis wrote:
    >
    > > 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?
    > - -----------------------------------------------------------
    > Frank D. Engel, Jr. <fde101fjrhome.net>
    >
    > $ ln -s /usr/share/kjvbible /usr/manual
    > $ true | cat /usr/manual | grep "John 3:16"
    > John 3:16 For God so loved the world, that he gave his only begotten
    > Son, that whosoever believeth in him should not perish, but have
    > everlasting life.
    > $
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v1.2.4 (Darwin)
    >
    > iD8DBQFB95gk7aqtWrR9cZoRAvk0AJwPM0obldPGktkjJWkBC1 1iMrPtTQCgiQfa
    > WbG/Bdj+yG9DSaTbSvRUlT0=
    > =c4+z
    > -----END PGP SIGNATURE-----
    >
    > __________________________________________________ _________
    > $0 Web Hosting with up to 120MB web space, 1000 MB Transfer
    > 10 Personalized POP and Web E-mail Accounts, and much more.
    > Signup at [url]www.doteasy.com[/url]
    >
    >
    > ---------------------------(end of broadcast)---------------------------
    > TIP 1: subscribe and unsubscribe commands go to [email]majordomopostgresql.org[/email]
    >
    ---------------------------(end of broadcast)---------------------------
    TIP 7: don't forget to increase your free space map settings

    Alex Turner Guest

  6. #6

    Default Re: text field constraint advice

    On Wed, Jan 26, 2005 at 01:29:53PM -0500, Alex Turner wrote:
    > Generaly network security suggests that your database server should
    > not allow connections from external addresses (including for services
    > like ssh as well as pgsql). iptables can help acheive this if your
    > servers are all on public IPs (also not a very good idea), otherwise
    > the best place to configure this is at your firewall/router.
    Some people like to have constraints in the database in addition
    to whatever host- or network-based security is in place. The
    thinking is that the closer the constraints are to the data, the
    less likely they are to be cirvented, either intentionally or
    accidentally. Firewalls keep out unauthorized users, application
    checks provide a layer of defense against bogus data from authorized
    users, and constraints in the database itself prevent bad data from
    being entered by misbehaving applications or by users who are
    bypassing the application (e.g., somebody tweaking the data from a
    psql session). Constraints in table definitions also serve as
    self-doentation.

    --
    Michael Fuhr
    [url]http://www.fuhr.org/~mfuhr/[/url]

    ---------------------------(end of broadcast)---------------------------
    TIP 3: if posting/reading through Usenet, please send an appropriate
    subscribe-nomail command to [email]majordomopostgresql.org[/email] so that your
    message can get through to the mailing list cleanly

    Michael Fuhr Guest

Similar Threads

  1. Forms: Text field - auto fill another field?
    By LDVDG@adobeforums.com in forum Adobe Acrobat Macintosh
    Replies: 3
    Last Post: May 18th, 05:35 PM
  2. Defined text field in form -> subject field in e-mail
    By olaka in forum Dreamweaver AppDev
    Replies: 0
    Last Post: March 14th, 02:20 PM
  3. Replies: 2
    Last Post: February 22nd, 04:59 PM
  4. Converting a text field to a date field - FM6
    By Carl Mittler in forum FileMaker
    Replies: 2
    Last Post: October 17th, 09:38 PM
  5. Linking date field to text field entry
    By Trey in forum Microsoft Access
    Replies: 1
    Last Post: July 16th, 07:35 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139