Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke
Author Message
spottedhog
Regular
Regular


Joined: Jun 02, 2004
Posts: 88

PostPosted: Thu Aug 31, 2006 8:11 am Reply with quote

Coding Standards is more what I'm going for. How do we filter variables? Do we use some pre-existing setup or make our own.


This is the discussion.

- Evaders99


----------------------------------------------------


Maybe a better catch phrase to use here is "Best Practices", which may get groans, but it is what it is.

Sure, time-tested and safe input filtering can be used, but a part of that is making filtering code available to 3rd party modules, etc. In other words, why stop at the core offerings?

I guess what I am thinking is that there are only so many types of inputs, like:
-text that includes html
-text without html which could also have many variation filters
-numeric only strings which could show how to modify the filter to fit the application

For example:
For application titles/categories one could use what is used now:

--$title = addslashes(check_words(check_html($title, "nohtml")));

OR maybe this:
--$title = mysql_real_escape_string(check_words(check_html($title, "nohtml")));

OR maybe this:
--$title = escape_string(check_words(check_html($title, "nohtml")));

(where "escape_string" is a function that could detect magic_quotes, stripslashes, does something else, then does the mysql_real_escape_string thing....) For example:

Code:


function escape_string($value) {
    // Stripslashes if magic_quotes_gpc is on
    if (get_magic_quotes_gpc()) {
        $value = stripslashes($value);
    }
    // Check php version
    if(version_compare(phpversion(),"4.3.0")=="-1") {
    // Quote if not integer
    if (!is_numeric($value) || $value[0] == '0') {
       $value = "'" . mysql_escape_string($value) . "'";
    } else {
    // Quote if not integer
    if (!is_numeric($value) || $value[0] == '0') {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
  }


OR maybe this:
--$title = escape_string(check_words(htmlspecialchars($title)));

so html could be displayed but not active.

OR maybe something with strip_tags in it...

Maybe a new function could be created for modules like FAQ and Tutorials, something like this so you can still have paragraph, line break, italics, and bold formatting:

Code:


function format_tags($string){
   $replaced_string = htmlspecialchars($string);
   $replaced_string = str_ireplace('&lt;p&gt;','<p>',$replaced_string);
   $replaced_string = str_ireplace('&lt;/p&gt;','</p>',$replaced_string);
   $replaced_string = str_ireplace('&lt;br /&gt;','<br />',$replaced_string);
   $replaced_string = str_ireplace('&lti;&gt;','<i>',$replaced_string);
   $replaced_string = str_ireplace('&lt;/i&gt;','</i>',$replaced_string);
   $replaced_string = str_ireplace('&lt;b&gt;','<b>',$replaced_string);
   $replaced_string = str_ireplace('&lt;/b&gt;','</b>',$replaced_string);
   return $replaced_string;
}


The above could maybe be written better like this:

Code:


strip_tags($text, '<p><br /><i><b>');


OR, maybe something could be done to be able to use the u__nion and s__cript words instead of having them blocked out. Maybe something like this:

Code:


function keep_words($string){
   $string = str_ireplace('union','un&#105_on',$string);
   $string = str_ireplace('script','scr&#105_pt',$string);
   $string = str_ireplace('body','b&#111_dy',$string);
return $string;
}

---the underscore needs to be replaced with a semi-colon  ;


(in the above function I placed the HTML Alphabet substitute for the letter "i" which is: &#105 in the un__ion and scr__ipt words and &#111 for the o in b__ody)


I guess what I am saying is that one can filter, but maybe it can be taken a step further and "filter with a desired outcome".

Maybe it is best to use htmlspecialchars() for those who would like to display something in a category or title like this:

Code:


Working with <p> tags


In the patch files, there are many things filtered out that could safely be put back in replacing characters with HTML Alphabet and other ways. When everything is filtered out, it limits the application when it does not have to. Heck, one cannot list a link to this site without having to manually do something. Wink

I know.... long winded reply..... just saying this issue may be more involved than one may originally consider.
 
View user's profile Send private message Visit poster's website
technocrat
Life Cycles Becoming CPU Cycles


Joined: Jul 07, 2005
Posts: 511

PostPosted: Thu Aug 31, 2006 9:28 am Reply with quote

Here is my 2 cents. First if magic quotes are on, I think you should undo it. It doesnt work which is why its being removed in php 6. It really just makes more trouble than its worth.

Then either use mysql_real_escape_string or something along those lines. ADODB has a nice function for it. So do many other coders. Its not a new concept and many people have come up with good scripts to manage it.

For actual html filtering there are many good places to get scripts that have been well tested and polished. Which is why I question reinventing everything.
Only registered users can see links on this board! Get registered or login! Only registered users can see links on this board! Get registered or login! Only registered users can see links on this board! Get registered or login!

I am sure there is more.

For security filtering its pretty easy.
1) Remove/convert any html, ascii, etc code.
2) Remove any spaces more than one
3) Look for things that do not belong

Here is some regex code that I am working on for Evo v3. Its still not done but it should give you the basic ideas.
Code:
define('REGEX_UNION','#\w?\s?union\s?\w*?\s?(select|all|distinct|insert|update|drop|delete)#is');

define('REGEX_XSS_HTML','#http:\/\/.*#is');
define('REGEX_XSS_DOT','#\.\/#i');
define('REGEX_STRIP_SPACES','/\s{1,}/');
define('REGEX_STRIP_COMMENTS','/\s?\/\s?\*\s*?\w*?\s*?\*\s?\/\s?/i');

_________________
Only registered users can see links on this board! Get registered or login!
Only registered users can see links on this board! Get registered or login! / Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message
Guardian2003
Site Admin


Joined: Aug 28, 2003
Posts: 6793
Location: Ha Noi, Viet Nam

PostPosted: Thu Aug 31, 2006 11:01 am Reply with quote

Personally, I would prefer to see all input and other security related filtering held in a class file - am I wrong in thinking that if the code is held in one file, it is much easier to maintain and update than having to tweak every file where filtering is currently used?
 
View user's profile Send private message Send e-mail
evaders99
Former Moderator in Good Standing


Joined: Apr 30, 2004
Posts: 3221

PostPosted: Thu Aug 31, 2006 11:21 am Reply with quote

Raises some good points. Are we going for a generic filter function? There are many cases to cover. A class file may work better for that.

Does bring up a good issue with uni0n and s_cript code that we would want to fix too. We would need to differentiate between HTML and non-HTML content, content for forms, database validation, and others.


Here's a question:

1) Does the database need to be filtered from? Security books would say yes... treat it as a source of input and validate it. Layers of security.

