Search Postgresql Archives

Re: SQL injection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I didn't think query plans were cached between sessions, in which case
prepeared statements aren't worth much for most HTTP based systems
(not counting luckily re-using the same connection using pgpool)...

Please correct me if I'm mistaken - I like being wrong ;)

Alex

On 10/31/05, Jim C. Nasby <jnasby@xxxxxxxxxxxxx> wrote:
> Does PHP support prepared queries with bound parameters for PostgreSQL?
> Not only is that foolproof (unless you're calling a function that uses
> an argument to build a query string...), you'll get a performance boost
> as well since PostgreSQL won't have to reparse and plan every query.
>
> On Mon, Oct 31, 2005 at 07:54:58PM +0200, Yonatan Ben-Nes 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
> >
>
> --
> Jim C. Nasby, Sr. Engineering Consultant      jnasby@xxxxxxxxxxxxx
> Pervasive Software      http://pervasive.com    work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
       message can get through to the mailing list cleanly


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux