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
