Modification suggestions and queries

Posted: Mon Oct 24, 2005 11:24 am

Hi

First, I still have an important issue open in this forum and so if anyone is in the know, please feel free to check that one out as I think that it is very important relative to Textarea related fields.

I am posting this new thread relative to some things I recently said to Technocrat and others running patched relative to the use of "if exists"

First, let me come right out and say that I have issues with the way that NukeSentinel is included and called by the mainfile.php. My major concern in this regard is that it does a "if exists" at least twice in the basic mainfile filtering code and my thought at this point is that it shouldn't do that at all.

In fact, IMHO I believe that inclusion of NukeSentinel should mean that it should completely replace the function calls that currently exist in the mainfile and that those mainfile checks should simply be totally removed.

Let me document what I mean.
The first time it gets called is in the Union tap function:

Code:

if(!file_exists('includes/nukesentinel.php')) {


  unset($matches);


  unset($loc);


  if(isset($_SERVER['QUERY_STRING'])) {


    if (preg_match("/([OdWo5NIbpuU4V2iJT0n]{5}) /", rawurldecode($loc=$_SERVER['QUERY_STRING']), $matches)) {


      die('Illegal Operation');


    }


  }


}

Now first things first. Please note HOW NukeSentinel gets called. If in fact you have installed NukeSentinel, you should never have a "If(!file_exists" type call, simply because you KNOW it exists. If you know it is there, there is no reason to add additional latency (which each one of these calls does).

Next, you find another call to it at:

Code:

// Additional security (Union, CLike, XSS)


if(!file_exists('includes/nukesentinel.php')) {


  if(isset($_SERVER['QUERY_STRING']) && (!stripos_clone($_SERVER['QUERY_STRING'], "ad_click") || !stripos_clone($_SERVER['QUERY_STRING'], "url"))) {


    $queryString = $_SERVER['QUERY_STRING'];


    if (stripos_clone($queryString,'%20union%20') OR stripos_clone($queryString,'/*') OR stripos_clone($queryString,'*/union/*') OR stripos_clone($queryString,'c2nyaxb0') OR stripos_clone($queryString,'+union+') OR stripos_clone($queryString,'http://') OR (stripos_clone($queryString,'cmd=') AND !stripos_clone($queryString,'&cmd')) OR (stripos_clone($queryString,'exec') AND !stripos_clone($queryString,'execu')) OR stripos_clone($queryString,'concat')) {


      die('Illegal Operation');


    }


  }


}


$postString = "";


foreach ($_POST as $postkey => $postvalue) {


    if ($postString > "") {


     $postString .= "&".$postkey."=".$postvalue;


    } else {


     $postString .= $postkey."=".$postvalue;


    }


}


str_replace("%09", "%20", $postString);


$postString_64 = base64_decode($postString);


if (stripos_clone($postString,'%20union%20') OR stripos_clone($postString,'*/union/*') OR stripos_clone($postString,' union ') OR stripos_clone($postString_64,'%20union%20') OR stripos_clone($postString_64,'*/union/*') OR stripos_clone($postString_64,' union ') OR stripos_clone($postString_64,'+union+')) {


header("Location: index.php");


die();


}

Now, once again we have done the same thing. We've said, "If (!file_exists" Why, I have no idea.... I mean why bother to add a latency expanding call twice? If it existed .5 seconds ago, chances are pretty good that it exists now, but again, if you've loaded NukeSentinel, you KNOW it exists so there is no real reason to ask in the firstplace.

But wait, there's more!:

Code:

if (!defined('ADMIN_FILE') && (!defined('PHPBB') && !file_exists('includes/nukesentinel.php'))) {


  foreach ($_GET as $sec_key => $secvalue) {


    if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*body*\"?[^>]*>", $secvalue)) ||


   (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


   (eregi("\"", $secvalue)) ||


   (eregi("forum_admin", $sec_key)) ||


   (eregi("inside_mod", $sec_key))) {


        die ($htmltags);


     }


  }





  foreach ($_POST as $secvalue) {


    if ((eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) || (eregi("<[^>]script*\"?[^>]*>", $secvalue)) || (eregi("<[^>]*body*\"?[^>]*>", $secvalue)) || (eregi("<[^>]style*\"?[^>]*>", $secvalue))) {


      die ($htmltags);


    }


  }


}

Okay, so now we've asked 3 times!

Now I know in the beginning, we needed this because many of us were simply testing NukeSentinel, but I think the time has come where these functions be actually DEFINED as functions and called in a single place.

Meaning, if you don't have NukeSentinel, they each exist as mainfile defined function(); call.

However, if you have NukeSentinel, they should simply be removed from the mainfile entirely and called via a single NukeSentinel "include"

Thus, you would delete all of this code from your mainfile and simply add at the top of your mainfile:
include(includes/NukeSentinel.php); and that would be the end of it, meaning NukeSentinel would now "take over" the management of these "functions" from the mainfile.

I say this because on top of asking for NukeSentinel 3 times on every single query, there is no logical reason to have the function calls existing twice (once in NukeSentinel and again in the mainfile) but more-over, there is no logical reason to add latency by having the mainfile ask 3 times if NukeSentinel exists or not, especially since you KNOW it exists.... Thus, there is no logical reason to ask at all! It simply slows everything down.

I have also said before that as more filtering methodologies are employed, they should exist in the NukeSentinel include. I say this because if you are using NukeSentinel's include to scan GET and POST for abuse, you probably should also manage the analysis of the content included in that process in the same "include".

Thus, in my particular scenario, I am trying to do XSS filtering and check_html/fixquote/stripslashes/htmlentities management in the same process which seems to really help performance.

The reason being is the data broken out (once in mainfile / once in NukeSentinel) must make the trip twice. First it must check the query against NukeSentinel, then it must manipulate the data in Mainfile. By moving all of these functions to NukeSentinel, we are actually consolidating all data get and post functions into a single pass. We check the function of the query, the query itself and the HTML for forbidden tags and then in that same process we check the content (data) for structure, forbidden words and formatting.

The bottom line is that by streamlining the order (data manipulation first, query manipulation and filtering last) and by consolidating the functions into a single include, we really boost performance and eliminate unneccessarily wasting resources on every single page load. Presently these 3 "if(file_exist" queries on every single page reduce performance by at least 10%.

Finally, anyone reading this... this isn't a critique of the current methods or an attack, but rather I'm saying that we started off this way for a reason in the beginning when NukeSentinel was an emerging solution. Now that it has proven itself, I think it's time to address these issues from an optimization perspective.

Thoughts?

Thanks
Steph

Posted: Mon Oct 24, 2005 1:50 pm

If you loaded NukeSentinel, key words, if it does in fact exist within the install then of course it will exist for the second filtering block of code, but what if it doesn't? should we leave the file wide open to the countless copy / paste losers that roam the net in look of something to do with their otherwise pathetic lives? i think not, If FB were to include NukeSentinel within Nuke's core i would not even bother with any filtering at all, but he doesn't and i doubt he ever will for whatever the reasons, now as for the blocks of code being spread so that the existance of NukeSentinel is checked more than once that is easilly solved and sure enough will be right now. Removing the filters? nope.

Posted: Mon Oct 24, 2005 2:20 pm

I'm not talking about Patched... I'm talking about instructions for NukeSentinel installation, though I might have represented it that way because not only does NukeSentinel installation instructions tell you to do this, but by default Patched does the same thing... In that regard, my bad but the instructions and language should probably be changed on both accounts (in Patched telling people to change the code in the situation of having NukeSentinel and in NukeSentinel installation instructions as well).

I understand that patched likes to address this in advance; though maybe that's not such a great idea given that it creates the situation of adding additional latency; however, again.. I think that if you ARE running NukeSentinel, the installation methodologies should be changed to NOT query an "if" situation. There simply is no need to even have any of that code in the mainfile at all if NukeSentinel exists. Rather the methodology should be changed to tell those installing either Patched or NukeSentinel to change all of that to simply do a single include(includes/nukesentinel.php); and that's it.

When you know it is installed, then there is no need to ask the question, nor to apply double filtering.

As for at least changing it to only ask once instead of 3 times, great... but I think in parallel the instructions for NukeSentinel itself should also be adjusted accordingly to remove all of that code and to have it located inside the includes/nukesentinel.php

Posted: Mon Oct 24, 2005 2:28 pm

The instructions for NukeSentinel did suffer changes because of Nuke Patched and will suffer them big time soon but not by my doing, Nuke 8.0 will change how files are included from what i hear but we'll have to wait until it is released to find out how this method will work and what it is.

Posted: Mon Oct 24, 2005 2:40 pm

Well, as is the case with 7.9, I won't be supporting 8.0. FB is not the sharpest knife in the drawer and from all observations just seems to make things worse with each revision. I've heard some additional very funny (LOL type) rumors lately about 8.0 and forums and the like and while I won't contribute to spreading any rumors, needless to say that I won't be supporting any more of FB's code because he simply makes it worse with every revision. If he spent some time fixing bugs from the last 2 years (or at least incorporating those fixes done by others) that would be one thing, but he simply could care less about any of us or any fixes or security issues.

While off topic, it goes back to what I was talking about regarding making assumptions about installed solutions.

My personal opinion is that Patched shouldn't assume, nor even inquire whether or not NukeSentinel is installed. It should assume that it is NOT; however, IMHO patched should consolidate all of the functions into an ordered series. Meaning... one right after the other instead of "around" inside the mainfile.

This would accomodate a NukeSentinel instruction that would have users doing a:
FIND Lines 120 through 180

Code:

code snippet of patched

REPLACE WITH:

Code:

include(includes/nukesentinel.php);

Thus, the problem is solved by NukeSentinel. In the case where NukeSentinel exists and users didn't make the modification, that's okay too because the default patched code would block the intrusion. The other advantage to NOT asking the question (if file_exists) is that a routine could be written for NukeSentinel that would examine the mainfile to see if the user has replaced the default patched code with the single include call, which can't be done as long as patched has a "if file exists" scenario.

In other words, NukeSentinel could be checking the nuke build (and the NukeSentinel configuration build) to ensure that everything is setup correctly simply by making a couple of queries at the administration level. If the function (include nukesentinel.php) is NOT being called, NukeSentinel would know it and would tell the user that they need to make xyz modifications to the mainfile.

This is much like what Protector did in knowing that modifications were yet to be done.

Thus again, I think patched should simply ignore this and not call for NukeSentinel (assume it is not there) and instead we modify the NukeSentinel installation instructions accordingly. I do think however it would be useful if Patched (whereever possible) could identify things that should be changed wherever appropriate and to consolidate functions to accomodate those future NukeSentinel made changes.

Just my 2 cents.

Steph

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

In reality, regardless of which approach is taken, the amount of latency/overhead, is but a few nano-seconds. I think this is more of an esoteric/philosophic debate.

Posted: Mon Oct 24, 2005 3:08 pm

More or less i have heard similar comments about 8.0, let's see what comes out and what user response is to it, i will not comment on it for now since it has not been released and like Steph said all is based on rumours at the moment so it would not be fair or wise for me to discuss it.

Regarding mainfile.php and any other file with similar code i am doing my best to group everything in a way that it at least makes some sense.

Posted: Mon Oct 24, 2005 3:21 pm

Yeah, I noticed that patched was getting better at organizing the code. God only knows that FB won't do it (as is demonstrated in the entire 7.x series).

Technocrat has been talking about some additional performance modifications that his team is making and I look forward to seeing those as well. I think when you integrate GT into the works, stuff like that becomes critical.

I guess the reason why I'd really like to see NukeSentinel take all of this out of the mainfile is that it really optimizes the mainfile and also makes it so that (from a debugging perspective) you know that only one function is being called for the formatting and filtering process. Less questions if you will, but more optimized as well. You also don't have to worry about clearing the cache of it the if_exists, which is important when we get into conditional filtering where post and get content changes from one state to the next. (One filter versus the other).

Again, much of this is thinking ahead..(or in some of cases the present) regarding use of these new filters that are neither part of default Nuke or NukeSentinel but are proving to be much better at function and data filtering both in terms of data manipulation (of check_html, stripslashes, FixQuotes, etc...) as well as filerting both the data as well as the query.

As these become more robust, streamlining turns into a serious performance issue. In my testing, I've seen a 20% jump from these new processes and i think that's substantial.

I realize for SOME people removal of that code means shaving nanoseconds, but not for everyone.... for some people it may mean more than just nanoseconds. It really depends on what the server configuration is in terms of memory allocation, disk configuration and the number of files in the target... nevermind the number of queries made as they are per session and not global. It all adds up I guess is what I am trying to say.

Posted: Mon Oct 24, 2005 4:10 pm

We have made a number of small core improvements with Evo (Credit largely goes to Quake). But it becomes a line in the sand, how far do you go. What about compatibility? When does it not become Nuke anymore?

One thing we have learned is that every nano second counts when you add them all up. Its like Superman II with all the 1/2 cents. Sure it seems like nothing at first, but after you get a large number of them you actually have something.

That being said I have to go with Steph on this one. It might seem minor but everything helps.

Posted: Mon Oct 24, 2005 7:03 pm

I am all for giving instructions to remove sections of mainfile.php all together. Like the whole dang thing Wink

Anyway, Putting hte NukeSentinel include at the very begining was how we started but have found unless

Code:

if(!ini_get("register_globals")) { import_request_variables('GPC'); }

is also moved to the vey begining many people were having problems with NukeSentinel not picking up everything correctly. So we adapted the inclusion code to take in Patched as a basis.

