On Fri, Oct 07, 2011 at 12:46:52AM -0400, Govinda wrote: > >>>> http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/ > > Hi everyone > > I have read many many articles and blog posts in the last few days to > bolster my (still mostly newbie) understanding of the factors that > play in to preventing various methods of SQL injection prevention.. > and by now I am well aware that most everyone (expert) here says > prepared statements are the most secure method of (string hacking) > SQL-injection prevention.. even to the point of saying that one common > (and at least previously-popular) alternative > "mysql-real-escape-string" is "..silly and technically insecure..". > > I am learning and using the CodeIgniter (CI) framework for my current > project and, not wanting to leave myself vulnerable, I read posts on > the CI forum on this topic, to find out if I could (or needed) to use > prepared statements in CI.. and I read one forum thread where one dev > shows how to hack the core system of CI so that it can use PDO (for > prepared statements) instead of the built-in ActiveRecord (or "Query > Bindings") which apparently rely on mysql-real-escape-string. In that > thread, the debate goes back and forth, as it does in other threads.. > and while the sentiment that prepared statements are better because > they remove the need to keep being ahead of the char-escaping chase... > I never did see any example of *how* mysql-real-escape-string fails. > The only thing I ever read that does show mysql-real-escape-string > possibly failing is in the example in this article: > > http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string > > or rather an article referred to there, here: > http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html > > ..which only comes up in certain circumstances.. ("[snip]..The bottom > line while the problem is serious, it would only affect people > changing character sets from single-byte encodings to multibyte ones. > As long as you stay away from multibyte encodings, with the exception > of UTF8 you should be safe...[snip]"). > > All well and good. I just wanted to understand, as a relative newbie, > why such bold seemingly definitive statements are made here on this > list in recent weeks, like ".. escaping doesn't work.." ? > > http://marc.info/?l=php-general&m=131293616328301&w=2 > http://marc.info/?l=php-general&m=131603743606025&w=2 > > Isn't it that it does work in most cases.. and one just needs to > know in which cases it can fail, and how to handle things in each > case? I totally get the point that prepared statements just remove > so much of the head pressure of sorting all this out.. BUT when > someone (mostly new) like me comes along and hears that > "mysql-real-escape-string is simply not secure", then it just gives > an unclear and incomplete picture, and creates more head pressure. > > Or is there definitive evidence, more recent than the above-mentioned > articles, that shows how to hack through mysql-real-escape-string even > in an SQL statement e.g. inserting into a UTF8 db, a properly escaped > (mysql-real-escape-string) var? > > In case my post here is lacking understanding, then please forgive.. > and better yet, please explain! I post/ask because I am wanting to > SEE the whole everything like you few experts here who really know > exactly what everyone is talking about (or when they are just groping > in the dark). There is more to SQL injection than getting the quoting correct. In my understanding, prepared statements handles the other problems associated with queries and SQL injection beyond just quoting. Here's a good tutorial on how this works: http://www.youtube.com/watch?v=bORZlmyDw0s Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
