Re: SQL injection

From: Alex Turner <armtuk(at)gmail(dot)com>
To: Yonatan Ben-Nes <da(at)canaan(dot)co(dot)il>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: SQL injection
Date: 2005-10-31 18:10:57
Message-ID: 33c6269f0510311010x474de6e6ra608738e25c90dc8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I don't know too much about this solutions, but It always seemed to me
that simple numeric validation plus magic-quotes will work just fine.

Simply validate any numeric input (or you can just quote it with
postgresql, and postgres will do it for you), and auto-escape any
string inputs (particularly quotes). replace("'","\\'");

I haven't figured out an attack that will get past this simple scheme
yet, I would love for somebody to correct me, because my sites are
built on this simple premise ;).

Alex

On 10/31/05, Yonatan Ben-Nes <da(at)canaan(dot)co(dot)il> wrote:
> Hi all,
>
> I'm currently trying to build a defence against SQL INJECTION, after
> reading some material on it I arrived to few possible solutions and I
> would like to know if anyone can comment anything about them or maybe
> add a solution of its own:
>
> 1. PachyRand: SQL Randomization for the PostgreSQL JDBC Driver - seems
> to be the best solution (easiest and most protective) though I didnt
> understood entirely if the solution is available for production
> enviorments or not, information can be attained at:
> http://nsl.cs.columbia.edu/projects/pachyrand/ &
> http://mice.cs.columbia.edu/getTechreport.php?techreportID=355&format=pdf&
>
> 2. Running for each data which will be used at the db checks with
> regular expressions to find out if its valid, this method is quite
> complicated to me (dont know regular expressions too much) and it
> demands diffrent checks to each data field (with quite big problems at
> open text data), at the end im afraid that holes will exist..
>
> 3. Running PHP functions like settype($data, 'integer') to be sure that
> the data which arrive is at the correct format and to the text run
> pg_escape_string($data), I suspect that this method wont block even
> close to 100% of the attacks, just like the former option.
>
> Another factor is the overhead to the system, I think that the previous
> methods don't create much overhead but if anyone have another idea of
> course it will also need to be efficent.
>
> Any new ideas or comments will be received gladly.
>
> Thanks in advance!
> Yonatan Ben-Nes
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message DEV 2005-10-31 18:11:20 replace() and Regular Expressions
Previous Message Yonatan Ben-Nes 2005-10-31 17:54:58 SQL injection