magic quotes + stripslashes

Involved Joined: Apr 06, 2008 Posts: 484

when creating modules is add and strip slashes only required if magic quotes is off.Or should it still be used

Posted: Sun Feb 15, 2009 8:20 pm

You should do a check to see if "magic quotes" is on and then do what is necessary.

Posted: Sun Feb 15, 2009 9:00 pm

i understand that, but what if it is off.Is there no need for add or strip slashes.

Posted: Sun Feb 15, 2009 9:35 pm

You should always do add/strip slashes. Magic_quotes_gpc is just there to automate the addslashes for get, post, and cookies.

If it is off you need to addslahes before entering into the database. You then need to stripslashes upon retrieving the data from the database. You need to strip them regardless if magic_quotes_gpc is on or off ass it only adds them.

If magic_quotes_gpc is on then you have two things to consider. One being if you are going to modify/display the data again before storing it. If you are then you have to stripslashes, modify/display, then addslashes. If you are directly storing the data then you don't have to do anything.

Remember you still have to filter your data with check_html() or what ever is approriate.

There is also magic_quotes_runtime that deals with external files and data. I doubt you are using that and it is usually off by default anyway I believe.

I don't claim to be an expert in this area so if anyone else wants to chime in Smile

Posted: Sun Feb 15, 2009 10:31 pm

Quote:

You then need to stripslashes upon retrieving the data from the database.

Actually, you don't ... as long as magic_quotes_runtime is off. addslashes is a database-escape. It is to process the correct input into the database. It is not stored in the database with slashes or anything

Posted: Sun Feb 15, 2009 11:21 pm

I was thinking about it yesterday and I thought maybe we could use a function like so

Code:




function rn_stripslashes($text)


  if (get_magic_quotes_gpc() == 1) {


    return stripslashes($text);


  } else {


    return $text;


  }


}

then replace all stripslashes, same would go for addslashes

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Here is routine I intend on submitting to the Team but just haven't had time so I will just present it here. It comes from PHP Solutions - Dynamic Web Design Made Easy by David Powers

Code:

function nukeMagicQuotes() {


  if (get_magic_quotes_gpc()) {


    function strip_slashes_deep($value) {


      $value = is_array($value) ? array_map('stripslashes_deep', $value) : stripslashes($value);


      return $value;


    }


    $_POST = array_map('stripslashes_deep', $_POST);


    $_GET = array_map('stripslashes_deep', $_GET);


    $_COOKIE = array_map('stripslashes_deep', $_COOKIE);


  }


}

The author adds

Dave Powers wrote:

The nukeMagicQuotes() function is not the ideal solution, because it involves removing the magic quotes, rather then preventing them from being inserted in the first place. However, it is the only universally applicable one. It also has the advantage that your pages will continue to run smoothly even if the server administrator decides to turn off magic quotes.

Posted: Mon Feb 16, 2009 6:33 am

testy1, just keep in mind if you are using RavenNuke(tm) that the check_html() function takes care of stripslashes if magic quotes is turned on. If the module indiscriminately does stripslashes of the input, which is what the patches do unfortunately, then it could be possible to remove some data that was intended on being there. The RN team has been talking about how to deal with what we're calling "fractured filtering" and it looks as though Raven has a nice function that could be incorporated into a final solution.

I would recommend that if you are using RN, that you don't stripslashes your input variables within your module, rather, instead always use check_html() for string input and intval() for integers. This way, as the Team works up a replacement for check_html(), they will need to account for the fact that check_html() has been the driver for string input "filtering" and will provide a good migration path to whatever is the future replacement for this.

Posted: Mon Feb 16, 2009 4:10 pm

ok that cleared it up for me, Thanks.I've been wondering about it for a while but never bothered to ask.

Posted: Mon Feb 16, 2009 7:17 pm

This is the function I've been using. Functionally, it should be equivalent to Raven's

Code:




function stripslashes_array($striparray)


{


   foreach ($striparray as $sec_key => $secvalue)


   {


      if (is_array($secvalue))


      {


         $striparray[$sec_key] = stripslashes_array($secvalue);


      } else {


         $striparray[$sec_key] = stripslashes($secvalue);


      }   


   }   


   return $striparray;


}





if (get_magic_quotes_gpc())


{


   $_GET = stripslashes_array($_GET);


   $_POST = stripslashes_array($_POST);


   $_COOKIE = stripslashes_array($_COOKIE);


}

I don't know if the callback is any more or less efficient.

Posted: Thu Apr 09, 2009 8:49 pm

@Whoever_Will_Listen, ok, so I made need further clarification here, cause Im a dummy Sad

Take the following for example

You have a module which is entirely located in the modules directory (admin side and all)

you would use the following?

Note: When I say enter an apostrophy I mean a title like so, Billybob's Title

1. inserts and selects on the user side would use check_html except where intval is applicable
2. admin side - (see 1)
3. if you enter an aposrophy and insert to db with magic quotes on you get an error.This would be fixed via FixQuotes?
4. if you enter an aposrophy and insert to db with magic quotes off you get an error.This would be fixed via FixQuotes?

Based on the above it would be best to use the following on all inserts and selects unless alternative checking is prefered e.g. intval

Code:




$title = check_html( FixQuotes( $_POST['title'], 'nohtml' ) );

Is this the best way to handle all problems?

Posted: Thu Apr 09, 2009 9:50 pm