As far as I am personally concerned removing the extra from mainfile.php is by far the best way to go but then you consider how many variants have the mainfile.php all screwed up and people would be causing more then good by removing pieces. Let's face it, we are considered to be experts by many people and this makes perfect sense to remove redundant code but so many people are still yet just beginners with nuke and are very fearful of removing anything. Which I also understand because I carshed my first nuke sites so many times I couldn't tell how many times Wink

Now, with 8.0 . I have no plans what so ever to support it in any way other then to make it availible to the masses as soon as I get my hands on it. This is something I have stated publicly on my site because we all know mr. burzi is not going to properly address past, present, and future issues with his shity way doing things. If NukeSentinel is made 8.0 compliant it will not be by my hands. I've drawn that fabled line in the sand and I have dared mr. burzi to cross it and unless he does, like when hell freezes, I'm not supporting any future $10 a shot crap.

He is doing his best to kill the project only to revive it as a commercial application where he has stripped every copyright, comment, and notice from the code so he can change from GPL to his own license and start charing $100 a pop. I'm not the only one that has seen that he is heading in this direction. So even if you disagree with me I'll still hold this to be true.

Slightly off topic, I have made plans to support only 7.0 to 7.9 as far as making NSN scripts compatible with them. I have also made plans to find the best replacement for Puke and join that team once it is made clear what and who that team may be. I want to see "After Patched" and the former "CPG Nuke" before I make any finial decissions but this has got to be the end for mr. burzi. I could continue to fix sites, patch sites, and revert sites back to 7.6 for months and feel guilty for charging people to fix what they thought was a good solution.

We MUST stop supporting mr. burzi and form a new and more powerful core cms that has HTML compliance, security, and speed as it's foundation. Not how many screwed up modules can be packed with it or how many faulty themes can be included in it. I am looking for a team that is doing just that. Stripping ALL the bloat out, reducing to a simple and solid core, and making mr. burzi suck dust from his solution being grounded from the backwash that will be produced by those I think could and can code circles around the arrogant bastard.

Back on topic, I will at my first free time work on reworking the install instructions and possiblely include basic and expert instructions. I have in the past tried to keep it as simple as possible for everyone. I will opt for instructing people to comment out code instead of completely removing it should they ever need to remove NukeSentinel from their sites though.

I will also produce a core include that will help to filter input in a better fashion so that any of the NSN scripts could rely on a single master include instead of having to have a seperate include for every script set that has repeated functions. This step will head us towards the improved speed which I am a supporter of. As it stands right now I am going to have to pull down my site and rebuild it making speed a major item on the todo list.

Finially, I think I lost the main focus of this thread but we are all talking of improvements but few of us have taken the time to make them in a shared fashion for fear of things being stolen, stripped, ripped, and abused. I guess I have gotten use to what I do being done just that way. From NSN-Nuke's admin system being ripped to the PHP-Nuke 7.2 that came directly from my PHP-Nuke 7.1.1 enhanced version so I guess I will do my very best to take the lead is making a "Shared" effort.

Posted: Mon Oct 24, 2005 7:26 pm

Not to interrupt the experts, but I just wanted to jump in and say that I would be all for this. My site has a 4-5 second delay most times when loading pages that I just cannot get rid of. Sad

I even removed the page numbers hack, scoring points, disabled MS-Analysis, etc. I'm trying to speed it up as much as I can.

Posted: Mon Oct 24, 2005 10:21 pm

Posted: Mon Oct 24, 2005 10:24 pm

BobMarion wrote:

We MUST stop supporting mr. burzi and form a new and more powerful core cms that has HTML compliance, security, and speed as it's foundation. Not how many screwed up modules can be packed with it or how many faulty themes can be included in it. I am looking for a team that is doing just that. Stripping ALL the bloat out, reducing to a simple and solid core, and making mr. burzi suck dust from his solution being grounded from the backwash that will be produced by those I think could and can code circles around the arrogant bastard.

I agree, a solid Core system is needed. Not a bunch of buggy releases with new buggy features with every release. FB needs to focus on the core phpNuke system, rather than throwing in new features.

Posted: Tue Oct 25, 2005 12:53 am

I don't trust FB to "focus" on anything. I'll do nothing to help Mr. Burzi because of the identified development in a vacuum strategies. While Mr. Burzi has been stripping out copyright notices, I have been busy adding them back into "After-Patched". I've done my best in this regard, but work continues on that front.

I also wanted to comment that I'm working on a name for "After-Patched". It is definately going to become a fork. While 100% Nuke compatible in every respect, at this stage, it is different enough that it can no longer be considered nuke and nor should it be burdened by the negative stigmas of carrying that name.

I still need to work out a groups system and figure out these filtering and manipulation functions (in other words shake up NukeSentinel a tad) but after that, I think that it will make a great foundation in that every single known bug (and quite a few unknown bugs) has been fixed.