2) In such cases, do we want to check_html tags on it? I know that Patched files have added a lot of checks where there were none previously. It has some concerns that the scripts are removing "features" that were there before. Even for admin scripts. I know there was some concern that admins should be allowed to add any code. If admins have some kind of backdoor, that would go against having the layer of security in the first place.

3) Is there a way to bypass some validations? Maybe some kind of prompt with a password... ala "you need admin permissions to submit this kind of code"? Or would that not be effective?
Perhaps even some way for the admin to say ... "yes I want to use HTML in this field, but not in that field?"

_________________
- Only registered users can see links on this board! Get registered or login! -

Need help? Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6383

PostPosted: Thu Aug 31, 2006 11:31 am Reply with quote

Just to remind everyone of similar discussion, enjoy Only registered users can see links on this board! Get registered or login!.

You might also enjoy this Only registered users can see links on this board! Get registered or login!. It's almost a year old, but I doubt these tools have changed that significantly. At the time, I liked cyberai best. But, I had already done so much with kses that it didn't make sense to reinvent that wheel.

As to where to use it...that's an interesting discussion for sure.

_________________
I google, therefore I exist...
Only registered users can see links on this board! Get registered or login!
 
View user's profile Send private message
kguske
PostPosted: Thu Aug 31, 2006 11:45 am Reply with quote

Well, the author of HTML Purifier sure is humble...not! I do like the explanations and roadmap... I wish I had time to look at this more closely!
 