FixQuotes isn't what I would use. It doesn't cover all cases, it's basically junk.
What I would use is addslashes (at least if you want to support compatibility with other databases). check_html unfortunately does a stripslashes in all cases

So here's what I recommend

Code:




$title = addslashes(check_html($_POST['title'], 'nohtml' ));

Posted: Thu Apr 09, 2009 10:44 pm

thanks, thats what I will do.

Posted: Fri Apr 10, 2009 7:37 am

I, too, agree with evaders' method. One caveat though: always be mindful of your use of the data. For example, unless you are going to immediately use $title ONLY within a DB call, then doing what you are doing is fine. However, I have seen even *nuke code to this addslashes() up front and then end up using the $title variable (in this example) both in a SQL call as well as later on in displaying the field to back to the browser. DOH!

Therefore, my coding style is now to create an array to hold my cleansed input variables and then I do whatever I need to do with them at the proper time. For example, when I need to use them in a SQL statement, I either addslashes() them or mysql_real_escape_string() the variables that I need. If instead I am going to post the data back to an input field within a form, I apply htmlentities() or htmlspecialchars() to it (helps in keeping from having XSS problems as well as valid XHTML). Etc., etc., etc.

Edited: just made small spelling correction.

Posted: Fri Apr 10, 2009 6:39 pm

montego wrote:

DOH!

I have no idea what your talking about, Ive never been caught with that Embarassed

EDIT: Except for today anyway

Posted: Wed Nov 04, 2009 7:11 pm

I just came across this and thought it could be beneficial to the devs.
[ Only registered users can see links on this board! Get registered or login! ]

Posted: Thu Nov 05, 2009 8:23 am

check_html() function within mainfile.php (if used properly by module code) will check to see if magic quotes were applied to the input and does the stripslashes only if they were infused by PHP. That is very interesting though about the relationship to the sybase settings. I wonder how many web hosts just leave that setting alone from default. Most hosting platforms are going to be MySQL so there should be no other dB specific settings turned on.

Thanks for showing us this. To be honest, I wish we could just force the shut off of magic quotes altogether but if we do that, poorly coded older *nuke modules could become less secure... !@#%$%^ It may be time to force the issue much like we did with the old $dbi database layer even though we provided for an easy "out" if older scripts would end up breaking their sites.

Posted: Thu Nov 05, 2009 5:01 pm

montego wrote:

To be honest, I wish we could just force the shut off of magic quotes altogether

sometimes people need a push to help themselves Wink

I think it's time to push towards php 5 only and even as far as coding towards 6 as I have tried php6 with rn24 and it seems like it's going to be a big job Sad

Posted: Mon Nov 09, 2009 11:15 pm

I'm thinking of just taking the core and rewriting it to fit PHP 6, fix the filtering, etc. No more legacy stuff, but it will take some developers who are interested Smile

Posted: Tue Nov 10, 2009 6:57 am

If you are talking about an effort to fix the RN core as such, you'd have quite a few on board. If you are talking only from a PHP-Nuke core standpoint, not so sure...

Posted: Tue Nov 10, 2009 3:58 pm

evaders99 wrote:

I'm thinking of just taking the core and rewriting it to fit PHP 6, fix the filtering, etc. No more legacy stuff, but it will take some developers who are interested Smile

I have an advanced diploma in being someone's biatch.Give me a job to do Smile

Regular Joined: Oct 28, 2004 Posts: 84

well personally this should not be used at all php is changing to and 5.3 already disables this 6.0.Dev already removed this so its better to either not rely on the function but rather disable it runtime from your script and either use mysql_real_escape_string or addslashes for database objects i've been workign on my own cms now for about 2 years but this is how i delth with the issue

Code:




   /**


    * Add slashes to the text if magic_quotes_gpc is turned off.


    *


    * @param   string  $text


    * @return  string


    **/


   public function add_slashes($text)


   {


      return ( get_magic_quotes_gpc() ? $text : addslashes( $text ) );


   }


   /*


   * if magic_quotes_gpc is on, stirip back slashes


    *


    * @param   string  $text


    *


    * @return   string


   */


   public function strip_slashes($text)


   {


      return ( get_magic_quotes_gpc() ? stripslashes($text) : $text );


   }

Steve

Posted: Sat Jan 23, 2010 11:45 pm

evaders99 wrote:

I'm thinking of just taking the core and rewriting it to fit PHP 6, fix the filtering, etc. No more legacy stuff, but it will take some developers who are interested Smile

@evaders99 maybe its better too to remove register globals ie $_GET['login'] rather then $login etc for example use super globals on the whole nuke system, can be done without breaking anything just takes someone who actually has time on there hands

Steve Smile

Posted: Sun Jan 24, 2010 10:34 am

perfect-games wrote:

can be done without breaking anything just takes someone who actually has time on there hands

Yes, it could be done on the core of *nuke, but many add-ons would break, so there are trade-offs to consider. I completely agree, though, that it would tighten up a bit on security.

But, then again, if a coder does his/her job right, it doesn't matter if they are global or not, so we're having to compensate all over the place (ala: NukeSentinel) for poor coding.

Posted: Mon Jan 25, 2010 10:39 pm

well technically FB no longer runs nuke, and the guy that runs it now has not given us anything so guess someone needs to fork it as nuke is on its last legs
the reason i don't do anything with nuke anymore as its constant security issues so i just thought i right my own taken me a while due to RL with kids / scripting for real money but think i almost got it where i want the public to see it, but im sure raven and team should do the same with nuke before its completely dead
that's just my 2 cents

Steve Smile