Anyway, I'm hoping to trim the mainfile down to a real sexy slim size and to carry all data manipulation and filtering processes into a seperate function (like includes/nukesentinel.php) only because I think the mainfile should handle structure and configuration and that manipulation and filtering should be done externally because frankly, the default nuke methods just don't cut it.

At least Chatserv and others have been moving forward with patching it where they can, but I think that effort is better spent on NukeSentinel versus baseline nuke code... but that's just my two cents.

Steph

Posted: Tue Oct 25, 2005 1:00 am

manunkind wrote:

Not to interrupt the experts, but I just wanted to jump in and say that I would be all for this. My site has a 4-5 second delay most times when loading pages that I just cannot get rid of. Sad

I even removed the page numbers hack, scoring points, disabled MS-Analysis, etc. I'm trying to speed it up as much as I can.

I only said that because people keep emailing me under the premiss of "Ask an expert" Smile

Not trying to shun anyone here but make a global assumpsion. Blonde Moment

<-- hey raven, shouldn't that be Blonde or is that yet another one? hehehehehehe

Posted: Tue Oct 25, 2005 2:30 am

According to the word experts Wink

, I quote:

The words blond and blonde come from the French and follow somewhat the French pattern. Blond (without the e) is used to describe males, mixed gender, or uncertain gender. Blonde refers to women or female gender.

In modern use, blond is sometimes used for female as well as male, but blonde is preferred for female.

Posted: Tue Oct 25, 2005 2:34 am

And all this time I thought we were talking about blounde hair. (Old english) lol

Posted: Tue Oct 25, 2005 12:35 pm

Well I have the luxury of experimenting on a Nuke 7.4 patched system here at home so I tried 64bit's suggestions out on mainfile. Partly this was to teach myself and I sure learned a few things in the process. I will say though that I was questioning the "file exists" logic on my own before I read 64bit's posting. I sure am not going to be running my systems without Sentinel so why always be testing that it exists.

Anyway here's the relevant sections of 7.4 mainfile code that I wound up with. I just commented the "file exists" sections out rather than remove them, though removing them would be easier and cleaner for reasons I'll discuss. I placed a caps locked word CHANGED at the beginning of each section I commented out and an END CHANGED at the end.

Code:

// convert superglobals if php is lower then 4.1.0


/*  CHANGED ... I am not running below 4.1.0


if ($phpver < '4.1.0') {


  $_GET = $HTTP_GET_VARS;


  $_POST = $HTTP_POST_VARS;


  $_SERVER = $HTTP_SERVER_VARS;


  $_FILES = $HTTP_POST_FILES;


  $_ENV = $HTTP_ENV_VARS;


  if($_SERVER['REQUEST_METHOD'] == "POST") {


    $_REQUEST = $_POST;


  } elseif($_SERVER['REQUEST_METHOD'] == "GET") {


    $_REQUEST = $_GET;


  }


  if(isset($HTTP_COOKIE_VARS)) {


    $_COOKIE = $HTTP_COOKIE_VARS;


  }


  if(isset($HTTP_SESSION_VARS)) {


    $_SESSION = $HTTP_SESSION_VARS;


  }


}


           END OF THAT CHANGED */


// override old superglobals if php is higher then 4.1.0


// I'M NOT SURE WHY THIS IS NEEDED BUT IT SCREWS THINGS UP IF IT'S NOT THERE 


if($phpver >= '4.1.0') {


  $HTTP_GET_VARS = $_GET;


  $HTTP_POST_VARS = $_POST;


  $HTTP_SERVER_VARS = $_SERVER;


  $HTTP_POST_FILES = $_FILES;


  $HTTP_ENV_VARS = $_ENV; 


  $PHP_SELF = $_SERVER['PHP_SELF'];


  if(isset($_SESSION)) {


    $HTTP_SESSION_VARS = $_SESSION;


  }


  if(isset($_COOKIE)) {


    $HTTP_COOKIE_VARS= $_COOKIE;


  }


} 





// After doing those superglobals we can now use one


// and check if this file isnt being accessed directly


if (stristr(htmlentities($_SERVER['PHP_SELF']), "mainfile.php")) {


    header("Location: index.php");


    exit();


}





if (!function_exists("floatval")) {


    function floatval($inputval) {


        return (float)$inputval;


    }


}