spottedhog
PostPosted: Thu Aug 31, 2006 4:55 pm Reply with quote

Here is a link to an Input Filter class system:
Only registered users can see links on this board! Get registered or login!

You can download it from the Resources drop down box.

Part of the filtering includes these 3 functions:

Code:


   function safeSQL($source, &$connection) {
      // clean all elements in this array
      if (is_array($source)) {
         foreach($source as $key => $value)
            // filter element for SQL injection
            if (is_string($value)) $source[$key] = $this->quoteSmart($this->decode($value), $connection);
         return $source;
      // clean this string
      } else if (is_string($source)) {
         // filter source for SQL injection
         if (is_string($source)) return $this->quoteSmart($this->decode($source), $connection);
      // return parameter as given
      } else return $source;   
   }


   function quoteSmart($source, &$connection) {
      // strip slashes
      if (get_magic_quotes_gpc()) $source = stripslashes($source);
      // quote both numeric and text
      $source = $this->escapeString($source, $connection);
      return $source;
   }
   

   function escapeString($string, &$connection) {
      // depreciated function
      if (version_compare(phpversion(),"4.3.0", "<")) mysql_escape_string($string);
      // current function
      else mysql_real_escape_string($string);
      return $string;
   }


Also includes some tag filtering that helps with XHTML validation.

evaders..... You have probably looked at this code, but if not, please take a look at it. This may have all that is needed.

By using this code package, one may be able to remove many functions now in mainfile.php like, check_html() and FixQuote() and probably the $_POST and $_GET code.

$AllowableHTML could be put into an array in InputFilter().

htmlspecialchars() could be used on top of the safeSQL() when the input does not allow html.

quoteSmart() could be used to escape all outputs.

And like Guardian suggested, the wheel is not reinvented and all the filtering code is in one file.

Thank you Guardian for the link.... this package has strong merit IMHO.
 
montego
Site Admin


Joined: Aug 29, 2004
Posts: 9456
Location: Arizona

PostPosted: Fri Sep 01, 2006 9:30 am Reply with quote

Regarding Filtering of DB Data (used as an input):

I am really torn on this one. If it was entirely my own script or a CMS where NO code can be added, I would NOT filter data from the DB. As an admin of my site, I should be allowed to use whatever HTML/CSS/JS/ETC code that I want in my forms that will produce the desired output. Unfortunately, if that stuff is screened out prior to being echo'd back, I have lost all of that! This is my biggest "beaf" with nuke and the patches.

But, I am fully aware of the "rub": we could strip all that out for the core PHP-Nuke and have my "nirvana", but all it takes is for one webmaster to not be careful with what add-on they install, and trouble begins...

Unfortunately, the only solution that I can think of is one that is quite "non-core nuke". It would involve marking all records with a flag to say "was this inserted by an Admin". If so, don't filter it. One would either have to add a field to many core nuke tables, or create a separate table that is used to validate whether the particular data element came from the admin vs. a regular user.

<sigh>

Any better ideas?

_________________
Only registered users can see links on this board! Get registered or login!
Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
montego
PostPosted: Fri Sep 01, 2006 9:42 am Reply with quote

Regarding Data Filtering:

With this, all I have to caution folks on is that what kind of filtering is done is dependent upon how the data is used; therefore, whatever filtering class is used, it must be flexible enough to hande these various uses and we should also not force filter everything right up front.

Consider the example of the nuke Submit News feature. The user fills in his HTML and article text into the textarea form field and clicks on Preview. Now, let us say that the filtering "class" blingly did an htmlentities on the incoming POST variable. The Preview of that data would NOT work. It would not show to the end-user what it was supposed to show. However, using htmlentities on the variable for the Form field to present the data back so it can be edited, is what should be done.

Therefore, the filtering needs to be flexible for its use OR we "filter" but not "prepare" the data. What I mean by this is that we separate filtering from preparing the data for use.

In the above example, we can most definitely filter the incoming POST variable for invalid HTML, XSS, etc., and that filtering is valid regardless of how the variable is subsequently used. Then, separate the "prepare" part as follows:

1) If rendered back in HTML, just use the already filtered input

2) If going back to a form object, use htmlentities on it.

3) If going back to the DB, make sure its propertly escaped.

Anyways, enough for now... gotta start thinking about getting my butt into work.
 
technocrat
PostPosted: Fri Sep 01, 2006 10:47 am Reply with quote

I like cyberai, its what we have used in Evo 1.0.x and 2, but I am probably going to stop using it. For starters the project has gone stale. I submitted a number of fixes, changes and suggestions to the author over a year ago. Never got any response. It has not been upgraded either. So I think that project is mostly dead. Sad

I think what we really need is 3 class functions.

1) Validates input. Check to make sure if its supposed to be a number it is a numer. Plus lengths and any other type checking.
2) HTML filtering & validation. Is HTML allowed for that field. If so what can be used. Filter out the stuff that doesnt belong.
3) Security filtering. Filter out Unions, XSS, and CMD attacks. Plus anything else you can think of.
 
montego
PostPosted: Sat Sep 02, 2006 10:08 am Reply with quote

technocrat, I like your summary. In 1) It could also allow for things like email address filtering. With 2), what are your thoughts on the kses filtering? Regarding 3), would we really need to filter on Unions if we solve the "db escaping" problem identified in Evader's other thread?

Love the brainstorming... this is great stuff.

Then, again, what about all those other add-ons? Any thoughts there? I could be possible to modify the PHP-Nuke sorry excuse for filter functions to be "stubs" which call the new class(es), but, unfortunately, without knowing how the authors are really using the variables post-filtering, could get unexpected results?
 
Guardian2003
PostPosted: Sat Sep 02, 2006 10:54 am Reply with quote

Then third party authors need to update their stuff or lose out - I guess this brings us back to another post on 'certifying' third party stuff.
OR for backward compatibility, have some sort of 'switch' so for example in a third party script you could just add a one line constant declaration to invoke the 'old' filter function instead of using it as a stub?
<Out of my depth here and winging it a lot>
 
montego
PostPosted: Sat Sep 02, 2006 11:08 am Reply with quote

Problem is, Guardian, that WE end up having to deal with all the questions here in the forums... it gets a bit old supporting crap that hasn't been updated in years upon years upon years. Sad
 
kguske
PostPosted: Sat Sep 02, 2006 11:50 am Reply with quote

Basically, we modified the standard check_html function to use kses to support WYSIWYG editing. We could build on that and use a modern class like HTML Purifier. We could add defaulted parameters to let new or updated applications take advantage of different features (like the ones Technocrat mentioned) while still providing support for the old stuff (but with better filtering, of course!).
 
technocrat
PostPosted: Sat Sep 02, 2006 12:06 pm Reply with quote

As always there is a million ways to do something. You can always take one that has gone stale and build on it. Its what is nice about GPL and other open source projects. But something has to be done for standard nuke users. Its a big time problem.

But in many ways it is kind of like putting a bandaid on a bullet wound, it only kind of stops the bleeding. With FB code there are so many problems and holes it is really not fixing the underlying issues. Which brings back to the age old discussions about forking or restarts.

I have started laying out ideas for the next version of Evo to go away from FB's code entirely. For my project I plan a restart with backwards compatibility. Bring code standards and programming form to what it should have been. Also use class types for as much as possible.

Me personally I am not going to do any php projects without using classes. OOP is really the way to go. Maybe that's because in real life I am C++ programmer and all my programs are reusable class types. So that is not going to carry over to php.

These are just my thoughts.
 
Gremmie
Former Moderator in Good Standing


Joined: Apr 06, 2006
Posts: 2415
Location: Iowa, USA

PostPosted: Sat Sep 02, 2006 1:49 pm Reply with quote

technocrat, I am also a C++ programmer and love the OOP paradigm. However, I have been reluctant to do it in PHP because apparently the PHP object model was greatly reworked for PHP5. So there would be no point in doing OOP in PHP4, and PHP5 is not widely available on hosts that I have surveyed. Can you do OOP PHP5 style and be somewhat backwards compatible with PHP4?

