Re: [PHP] magic_quotes
On 8 Oct 2008, at 21:38, Bryan wrote:
My web site consists of some hard-coded html but on the main, data is
stored in MySQL and through the use of PHP I generate pages of html.
Everything went well this year until around June/July time when I
started noticing quotes (') were escaped in the generated html, so
it's would appear as it\'s. I use Dreamweaver 8 to develop my
site.
Hard-coded html is fine, it also obeys any CSS within it, PHP
generated html however doesn't obey CSS or URL's.
Looking at my computer server setup everything runs properly on the PC
but not on my webspace, it ran OK for 18 months on both. Looking at
php.ini on my PC I note magic_quotes_gpc is set to on and
magic_quotes_runtime is set to off. On my webspace I note
magic_quotes_gpc is set to on as is magic_quotes_runtime, I assume
this is what's screwing up the PHP generated html.
Is there a way to avoid this?
http://stut.net/blog/2008/06/08/where-are-these-backslashes-coming-from/
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
Hello,
without trying to embarrass myself, but
Here the smart quoting function off php.net
|function quote_smart($value)
{
// Stripslashes
if (get_magic_quotes_gpc()) {
$value = stripslashes($value);
}
// Quote if not a number or a numeric string
if (!is_numeric($value)) {
$value = ' . mysql_real_escape_string($value) . ';
}
return $value;
}
From that Idea I implemented that into my MySQL class:
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return stripslashes($string);
}
else {
return mysql_real_escape_string($string);
}
}
I call up in in the following manner:
$result= $mysql-query(SELECT *
FROM [[prefix]]_users
WHERE name =
'.MySQL::smartQuote($_POST['username']).'
AND password =
'.md5(MySQL::smartQuote($_POST['password'])).'
);
Now, when magic_quotes is off and the user name is say Jingle'sBells -
it works fine, because mysql_real_escape_string() kicks in.
But if magic_quotes is on I get the error that something is invalid in
my SQL syntax near 'sBells' - because of could it would look like name =
'Jingle'sBells'
So I modified a little:
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return mysql_real_escape_string(stripslashes($string));
}
else {
return mysql_real_escape_string($string);
}
}
That now works both with magic_quotes on and off for Inserts / Selects
etc. etc. (of course I have to call on MySQL::smartQuote() for each
value - but it's worth it. Or does my function defeat the point totally?
I did notice that with both magic_quotes On or Off data is inserted
correctly into the table as Jingle's Bells without slashes.
I was wondering if my above function is correct and the website's
documentation is off a little?
Regards,
Johannes
I'm grateful for any help.
|
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
On 12/1/06, Johannes Lindenbaum [EMAIL PROTECTED] wrote:
Hello,
without trying to embarrass myself, but
Here the smart quoting function off php.net
|function quote_smart($value)
{
// Stripslashes
if (get_magic_quotes_gpc()) {
$value = stripslashes($value);
}
// Quote if not a number or a numeric string
if (!is_numeric($value)) {
$value = ' . mysql_real_escape_string($value) . ';
}
return $value;
}
From that Idea I implemented that into my MySQL class:
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return stripslashes($string);
}
else {
return mysql_real_escape_string($string);
}
}
I call up in in the following manner:
$result= $mysql-query(SELECT *
FROM [[prefix]]_users
WHERE name =
'.MySQL::smartQuote($_POST['username']).'
AND password =
'.md5(MySQL::smartQuote($_POST['password'])).'
);
Now, when magic_quotes is off and the user name is say Jingle'sBells -
it works fine, because mysql_real_escape_string() kicks in.
But if magic_quotes is on I get the error that something is invalid in
my SQL syntax near 'sBells' - because of could it would look like name =
'Jingle'sBells'
So I modified a little:
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return mysql_real_escape_string(stripslashes($string));
}
else {
return mysql_real_escape_string($string);
}
}
That now works both with magic_quotes on and off for Inserts / Selects
etc. etc. (of course I have to call on MySQL::smartQuote() for each
value - but it's worth it. Or does my function defeat the point totally?
I did notice that with both magic_quotes On or Off data is inserted
correctly into the table as Jingle's Bells without slashes.
I was wondering if my above function is correct and the website's
documentation is off a little?
Regards,
Johannes
I'm grateful for any help.
|
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return stripslashes($string);
}
else {
return mysql_real_escape_string($string);
}
}
You almost have it. What you need to do is if magic quotes is on,
then stripslashes and apply mysql_real_escape_string. If magic quotes
is off only apply mysql_real_escape_string since php didn't escape
values for you.
Also in your mysql_real_escape_string I would suggest adding the
second parameter to your connection.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
Eric Butera schrieb:
You almost have it. What you need to do is if magic quotes is on,
then stripslashes and apply mysql_real_escape_string. If magic quotes
is off only apply mysql_real_escape_string since php didn't escape
values for you.
Also in your mysql_real_escape_string I would suggest adding the
second parameter to your connection.
Isn't that what I have? Quote:
So I modified a little:
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return mysql_real_escape_string(stripslashes($string));
}
else {
return mysql_real_escape_string($string);
}
}
if the MQ runtime is on / 1 stripslashes from string then apply
mysql_real_escape_string?
[ So the documentation is wrong?
http://ca.php.net/manual/en/function.mysql-real-escape-string.php -
Example 3. A Best Practice query ]
I will add the MySQL link identifier - cheers!
Thanks again for the help.
Regards,
Johannes
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
On 12/1/06, Johannes Lindenbaum [EMAIL PROTECTED] wrote:
Eric Butera schrieb:
You almost have it. What you need to do is if magic quotes is on,
then stripslashes and apply mysql_real_escape_string. If magic quotes
is off only apply mysql_real_escape_string since php didn't escape
values for you.
Also in your mysql_real_escape_string I would suggest adding the
second parameter to your connection.
Isn't that what I have? Quote:
So I modified a little:
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return mysql_real_escape_string(stripslashes($string));
}
else {
return mysql_real_escape_string($string);
}
}
if the MQ runtime is on / 1 stripslashes from string then apply
mysql_real_escape_string?
[ So the documentation is wrong?
http://ca.php.net/manual/en/function.mysql-real-escape-string.php -
Example 3. A Best Practice query ]
I will add the MySQL link identifier - cheers!
Thanks again for the help.
Regards,
Johannes
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Blah sorry, I saw your second example not your final code. Some
scripts I use have different database connections and because of that
it is very important to always make sure I am using the correct link
identifier.
The php best practice example checks the string to see if it is a
number. If it is there technically isn't any reason to escape because
there won't be any quotes.
Just out of curiosity how exactly are you going to put the link
identifier in your method since it is static?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
On Fri, December 1, 2006 2:32 pm, Johannes Lindenbaum wrote:
Here the smart quoting function off php.net
|function quote_smart($value)
{
// Stripslashes
if (get_magic_quotes_gpc()) {
$value = stripslashes($value);
}
// Quote if not a number or a numeric string
if (!is_numeric($value)) {
I personally would not test for is_numeric() to determine whether or
not to call mysql_real_escape_string.
I don't know UTF-8/UTF-16/Klingon well enough to know that it's going
to Do The Right Thing.
$value = ' . mysql_real_escape_string($value) . ';
I also would not attempt to add the apostrophes at this layer of
business logic, personally.
Put them into the SQL string, rather than as part of the data being
munged.
}
return $value;
}
The easier and more clear way to do what you did:
From that Idea I implemented that into my MySQL class:
public function smartQuote( $string )
{
if( get_magic_quotes_gpc() == 1 ) {
return stripslashes($string);
}
//No matter what the data is/was, and no matter about GPC on or off
//you still want to escape it for MySQL:
else {
return mysql_real_escape_string($string);
}
}
I was wondering if my above function is correct and the website's
documentation is off a little?
The function you have is correct; The documentation is correct.
Resolving those two inside your head is going to take a tiny bit more
effort on your part, but you've obviously got it to about 99% now!
Rock On!
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
Blah sorry, I saw your second example not your final code. Some scripts I use have different database connections and because of that it is very important to always make sure I am using the correct link identifier. The php best practice example checks the string to see if it is a number. If it is there technically isn't any reason to escape because there won't be any quotes. Just out of curiosity how exactly are you going to put the link identifier in your method since it is static? Hey Eric, The function standalone seems static, but it's implemented in a MySQL class I wrote. I can just add $this-connId as the link identifier And it should work no problem :) Regards, -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
Chris schrieb: That part is correct. You shouldn't need to use addslashes - use mysql_real_escape_string or mysql_escape_string depending on your (current) php version - they are both locale aware and will escape things for you depending on mysql server (re: language setup). Then just use htmlentities to display on the frontend rather than using stripslashes. Of course other db's have similar functions, check the manual. -- Sorry I sent you this email to your personal account, Chris. Morning, Just a question out of pure curiosity. Why would one prefer using mysql_real_escape_string (I'm using 5.1.6 so mysql_escape_string is deprecated). and htmlentities instead of addslashes and stripslashes? I'm going to guess the main reason is to stop SQL injections? But wouldn't add- and stripslashes do the same? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
On Thu, 2006-11-30 at 10:37 -0600, Johannes Lindenbaum wrote: Chris schrieb: That part is correct. You shouldn't need to use addslashes - use mysql_real_escape_string or mysql_escape_string depending on your (current) php version - they are both locale aware and will escape things for you depending on mysql server (re: language setup). Then just use htmlentities to display on the frontend rather than using stripslashes. Of course other db's have similar functions, check the manual. -- Sorry I sent you this email to your personal account, Chris. Morning, Just a question out of pure curiosity. Why would one prefer using mysql_real_escape_string (I'm using 5.1.6 so mysql_escape_string is deprecated). and htmlentities instead of addslashes and stripslashes? I'm going to guess the main reason is to stop SQL injections? But wouldn't add- and stripslashes do the same? addslashes() and stripslashes() are generic and don't properly take into consideration character set for the given database table. It states this explciitly int he help for mysql_real_escape_string(): Escapes special characters in the unescaped_string, taking into account the current character set of the connection so that it is safe to place it in a mysql_query(). If binary data is to be inserted, this function must be used. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
On 11/30/06, Johannes Lindenbaum [EMAIL PROTECTED] wrote: And on retrieval stripslashes(). You shouldn't have to stripslashes your data coming from the DB. Addslashes and friends exist to escape your data. It is not part of your data. So when you INSERT Jingle\'s Bells when you retrieve it you should have Jingle's Bells not Jingle\'s Bells because \ was syntax to escape the single quote. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
On Wed, November 29, 2006 11:55 pm, Johannes Lindenbaum wrote: But... magic_quotes. If my understanding is correct magic quotes will give ', and \ (for ASCII characters, e.g. \n) a preceding backslash to escape it. I also see that magic_quotes_gpc() is On by default. So all data in $_POST and $_GET etc. has escaping backslashes. Yes, but the problem is that *ALL* data in GET/POST has the escaping backslashes as if it were ASCII data, and it may *NOT* be ASCII data. It might be UTF-8. It might be UTF-16. It might be some charset you've never even heard of. And guess what? addslashes() on non-ASCII data, UTF-8 for example, is like a condom with a hole in it. If in a .htaccess I should set php_flag magic_quotes_gpc Off That would lead to $_POST data like Jingle's Bells to be passed as Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data gets written into a MySQL table to which I perform addslashes(). Switch to: http://php.net/mysql_real_escape_string And on retrieval stripslashes(). No, no, and no. You do *NOT* use stripslashes() on the data coming OUT of MySQL. Unless you've already screwed up and done BOTH addslashes() and MagicQuotes, which in essence did addslashes() twice, so you added bogus data to your database. Jingle's Bells + [magic quotes] === Jingle\'s Bells + [addslashes] === Jingle\\\'s Bells Corrupt data in MySQL: Jingle\'s Bells The whole point of this escaping is to identify characters that MySQL should store as data, rather than interpret as non-data Jingle's Bells + [magic quotes *OR* addslashes *OR* mysql_real_escape_string] = Jingle\'s Bells == Correct data in MySQL: Jingle's Bells Once you've done that correctly, what MySQL actually stores is the data, not the escapes it needed to identify the data. So if you find yourself using stripslashes() on your MySQL data to get it right, then, in reality, you've already screwed up and stored non-data as data. So go back and fix your script to NOT double-escape the input, then fix your bad data in MySQL to NOT have non-data (\ escape character) as part of your data. This is going to be a major pain, I know, but you'll only make it worse the longer you put it off. It will be a whole lot easier if you can freeze the input routines to not take anything in between the time you fix those and when you fix the data within the database... If not, you'll want to note EXACTLY which rows have corrupted extra backslashes and which do not, so you can apply stripslashes() to only the corrupt data. If I keep on doing that - and just start coding with magic_quotes_gpc Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should they? You are correct that turning off magic_quotes_gpc is a good way to prepare for PHP 6. This has been rant #53, brought to you by the character \ :-) :-) :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
Richard Lynch schrieb: On Wed, November 29, 2006 11:55 pm, Johannes Lindenbaum wrote: But... magic_quotes. If my understanding is correct magic quotes will give ', and \ (for ASCII characters, e.g. \n) a preceding backslash to escape it. I also see that magic_quotes_gpc() is On by default. So all data in $_POST and $_GET etc. has escaping backslashes. Yes, but the problem is that *ALL* data in GET/POST has the escaping backslashes as if it were ASCII data, and it may *NOT* be ASCII data. It might be UTF-8. It might be UTF-16. It might be some charset you've never even heard of. And guess what? addslashes() on non-ASCII data, UTF-8 for example, is like a condom with a hole in it. If in a .htaccess I should set php_flag magic_quotes_gpc Off That would lead to $_POST data like Jingle's Bells to be passed as Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data gets written into a MySQL table to which I perform addslashes(). Switch to: http://php.net/mysql_real_escape_string And on retrieval stripslashes(). No, no, and no. You do *NOT* use stripslashes() on the data coming OUT of MySQL. Unless you've already screwed up and done BOTH addslashes() and MagicQuotes, which in essence did addslashes() twice, so you added bogus data to your database. Jingle's Bells + [magic quotes] === Jingle\'s Bells + [addslashes] === Jingle\\\'s Bells Corrupt data in MySQL: Jingle\'s Bells The whole point of this escaping is to identify characters that MySQL should store as data, rather than interpret as non-data Jingle's Bells + [magic quotes *OR* addslashes *OR* mysql_real_escape_string] = Jingle\'s Bells == Correct data in MySQL: Jingle's Bells Once you've done that correctly, what MySQL actually stores is the data, not the escapes it needed to identify the data. So if you find yourself using stripslashes() on your MySQL data to get it right, then, in reality, you've already screwed up and stored non-data as data. So go back and fix your script to NOT double-escape the input, then fix your bad data in MySQL to NOT have non-data (\ escape character) as part of your data. This is going to be a major pain, I know, but you'll only make it worse the longer you put it off. It will be a whole lot easier if you can freeze the input routines to not take anything in between the time you fix those and when you fix the data within the database... If not, you'll want to note EXACTLY which rows have corrupted extra backslashes and which do not, so you can apply stripslashes() to only the corrupt data. If I keep on doing that - and just start coding with magic_quotes_gpc Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should they? You are correct that turning off magic_quotes_gpc is a good way to prepare for PHP 6. This has been rant #53, brought to you by the character \ :-) :-) :-) Thank you very much all of you - I know what I'm doing with my weekend. I think I was disillusioned by the fact that I had a couple Queries screw up because they were of the format (example): INSERT INTO table (text) VALUES( '.$_POST['data'].'); where $_POST['data'] was filled with something similar to Jingle's Bells (a single quote), thus screwing up the query, because it was trying to do VALUES( 'Jingle's Bells'); So by pure ignorance I just added addslashes infront of my queries. I've come a long way since then, and I'll probably just end up writing a smartQuoting function for my MySQL class that will use mysql_real_escape_string() on INSERTS so I have the correct data in my table. :) Thanks again! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
Johannes Lindenbaum wrote: Just a question out of pure curiosity. Why would one prefer using mysql_real_escape_string (I'm using 5.1.6 so mysql_escape_string is deprecated). and htmlentities instead of addslashes and stripslashes? This example might be helpful: http://shiflett.org/archive/184 It highlights the importance of character encoding consistency by demonstrating an SQL injection attack that is immune to addslashes() but not mysql_real_escape_string(). Hope that helps. Chris -- Chris Shiflett http://shiflett.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] magic_quotes
Johannes Lindenbaum wrote: Evening, I am new to this list, so please if this email is offensive to anyone I didn't know any better. Not here to start a war or similar. I have a couple questions about magic_quotes and it's deletion in PHP 6. I've been lazily following php.internals and read about register_globals and magic_quotes (finally) being deleted from PHP. I don't have any scripts that run with register_globals - not worried about PHP 6 for that case. But... magic_quotes. If my understanding is correct magic quotes will give ', and \ (for ASCII characters, e.g. \n) a preceding backslash to escape it. I also see that magic_quotes_gpc() is On by default. So all data in $_POST and $_GET etc. has escaping backslashes. If in a .htaccess I should set php_flag magic_quotes_gpc Off That would lead to $_POST data like Jingle's Bells to be passed as Jingle's Bells, not Jingle\'s Bells. Usually most of my $_POST data gets written into a MySQL table to which I perform addslashes(). And on retrieval stripslashes(). If I keep on doing that - and just start coding with magic_quotes_gpc Off - my scripts shouldn't alter behaviour upon PHP 6 arrival, should they? That part is correct. You shouldn't need to use addslashes - use mysql_real_escape_string or mysql_escape_string depending on your (current) php version - they are both locale aware and will escape things for you depending on mysql server (re: language setup). Then just use htmlentities to display on the frontend rather than using stripslashes. Of course other db's have similar functions, check the manual. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