if ($phpver >= '4.0.4pl1' && isset($_SERVER['HTTP_USER_AGENT']) && strstr($_SERVER['HTTP_USER_AGENT'],'compatible')) {


   if (extension_loaded('zlib')) {


      @ob_end_clean();


      ob_start('ob_gzhandler');


   }


} elseif ($phpver > '4.0' && isset($_SERVER['HTTP_ACCEPT_ENCODING']) && !empty($_SERVER['HTTP_ACCEPT_ENCODING'])) {


   if (strstr($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) {


      if (extension_loaded('zlib')) {


         $do_gzip_compress = true;


         ob_start(array('ob_gzhandler',5));


         ob_implicit_flush(0);


      if (ereg("MSIE", $_SERVER['HTTP_USER_AGENT'])) {


         header('Content-Encoding: gzip');


      }


   }


}


}





if (!ini_get('register_globals')) {


  @import_request_variables("GPC", "");


}





//Union Tap


//Copyright Zhen-Xjell 2004 http://nukecops.com


//Code to prevent UNION SQL Injections


/* CHANGED 


if(!file_exists('includes/nukesentinel.php')) {


  unset($matches);


  unset($loc);


  if(isset($_SERVER['QUERY_STRING'])) {


    if (preg_match("/([OdWo5NIbpuU4V2iJT0n]{5}) /", rawurldecode($loc=$_SERVER['QUERY_STRING']), $matches)) {


      die('Illegal Operation');


    }


  }


}


  END OF CHANGED */


// This block of code makes sure $admin and $user are COOKIES


if((isset($admin) && $admin != $_COOKIE['admin']) OR (isset($user) && $user != $_COOKIE['user'])) {


  die("Illegal Operation");


}





// We want to use the function stripos,


// but thats only available since PHP5.


// So we cloned the function...


if(!function_exists('stripos')) {


  function stripos_clone($haystack, $needle, $offset=0) {


    return strpos(strtoupper($haystack), strtoupper($needle), $offset);


  }


} else {


// But when this is PHP5, we use the original function   


  function stripos_clone($haystack, $needle, $offset=0) {


    return stripos($haystack, $needle, $offset=0);


  }


}





// Additional security (Union, CLike, XSS)


/*  CHANGED 


if(!file_exists('includes/nukesentinel.php')) {


  if(isset($_SERVER['QUERY_STRING']) && (!stripos_clone($_SERVER['QUERY_STRING'], "ad_click") || !stripos_clone($_SERVER['QUERY_STRING'], "url"))) {


    $queryString = $_SERVER['QUERY_STRING'];


    if (stripos_clone($queryString,'%20union%20') OR stripos_clone($queryString,'slash asterik') OR stripos_clone($queryString,'asterik slashunionslash asterik') OR stripos_clone($queryString,'c2nyaxb0') OR stripos_clone($queryString,'+union+') OR stripos_clone($queryString,'http://') OR (stripos_clone($queryString,'cmd=') AND !stripos_clone($queryString,'&cmd')) OR (stripos_clone($queryString,'exec') AND !stripos_clone($queryString,'execu')) OR stripos_clone($queryString,'concat')) {


      die('Illegal Operation');


    }


  }


}





$postString = "";


foreach ($_POST as $postkey => $postvalue) {


    if ($postString > "") {


     $postString .= "&".$postkey."=".$postvalue;


    } else {


     $postString .= $postkey."=".$postvalue;


    }


}


str_replace("%09", "%20", $postString);


$postString_64 = base64_decode($postString);


// the union in next should be asterik slash union slash asterik


if (stripos_clone($postString,'%20union%20') OR stripos_clone($postString,'a/union/a') OR stripos_clone($postString,' union ') OR stripos_clone($postString_64,'%20union%20') OR stripos_clone($postString_64,'asterik slashunionslash asterik') OR stripos_clone($postString_64,' union ') OR stripos_clone($postString_64,'+union+')) {


header("Location: index.php");


die();


}


       END OF CHANGED */


if(isset($admin) && $admin == $_COOKIE['admin'])


{


   $admin = base64_decode($admin);


   $admin = addslashes($admin);


   $admin = base64_encode($admin);


}





if(isset($user) && $user == $_COOKIE['user'])


{


   $user = base64_decode($user);


   $user = addslashes($user);


   $user = base64_encode($user);


}





// Die message for not allowed HTML tags


$htmltags = "<center><img src=\"images/logo.gif\"><br><br><b>";


$htmltags .= "The html tags you attempted to use are not allowed</b><br><br>";


$htmltags .= "[ <a href=\"javascript:history.go(-1)\"><b>Go Back</b></a> ]";





// Die message for empty HTTP_REFERER


$posttags = "<b>Warning:</b> your browser doesn't send the HTTP_REFERER header to the website.<br>";


$posttags .= "This can be caused due to your browser, using a proxy server or your firewall.<br>";


$posttags .= "Please change browser or turn off the use of a proxy<br>";


$posttags .= "or turn off the 'Deny servers to trace web browsing' in your firewall<br>";


$posttags .= "and you shouldn't have problems when sending a POST on this website.";


/*  CHANGED


if (!defined('ADMIN_FILE') && !file_exists('includes/nukesentinel.php')) {


  foreach ($_GET as $sec_key => $secvalue) {


    if ((eregi("<[^>]*script*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*object*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*iframe*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*applet*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*meta*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*style*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*form*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*img*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||


   (eregi("<[^>]*body*\"?[^>]*>", $secvalue)) ||


   (eregi("\([^>]*\"?[^)]*\)", $secvalue)) ||


   (eregi("\"", $secvalue)) ||


   (eregi("forum_admin", $sec_key)) ||


   (eregi("inside_mod", $sec_key))) {


        die ($htmltags);


    }


}





foreach ($_POST as $secvalue) {


    if ((eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) || (eregi("<[^>]script*\"?[^>]*>", $secvalue)) || (eregi("<[^>]*body*\"?[^>]*>", $secvalue)) || (eregi("<[^>]style*\"?[^>]*>", $secvalue))) {


      die ($htmltags);


    }


  }


}


*/


// Posting from other servers in not allowed


// Fix by Quake


// Bug found by PeNdEjO


/* if ($_SERVER['REQUEST_METHOD'] == "POST") {


  if (isset($_SERVER['HTTP_REFERER'])) {


    if (!stripos_clone($_SERVER['HTTP_REFERER'], $_SERVER['HTTP_HOST'])) {


        die('Posting from another server not allowed!');


    }


  } else {


    die($posttags);


  }


}  END OF CHANGED */

As 64bit suggested, the references to file exists and the logic that duplicates the filtering code in mainfile are now commented out. One thing 64bit suggested that wouldn't work, I don't think, is to simply include sentinel at the beginning ... I believe the path that it's included from depends on where you are at the time.

I also took out the test for whether the PHP version is less than 4.1.0 since in my case I know it's not. Given the number of times that mainfile gets called it sure would be nice to be able to do these tests and set these variables once for the whole system and not have to test the version or set the variables every time thru.

Oh one interesting anomaly if anyone is trying to comment the filters out, they contain /* and */ characters in them so if you comment them out those characters can unintentionally "end" your comments and result in a syntax error. I changed them all to slash asterik or asterik slash as a temporary measure but the proper way would be to eventually remove the code entirely.

I can emphasize with the fact that you are trying to write GENERAL instructions for Sentinel that will work for a range of systems but I'm a relatively newbie to this and if I can figure it out so can many others. As for it being just nanoseconds, well that's all a computer is and they do add up. There is a lot of other stuff in mainfile too that gets executed many times for each user when it probably just needs to be run once per "session" at most. For instance, the extension_loaded zlib routines. Beyond the nanoseconds saved, anything you can do to simplify the core routines will pay off in the long run in terms of maintenance, debugging, and reducing user error.

Posted: Tue Oct 25, 2005 12:56 pm

I want to clarify something here. It used to be the case where 'nano seconds add up' really mattered. In today's server's economy and connection speeds, this is so much less the issue. That aside, if a function takes 2 nano seconds to run it does NOT add anything [measurable] to your overhead - period. I don't care whether you agree or not or use the function or not. But please don't keep restating that it matters because in this particular case it does not. In this case it is really a philosophical debate and nothing else. Run a time check on using it and not using it if you need the proof. I've been in this business since 1970 when we had to squeeze every ounce of blood from every turnip we had. I strive for efficiency too but am not going to bank on something that simply doesn't matter. there's so much more to draw from.

Quote:

I also took out the test for whether the PHP version is less than 4.1.0 since in my case I know it's not. Given the number of times that mainfile gets called it sure would be nice to be able to do these tests and set these variables once for the whole system and not have to test the version or set the variables every time thru.

Very easy to do. Use static variables.

Posted: Tue Oct 25, 2005 3:31 pm

I started in the era of punch cards too and am very much aware that the execution of one function, more or less, or even a dozen doesn't add up to much. And I have no desire to initiate or even join in a purely philosphical discussion.

However, this thread was started, if I recall correctly, in part because 64bit is working on what will be a new Fork for Nuke or perhaps he would prefer to call it a new system entirely. In the process it makes sense to look at the architecture or how things hang together.

You are all more familiar with the code than I am but my reading is that mainfile contains two types of "things": (1) initialization of variables and (2) functions that other programs may or may not use. The functions don't get used unless another program calls them so they really don't matter much to this discussion -- though if PHP offered a way to read them into memory and make them "persistent" thru a session without including mainfile every time that would be cool. The initialization stuff is happening every time thru and that's what doesn't make much sense to me.

By my reading, mainfile gets called just about any time a user moves from screen to screen in the system. So every time, just for instance, there's a connection to the prefix_config table made and all the columns in there are read into variables. I/O still counts doesn't it? Why couldn't this be done once when a user first comes into the system? Once per session so to speak. I know this is Barzi's design but if someone is going to recode the system why not find a way to only do things that need doing once, once? Almost everything else that I posted in the code section of the previous post could also be included in the "needs to be done once" area.

I looked at index.php as a potential place to put "initialization" stuff but of course that starts out by including mainfile.php. Darn! How about if you took the initialization stuff out of mainfile and stuck it in something called initialization.php and set some static initialization variable to "1" when the file was included once and then only included it if the variable wasn't set? Or there may be some more elegant and foolproof way to do this.

If someone did this and eliminated the code that duplicates Sentinel functions then mainfile would be reduced to pretty much a set of common sub-routines (oops, functions).

Posted: Tue Oct 25, 2005 5:32 pm

Although I have not looked at it with any real solid analysis, it was NOT my understanding that mainfile.php is parsed multiple times, so this whole discussion regarding "initialization" I do not think relevant to the initial thread. Not that it isn't a discussion point of interest, just that it doesn't really relate to the original contention of 64-bit.

If I am understanding correctly, his main issues that 64-bit is raising are multiple functions doing the same/very similar things (thus increased parse times, difficulty in ongoing maintenance, and replicated/duplicated calls to do similar things) as well as unnecessary calls to file_exists.

Since the web is stateless, unless the language and app server being used allows for session-level and application-level objects, all the necessary scripts have to be re-parsed every key-click from the user. That is just the nature of scripting. ASP (and I think with Java app servers) gives one the ability to store application-level information in an object and user-sessions level information as well in a session object... is there really an exact equivalent in PHP? If so, I would be interested in learning as such because I think it would be very useful.

Regards,
montego

Regular Joined: Oct 17, 2005 Posts: 51

That sounds great to get fb outta the picture. I went to his site not too long ago and was suprised I didnt get spyware from all the pop-ups and crap. Anyway, on everyone supporting after patched and perhaps switching over to this. Now from my understanding Steph is going to be charging a subscription for this. So basically what Im asking is, is tis new fork in the road gonna be costing money, not that its not worth it, but I just dont see all themers and other scripters changing everything to comply with a pay install. Are you going to be releasing an open source version of this Steph?

Posted: Tue Oct 25, 2005 6:55 pm

PHP have session handling (objects if you prefer). mainfile.php does NOT necessarily get parsed everytime it is called as long as it is called with include_once or require_once. And, as I said earlier, the use of static variables in functions can and will speed up the redundant efforts of many functions in mainfile. I have been using them forever. In fact, it seems that the thread that first brought about those changes was started way back in my forums.

Posted: Tue Oct 25, 2005 9:01 pm

j_felosi wrote:

Are you going to be releasing an open source version of this Steph?

Someone can still charge for a service or even the download and it still be GNU/GPL. It just means that anyone else can distribute it as well as long as certain requirements are met, among other things. I believe Steph is trying to pull together a more controlled and service-oriented approach to assist web masters with keeping up with security and other updates. This, I believe, is where the value-add may be for those who don't have as much time to analyze every update, figure out all the affects, implement, test thoroughly, deploy, etc.... at least that is what I am hoping. However, if it doesn't support existing add-ons, I'd be hard-pressed to move to it even if it is truelly compliant, but the Dr. is still out on that one... I am in wait-and-see mode.

Also, if I am understanding the GPL correctly, Steph will have a difficult time defending NOT releasing After-Patched as GPL even if he has substantially re-written much of it as he says. I don't know the exact requirement as I have not read it in awhile, but he may have trouble with having started with Nuke as the base.

Regards,
montego

Posted: Tue Oct 25, 2005 9:31 pm

Me and my friend recently discovered that United Nuke, which is 100% w3c compliant but its gonna be til next version til they release it with bb2nuke. The makers say its uses rock solid authentication for sql queries and such so it dont really need sentinel but Ill still try it. i have one installed now on a test domain and Im amazed. It has a page generation rate of around .03 seconds, its 10 times faster than regular nuke. So we'rre gonna mess with it a while and see how it goes. Although its 100% compliant stock, when you add the regular nuke themes and addons there is the problem but hopefully that can be fixed. Go check it out ,it might be worth looking into. But then again, maybe not. It looks good so far.

Edited: I seen their url is not allowed here, hope I didnt do anything worng, looks just like a nuke development site to me