_________________
Only registered users can see links on this board! Get registered or login! - An Event Calendar for PHP-Nuke
Only registered users can see links on this board! Get registered or login! - A Google Maps Nuke Module 
View user's profile Send private message
technocrat
PostPosted: Tue Sep 05, 2006 11:42 am Reply with quote

It is true you cannot do somethings with 4 as you can with 5, but that does not mean you cannot start the ground work with classes. Everything has to start some where and until php 5 is out there more you are limited. But why not get started on the future.
 
fkelly
Former Moderator in Good Standing


Joined: Aug 30, 2005
Posts: 3312
Location: near Albany NY

PostPosted: Tue Sep 05, 2006 2:31 pm Reply with quote

I'd like to step back a few posts to something Montego said:

Quote:
Consider the example of the nuke Submit News feature. The user fills in his HTML and article text into the textarea form field and clicks on Preview. Now, let us say that the filtering "class" blingly did an htmlentities on the incoming POST variable. The Preview of that data would NOT work. It would not show to the end-user what it was supposed to show. However, using htmlentities on the variable for the Form field to present the data back so it can be edited, is what should be done.


Why would you not want to do an htmlentities on the previewed data before showing it back to the user? That's precisely what's going to happen to the data when he/she stores it and that's how it will be displayed thereafter. So a preview should show it that way.

Only thing is that htmlentities is too broad a brush if we want to allow bolding or italics without allowing scripting. But let's say we have a filter class with agreed upon functions that allow some html (humm allowablehtml?) without allowing hackers to have their way. Wouldn't we want to apply it to any textarea element or really to any input element, preview or not?

The other thing I think we need to work out is how this all ties into Sentinel. If the wysiwyg editor has already filtered an input and says it's okay, do we really want Sentinel re-filtering it and in some cases banning it and the user? I think 64bitguy used the phrase "fractured filtering" to describe this approach. Could we work with the Sentinel authors to pass it an "already_validated" flag for certain input to just let it pass?
 
View user's profile Send private message Visit poster's website
spottedhog
PostPosted: Tue Sep 05, 2006 7:59 pm Reply with quote

Smile I wondered when Sentinel would be brought up....

Will all of Sentinel be needed if there is input filtering and proper escaping?

...interesting thoughts ahead.....
 
montego
PostPosted: Tue Sep 05, 2006 10:42 pm Reply with quote

Quote:

Why would you not want to do an htmlentities on the previewed data before showing it back to the user? That's precisely what's going to happen to the data when he/she stores it and that's how it will be displayed thereafter. So a preview should show it that way.

Try it and you will see what I mean! Remember that I am talking about the "preview" which is basically echo'ing it straight out as "html" to the browser...

There is a thread that 64bitguy started long back about this... too tired to find it now... Would be worth a read too for all of us. He brought up some really good points. He was even deadset against htmlentities, but instead, using htmlspecialchars.
 
kguske
PostPosted: Wed Sep 06, 2006 10:52 am Reply with quote

Here's another detailed, though less objective, Only registered users can see links on this board! Get registered or login!. It doesn't address when to filter - that's left up to us.

As with similar discussions on the evolution of PHP-Nuke, I'd prefer an approach that leverages existing modules, addons, etc. to the extent that it can. I hear your point, Montego, about supporting them. But the alternative is what? To rewrite them? Maybe the out of date stuff isn't worth bringing forward... I definitely think it's worth further investigation, including a review of Steph's Only registered users can see links on this board! Get registered or login!.
 
evaders99
PostPosted: Wed Sep 06, 2006 1:00 pm Reply with quote

So we need a seperate HTML filter for admins and users? And perhaps even an option to disable the filter...



On a slightly different tangent, perhaps we should talk about variable validation by type.
Is this an integer?
A valid date?
A URL?
A file path?
Even to go and define certain formats like the email one that was added in the Patched files.

Do we keep some of the alphanumeric checks in place? Or can we allow non-alphanumeric characters, esp for foreign languages?
 
