Re: [PHP] MySql injections (related question)
On Fri, May 13, 2005 12:51 am, Marek Kilimajer said: Richard Lynch wrote: On Thu, May 12, 2005 4:43 pm, Chris Shiflett said: From me: The fact that it uses the character set of your current connection to MySQL means that what your escaping function considers to be a single quote is exactly what your database considers to be a single quote. If these things don't match, your escaping function can miss something that your database interprets, opening you up to an SQL injection attack. Under the following pre-conditions: 1. C Locale / English in MySQL data 2. No intention to ever switch natural language, nor database. is there any real benefit to spending man hours I really can't afford for legacy code to switch from Magic Quotes to mysql_real_escape_string -- and make no mistake, it would be a TON of man hours. It will take less than five minutes to write a recursive function that will stripslashes() all incoming variables and use mysql_real_escape_string() instead. Except that for integer data, I just type-cast to (int) and check the range, but for some string data, which should not have had any characters that need escaping, I'm doing a regex, and for the string data where characters that needed escaping, I'm already doing stripslashes(), then a regex, then an addslashes(), so applying stripslashes() to all incoming data will break all of those last ones pretty badly. Are we all on the same page now? :-) I'm not under-estimating the time/effort here. Honest. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
Richard Lynch wrote: On Fri, May 13, 2005 12:51 am, Marek Kilimajer said: Richard Lynch wrote: On Thu, May 12, 2005 4:43 pm, Chris Shiflett said: From me: The fact that it uses the character set of your current connection to MySQL means that what your escaping function considers to be a single quote is exactly what your database considers to be a single quote. If these things don't match, your escaping function can miss something that your database interprets, opening you up to an SQL injection attack. Under the following pre-conditions: 1. C Locale / English in MySQL data 2. No intention to ever switch natural language, nor database. is there any real benefit to spending man hours I really can't afford for legacy code to switch from Magic Quotes to mysql_real_escape_string -- and make no mistake, it would be a TON of man hours. It will take less than five minutes to write a recursive function that will stripslashes() all incoming variables and use mysql_real_escape_string() instead. Except that for integer data, I just type-cast to (int) and check the range, but for some string data, which should not have had any characters that need escaping, I'm doing a regex, and for the string data where characters that needed escaping, I'm already doing stripslashes(), then a regex, then an addslashes(), so applying stripslashes() to all incoming data will break all of those last ones pretty badly. Are we all on the same page now? :-) If this is how your application works now then it's really only search and replace s/addslashes/mysql_real_escape_string/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
Richard Lynch wrote: On Thu, May 12, 2005 4:43 pm, Chris Shiflett said: From me: The fact that it uses the character set of your current connection to MySQL means that what your escaping function considers to be a single quote is exactly what your database considers to be a single quote. If these things don't match, your escaping function can miss something that your database interprets, opening you up to an SQL injection attack. Under the following pre-conditions: 1. C Locale / English in MySQL data 2. No intention to ever switch natural language, nor database. is there any real benefit to spending man hours I really can't afford for legacy code to switch from Magic Quotes to mysql_real_escape_string -- and make no mistake, it would be a TON of man hours. It will take less than five minutes to write a recursive function that will stripslashes() all incoming variables and use mysql_real_escape_string() instead. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On Wed, May 11, 2005 8:58 pm, Jason Wong said: Well put it this way, addslashes() was not meant to make data safe for mysql, it just happened to work. Now there is a better/official/whatever alternative why not use it? Actually, unless I'm very much mistaken about why addslashes() was written, it *WAS* (and *IS*) designed to make data safe for MySQL. Okay, maybe technically it was first written for mSQL, but that being in the state it is, and the current state of affairs of PHP/MySQL... I'd bet a dollar that if the MySQL C Client library changed what needs escaping, addslashes would change with it. Am I delusional? What problem do you think addslashes() was written to solve? PS On the language/encoding thing... I don't think I'll ever figure that stuff out before I die, so there's not much point worrying about it, though I can certainly see why it's an atrractive MUST USE for those who can actually cope with more than one natural language! -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On Wed, May 11, 2005 8:27 pm, James Williams said: On 5/11/05, Richard Lynch [EMAIL PROTECTED] wrote: Is mysql_real_escape_string *DIFFERENT* in some incredibly huge secure way that I want to stop working on all my current projects to go re-write the 10,000,000 lines of code? 2 words: Search Replace. 2 words: Magic Quotes -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] MySql injections (related question)
-Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 8:47 AM I'd bet a dollar that if the MySQL C Client library changed what needs escaping, addslashes would change with it. Ehhh? I think not. Let´s let a mindgame (can´t spell hypo..whatever :-) and say that the MySQL folk figures out they wanna use the same way for escaping as PostgreSQL, then addslashes() would add ' ? The whole idea of nameconvention is gone then :-) But I do agree with You, need to hear *WHY* the mysql_real_escape_string() is better (and a so fu' long word :) What problem do you think addslashes() was written to solve? For those who has magic qoutes off? I still can figure out why some people hate that setting so much? Though one´s not safe with only magic quotes, addslashes() are needed too... -- Med venlig hilsen / best regards ComX Networks A/S Kim Madsen Systemudvikler/Systemdeveloper -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
I'm pretty sure that, in order to use mysql_real_escape_string() you must have magic quotes off or use stripslashes first... the same as addslashes, so it should work if you just search and replace. Don't quote me on that though On 5/12/05, Richard Lynch [EMAIL PROTECTED] wrote: On Wed, May 11, 2005 8:27 pm, James Williams said: On 5/11/05, Richard Lynch [EMAIL PROTECTED] wrote: Is mysql_real_escape_string *DIFFERENT* in some incredibly huge secure way that I want to stop working on all my current projects to go re-write the 10,000,000 lines of code? 2 words: Search Replace. 2 words: Magic Quotes -- Like Music? http://l-i-e.com/artists.htm -- jamwil.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On Thu, May 12, 2005 12:39 pm, James Williams said: I'm pretty sure that, in order to use mysql_real_escape_string() you must have magic quotes off or use stripslashes first... the same as addslashes, so it should work if you just search and replace. Don't quote me on that though Well, yes, but you see it's no longer as simple as a global search and replace, since there is no addslashes all over the place. I have to hand-examine every file in, what, almost a decade's worth of code spread over several dozen websites? What is the CURRENT security advantage, if any, to mysql_real_escape_string versus Magic Quotes? -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
I couldn't tell you the technicals of it, but just from the php documentation: This function must always (with few exceptions) be used to make data safe before sending a query to MySQL. On 5/12/05, Richard Lynch [EMAIL PROTECTED] wrote: On Thu, May 12, 2005 12:39 pm, James Williams said: I'm pretty sure that, in order to use mysql_real_escape_string() you must have magic quotes off or use stripslashes first... the same as addslashes, so it should work if you just search and replace. Don't quote me on that though Well, yes, but you see it's no longer as simple as a global search and replace, since there is no addslashes all over the place. I have to hand-examine every file in, what, almost a decade's worth of code spread over several dozen websites? What is the CURRENT security advantage, if any, to mysql_real_escape_string versus Magic Quotes? -- Like Music? http://l-i-e.com/artists.htm -- jamwil.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] MySql injections (related question)
On Thu, May 12, 2005 1:44 am, Kim Madsen said: -Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 8:47 AM I'd bet a dollar that if the MySQL C Client library changed what needs escaping, addslashes would change with it. Ehhh? I think not. Let´s let a mindgame (can´t spell hypo..whatever :-) and say that the MySQL folk figures out they wanna use the same way for escaping as PostgreSQL, then addslashes() would add ' ? The whole idea of nameconvention is gone then :-) But I do agree with You, need to hear *WHY* the mysql_real_escape_string() is better (and a so fu' long word :) What problem do you think addslashes() was written to solve? For those who has magic qoutes off? I still can figure out why some people hate that setting so much? Though one´s not safe with only magic quotes, addslashes() are needed too... Kim, I'm sorry, but it's blatantly clear that you don't understand Magic Quotes and addslashes() Magic Quotes calls addslashes() automatically on data coming from GET/POST/COOKIE. (And maybe from other sources, depending on php.ini) It's that simple. You would NEVER use both Magic Quotes and addslashes() on the same chunk of data. That would just escape the escape characters and screw up your data, so you'd need to use stripslashes() on all data coming *OUT* of the database, to un-do the second addslashes() you called on the data you never should have called it on in the first place. Which is not to say I haven't seen a few zillion newbies, and even journey-man scripts do this, as the programmers incorrectly believed that's what they needed to do. I'm almost certain that both addslashes() and Magic Quotes were designed, from the get-go, to escape data being sent to mSQL/MySQL, but I'm waiting to hear from, say, Rasmus, that that's true. Wanna bet money on it? I got a dollar. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
Richard Lynch wrote: It's all very well to repeat these pronouncements from on high that mysql_real_escape_string is better but I personally would sure appreciate somebody who's saying this to say *WHY* it is better, and in precisely what ways it is different from addslashes and/or magic quotes with or without data scrubbing. From me: The fact that it uses the character set of your current connection to MySQL means that what your escaping function considers to be a single quote is exactly what your database considers to be a single quote. If these things don't match, your escaping function can miss something that your database interprets, opening you up to an SQL injection attack. This type of attack isn't quite as easy as when someone doesn't escape their data at all, but it's something that can be avoided by using the proper escaping function. From Derick Rethans (sitting beside me): Other things are that addslashes() screws up with big-5 (it can contains \'s in multi-byte characters), and mysql_real_escape_string() takes into account charcter sets. -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On Thu, May 12, 2005 4:43 pm, Chris Shiflett said: From me: The fact that it uses the character set of your current connection to MySQL means that what your escaping function considers to be a single quote is exactly what your database considers to be a single quote. If these things don't match, your escaping function can miss something that your database interprets, opening you up to an SQL injection attack. Under the following pre-conditions: 1. C Locale / English in MySQL data 2. No intention to ever switch natural language, nor database. is there any real benefit to spending man hours I really can't afford for legacy code to switch from Magic Quotes to mysql_real_escape_string -- and make no mistake, it would be a TON of man hours. If I *HAVE* to do it; fine. If it's not going to really make a difference in my Security, I'm only going to use mysql_real_escape_string going forward. Or, put it another way: If somebody puts in some big-5 data, or whatever, and I have Magic Quotes, is it safe or is that somehow going to allow some sql-injection security hole? -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
-- Original message -- From: Richard Lynch [EMAIL PROTECTED] On Thu, May 12, 2005 4:43 pm, Chris Shiflett said: From me: The fact that it uses the character set of your current connection to MySQL means that what your escaping function considers to be a single quote is exactly what your database considers to be a single quote. If these things don't match, your escaping function can miss something that your database interprets, opening you up to an SQL injection attack. Under the following pre-conditions: 1. C Locale / English in MySQL data 2. No intention to ever switch natural language, nor database. is there any real benefit to spending man hours I really can't afford for legacy code to switch from Magic Quotes to mysql_real_escape_string -- and make no mistake, it would be a TON of man hours. I believe it also takes into account special characters like _ and %, which addslashes does not. In certain instances if you do not escape special characters, such as the wildcards I mentioned, the results that you get can differ from what you intended. One instance this comes into play is a search form used by a non-technical user. You should probably check that though, it has been a while since I have looked into it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
I have a related question, many of you have suggested using addslashes on your variables to prevent SQL injections, but is it safer to use mysql_real_escape_string (or mysql_escape_string)? What is the benefit / cost of using mysql_real_escape_string rather than addslashes? When using Postgres i always use pg_escape_string on anything i send the DB's way. In fact the manual says specifically to use pg_escape_string rather than addslashes (however it doesnt give that advice in mysql_real_escape_string )... http://us3.php.net/manual/en/function.pg-escape-string.php Not being familiar with the internals of any of these functions, i'm wondering which are safer or do they do approximately the same thing? Is there any difference in performance? Which method do you use and why? -k. __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On Thursday 12 May 2005 06:30, -k. wrote: I have a related question, many of you have suggested using addslashes on your variables to prevent SQL injections, but is it safer to use mysql_real_escape_string (or mysql_escape_string)? What is the benefit / cost of using mysql_real_escape_string rather than addslashes? When using Postgres i always use pg_escape_string on anything i send the DB's way. In fact the manual says specifically to use pg_escape_string rather than addslashes (however it doesnt give that advice in mysql_real_escape_string )... Postgresql uses a single-quote to escape a single-quote. MySQL uses a backslash. Hence running addslashes() on a string destined for MySQL is usually OK whilst doing so for Postgresql is not. But now that mysql_real_escape_string() is available that is what you ought to use. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- New Year Resolution: Ignore top posted posts -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On Wed, May 11, 2005 5:23 pm, Jason Wong said: But now that mysql_real_escape_string() is available that is what you ought to use. But are they REALLY different. Or, put it this way: Suppose I have 10,000,000 lines of code that have Magic Quotes on, which calls addslashes automatically, and I already have scrubbing in place for the data that can be scrubbed from untrusted users. Is mysql_real_escape_string *DIFFERENT* in some incredibly huge secure way that I want to stop working on all my current projects to go re-write the 10,000,000 lines of code? Or is mysql_real_escape_string just something I should use going forward in case it might be better someday, but it's really the same for now? Or, is it a LITTLE better for an obscure hack that won't affect me if my scrubbing is halfway decent? Or... ??? It's all very well to repeat these pronouncements from on high that mysql_real_escape_string is better but I personally would sure appreciate somebody who's saying this to say *WHY* it is better, and in precisely what ways it is different from addslashes and/or magic quotes with or without data scrubbing. It's not quite yet at the point where I'm getting tired of hearing about mysql_real_escape_string is better but the envelope is being pushed. :-) Maybe I just missed that detailed analysis of the inherent superiority of mysql_real_escape_string, but it's not for a lack of looking... -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On 5/11/05, Richard Lynch [EMAIL PROTECTED] wrote: Is mysql_real_escape_string *DIFFERENT* in some incredibly huge secure way that I want to stop working on all my current projects to go re-write the 10,000,000 lines of code? 2 words: Search Replace. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySql injections (related question)
On Thursday 12 May 2005 09:57, Richard Lynch wrote: On Wed, May 11, 2005 5:23 pm, Jason Wong said: But now that mysql_real_escape_string() is available that is what you ought to use. But are they REALLY different. mysql_real_escape_string() is most certainly different from mysql_escape_string(), and of course addslashes(), in that it takes into account the language/character encoding. Also manual entries for addslashes() and mysql_real_escape_string() does tell you what characters are escaped. Or, put it this way: [snip] Or is mysql_real_escape_string just something I should use going forward in case it might be better someday, but it's really the same for now? I suppose that if you're not using some esoteric character encoding then the standard addslashes() would suffice. However a quick fix is simply do a search and replace then make sure you have established an mysql connection early on in your code (before mysql_real_escape_string() is called). It's all very well to repeat these pronouncements from on high that mysql_real_escape_string is better but I personally would sure appreciate somebody who's saying this to say *WHY* it is better, and in precisely what ways it is different from addslashes and/or magic quotes with or without data scrubbing. mysql_real_escape_string() calls the underlying MySQL C client library and because that library is produced by the MySQL people they are in the best position to know what exactly needs escaping. And in the event that what needs escaping gets updated then you don't need to touch your code because when the MySQL library is updated you're set. Not so if you use your own escaping function(s). Maybe I just missed that detailed analysis of the inherent superiority of mysql_real_escape_string, but it's not for a lack of looking... Well put it this way, addslashes() was not meant to make data safe for mysql, it just happened to work. Now there is a better/official/whatever alternative why not use it? -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- New Year Resolution: Ignore top posted posts -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