kguske
PostPosted: Wed Sep 06, 2006 8:39 pm Reply with quote

That was one of Steph's points - why are we validating / filtering integers as if they were HTML?

Not sure we need separate filters, but possibly less restrictive filters for admins than for users. Or, filter by function. For example, when maintaining a block, allow js, since it might be appropriate there and only an admin has the access. But don't allow it in a forum post or new story.
 
montego
PostPosted: Thu Sep 07, 2006 6:55 am Reply with quote

All excellent points... love this stuff... But I want to "key" on this item here:

Quote:

So we need a seperate HTML filter for admins and users? And perhaps even an option to disable the filter...

Have we settled then on NOT filtering data coming from MySQL? Although that is my preference from a core nuke standpoint that we can control via the patch series... that is the only way this method would work. But, for us admins, I honestly believe this is a must... who wants to have to do their editing in phpMyAdmin? Sad

You can avoid filtering for an admin on the way in... but you would also have to avoid filtering on the way out from the DB. Like I said somewhere else, the only way I can think to do this -- if filtering DB data is still deemed as required -- is to know the "source" of the original DB data. If it came from an Admin, trust it, if it did not, don't trust it and filter it as appropriate.

Off the top of my head I can think of a few ways to potentially accomplish this:


    1. Keep a separate table which "points" (this is in object-relational terminology) to the data element in question and its source (i.e., "trusted"). It is possible that we would only have to mark those data elements which came from the admin.

    2. Another option might be to add a flag to every "desired" core nuke table to set if the source is "trusted" (Yuk!)

    3. Another option might be to somehow embed with a given text field a "token" and somehow compare it to something else to determine if the data is "trusted" or not. (I have no idea how to do this right now... just brainstorming.)


I really think the issue of "Do we filter DB data coming in as input" is one of the truelly fundamental issues that needs to be addressed. And, it may even have to come down to where we apply this approach. As kguske mentions a few posts back, add-ons vs. core PHP-Nuke. Need to maintain as much compatibility as possible (BTW, that is what I was also getting at with my "stubs" comment...)

kguske, thanks for finding Steph's original thread! It is great to have it here for reference. Everyone should read and re-read and re-read that... including me!
 
spottedhog
PostPosted: Sun Sep 24, 2006 5:24 pm Reply with quote

***EDITED***

Discussion seems to have stopped for a bit, so I will bring up some things to consider....

Here is what I am now doing for my nuke fork:

I have replaced all the addslashes, stripslashes, htmlentities, and check_html in all the module ModuleName/index.php files and the admin/index.php files. I replaced it with this ever so slightly modified InputFilter code. I will list the entire code in a file link below. This InputFilter code removes nasty XSS, specific html tags, and prevents SQL injection by escaping data after checking if magic_quotes_gpc is on or off.

It also places closing tags on tags like:
Code:
<br> or <hr> to make <br /> and <hr />

so inputs can pass XHTML Strict compliance. InputFilter will also strip capitalized html tags to lower case, again for making the inputs pass XHTML Strict compliance.

Here is how to use the InputFilter system:

Create the php files with the corresponding names and upload them to the includes folder.

Next, in mainfile.php place these 2 lines:

Code:
@require_once("includes/class.inputfilter.php");

@require_once("includes/class.nohtmlinputfilter.php");


Now in the file where you wish to filter/escape the data, just below the global line of a function place these 2 lines:

Code:
$myFilter = new InputFilter();

$my_nohtmlFilter = new nohtmlInputFilter();

You will need to place these lines in EVERY function where you wish to use it.

OK.... For functions that are used for creating or editing data, I have initialized the variable by placing the variable just under the $myFilter lines from above. For example, in the Content/admin/index.php file I have done this in the function edit_category:

Code:
$title = array();

$description = array();

DO NOT INITIALIZE VARIABLES IN FUNCTIONS THAT SAVE DATA TO THE DATABASE. This would be places where you would see this for example:

Code:
function content_save($title, $subtitle, $page_header, $text, $page_footer, $signature, $clanguage, $active, $cid) {

    global $prefix, $db, $admin_file;
$myFilter = new InputFilter();
$my_nohtmlFilter = new nohtmlInputFilter();
    $text = $myFilter->safeSQL($myFilter->process($text));
    $title = $my_nohtmlFilter->nohtmlsafeSQL($my_nohtmlFilter->nohtmlprocess($title));
    $subtitle = $my_nohtmlFilter->nohtmlsafeSQL($my_nohtmlFilter->nohtmlprocess($subtitle));
    $db->sql_query("insert into ".$prefix."_pages values (NULL, '$cid', '$title', '$subtitle', '$active', '$page_header', '$text', '$page_footer', '$signature', now(), '0', '$clanguage')");
    Header("Location: ".$admin_file.".php?op=content");
}

Please note that the variables coming into this function should already have a string in them and therefore do NOT need to be initialized.

Now for filtering/escaping of data, the places where a data variable is known... For the $title and $description I have placed this:

Code:
$title = $my_nohtmlFilter->nohtmlsafeSQL($my_nohtmlFilter->nohtmlprocess($title));

$description = $myFilter->safeSQL($myFilter->process($description));


OK.... You probably noticed that one line has "nohtml" in the string name. The one that does NOT have nohtml in it has the allowed html tags in its tag array. And vice versa...

Sooo, for the examples above, since you do not want html tags in the Title, you would use the code that removes all html tags. And for the Description, only those html tags listed in the allow tags array can be displayed/saved in that data file.

It may be best to only escape data coming from the database in functions that edit or display data. Here is a function that could be placed in the mainfile.php:
Code:
function escape_string($value) {


    // Stripslashes
    if (get_magic_quotes_gpc()) {
        $value = stripslashes($value);
    }
    // Quote if not integer
    if (!is_numeric($value) || $value[0] == '0') {
        $value = mysql_real_escape_string($value);
    }
    return $value;
}





Maybe I am crazy, but I saw a big advantage of using this system versus using addslashes, stripslashes, check_html, and htmlentities. One thing I saw was that the InputFilter system actually removes not allowed html from the data input, whereas something like htmlentities just renames certain characters.

Here is the code for the 2 InputFilter files:
Only registered users can see links on this board! Get registered or login!

---had to place the code there since the forums would not allow some words..... Sad

The PHP Security gurus say to:
-Initial Variables
-Filter Inputs
-Escape Outputs

So to that end, the method and code from above does this, or at least it appears to.

There was a short discussion on the need to have one filter for Admins and one for Users. I just do not see that need. IMHO there are 3 types of database inputs in Nuke.

1. Integers
2. Text with html tags
3. Text without html tags

For the Integer fields, intval() can be used to filter.
The text data can use the appropriate InputFilter file to filter/escape data.

For me, the only issue is on whether to let Admins to use whatever words they want in their inputs, or to check_words for all text inputs. I decided Admins can make the choice, however, I am checking all words from User inputs.

I am submitting this for others to possibly use for their own use. For me, the system seems excellent because of ensuring proper data is entered and maintained in the data field. And I think it also keeps data safe for outputting to a web browser.

Summary:

In functions where data is edited or displayed to a web browser, first initialize the data variable to an empty array, for example like this:
Code:
$mytitle = array();

Then escape the data coming from a sql query to the empty array data variable, for example like this:
Code:
$mytitle = escape_string($mypages['title']);


In functions where the data is saved, filter/escape the data before saving it to the database, for example like this:
Code:
$title = $my_nohtmlFilter->nohtmlsafeSQL($my_nohtmlFilter->nohtmlprocess($title));


This approach should secure the data with no real overhead, except when saving data, which in proportion, is minimal at best.

This approach would allow for deleting these functions from mainfile.php:

filterQuote
delQuote
check_html

Lastly, this could be a standardized or "Best Practices" way of filtering/escaping both primary and 3rd party modules.


Last edited by spottedhog on Mon Sep 25, 2006 6:52 am; edited 2 times in total 
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - PHP Nuke

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©