Securing 3rd Party Add-Ons

New Member Joined: Oct 10, 2005 Posts: 20

I am hoping some of you could help me with a project I am working on. I would like to write an article for my site on securing 3rd party addons such as modules and blocks, etc. I figured I would throw this out here and try to get as many opinions as possible of what one should look out for as there are quite allot of older and poorly written addons available.

What should every module include to make it secure?

What types of modules should you NEVER run?

What risks do blocks pose?

What types of blocks should you NEVER run?

What should every block include to make it secure?

Any other comments on the subject would be welcome. I think this would be useful to allot of people as well as myself.

Sells PC To Pay For Divorce Joined: Posts: 5661

I think this is difficult to answer.
To my knowledge there isnt realy a unsecure block,since it isnt that vunerable and whatever attacker doesnt know how the block is named.
And if the block doesnt have any posting functions.

In the modules case thats different,but if including a simple code to make it safe would be all...then we didnt needed sentinel.

What type not to run ?...blocks or mods...
As you might read here and there using any addons on a site that allows any member or vistor to upload anyhing it can be classified as dangerous.
With that your opening a door to any possible hacking attemt.
That can be prevented (whitch usualy is the case) but there's always a chance they might find an opening.

As for the rest of your questions....well look around and read some... Smile

Posted: Mon Oct 10, 2005 4:16 pm

I have looked around some and many people do things allot of different ways. For instance the opening of every block goes something like:

Code:

if (!defined('MODULE_FILE')) {


   die ("You can't access this file directly...");


}

I have also seen it other ways including:

Code:

if (!eregi("modules.php", $PHP_SELF)) {


   die ("You can't access this file directly...");

Is there a prefered or more secure way or do they all accomplish the same thing.

Another thing that I noticed, and what actually got me thinking about this, was the change to the index.php in the PHP-Nuke HOWTO. It appears there was some type of risk by not defining what html files were allowed to be called.

I am hoping by this post to gather as many different things to look out for in order to prepare some type of lose guideline to follow when selecting and installing 3rd party stuff to your site. You can add the patched files, install NukeSentinel but one poorly secure module could really mess ya up i believe.

Posted: Mon Oct 10, 2005 4:29 pm

Well the code you show are for modules and not blocks.
Blocks look like :

Code:

if ( !defined('BLOCK_FILE') ) {


    Header("Location: ../index.php");


    die();

but i suggest you read a litle bit further cause this can be very time consuming.

If you wanna know about the how and the why about nuke stuff i suggest you read phpnuke howto from karakas.

Posted: Mon Oct 10, 2005 4:30 pm

You sound like a network administrator Razz

Posted: Mon Oct 10, 2005 4:32 pm

no im not.. Smile

Im just helping out and if needed pointing people in the right direction...

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

Chris Karakas' HowTo is a great guide, as hitwalker suggested. You might also want to compare the current patch files to the unpatched version - you can learn much from that. Use a file comparison tool like Beyond Compare or the free tool, WinMerge. These tools are also useful for understanding future changes, patches, tweaks, etc.

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

I have found that using Chaterv's latest methodology is the most secure way, thus far, to ensure that it is a legitimate block from YOUR site.

Code:

For Modules:


if (!defined('MODULE_FILE')) {


   die ("You can't access this file directly...");


}


and for Blocks:


if (!defined('BLOCK_FILE')) {


   die ("You can't access this file directly...");


}

As to other security measures, well, I would stay away from addons that don't use the $db->sql_query() type calls and directly access MySQL. Not that it is bad or wrong, but it is bypassing the "standard" access layer calls. If we are going to secure the database access then we would want to do it at the db layer level and directly access MySQL will bypass that. The major security risks with any script is XSS and/or critical path disclosure. I will not belabor the subjects here as they are probably some of the most discussed security issues on the 'net. NukeSentinel protects against most XSS attacks, but the answer lies in FIEO (Filter Input, Escape Output). Never trust any input. That is your secret formula. It's not the block or the module that's necessarily the issue, it's the way errors are handles and queries are written.

Posted: Tue Oct 11, 2005 10:16 am

Thanks Raven that gives me a direction to go in. Chatserv is our friend.. input is our enemy.

Posted: Tue Oct 11, 2005 4:19 pm

one other question on this topic...

Code:

if (!defined('MODULE_FILE')) { 


   die ("You can't access this file directly..."); 


}

I understand the basics of this... it is saying if NOT defined as MODULE_FILE die... but how is it defined as a module file?

Posted: Tue Oct 11, 2005 6:32 pm

stoney wrote:

one other question on this topic...

Code:

if (!defined('MODULE_FILE')) { 


   die ("You can't access this file directly..."); 


}

I understand the basics of this... it is saying if NOT defined as MODULE_FILE die... but how is it defined as a module file?

This is all based on Chat's fixes. Look at v3.1 and look in modules.php.

Code:

define('MODULE_FILE', true);

Posted: Tue Oct 11, 2005 6:39 pm

Ahh that explains allot... thanks yet again.

Posted: Wed Oct 12, 2005 2:18 pm

I've written what could be considered a couple of third party add ons for my site (a bicycle club site) -- they started as stand alones and then I made them into modules when I found Nuke. Then I found religion about security and I'm trying to understand what exposures there are. The suggestion to compare patched and unpatched code is valuable and I'm doing that. But I'm struggling to understand how the vulnerability for input works as indicated in this quote earlier in the thread:

Quote:

the answer lies in FIEO (Filter Input, Escape Output). Never trust any input. That is your secret formula. It's not the block or the module that's necessarily the issue, it's the way errors are handles and queries are written.

I have some screens where users input data about bike rides they are planning. Most of the data is taken from prescribed values on drop down boxes and I believe that there would be no problem there? Or am I wrong? Then there are one or two text input boxes (some text, some textareas). I guess someone could "inject" something there but I really don't understand the mechanism by which it could do harm.

The input screen is in a PHP function in a long PHP "program" that contains a bunch of functions. When submit is hit and some Javascript edits are satisfied, the form action is a separate PHP program that gets the values. Here's a little sample code:

Code:

$ride_name = $HTTP_POST_VARS['ride_name'];


    $member = $HTTP_POST_VARS['member'];


   $ridecat = $HTTP_POST_VARS['ridecat'];


    $distance = $HTTP_POST_VARS['distance'];


    $ride_description = $HTTP_POST_VARS['ride_description'];

In the example code above the ride name and description are more or less free form while the other values are prescribed by the input form or come from database lookups that the user has no control over.

Once these values (and others) are assembled a function is called to update the database. The call looks like this:

Code:

if(insert_ride($ride_name, $distance, $ride_description, $location_key, $fd_date, $fd_time, $member, $pace, $terrain, $ridecat, $ride_type, $freq, $lday, $lmth, $lyear, $month, $year, $day, $createdate, $mem))


      $ridemsg = 'Ride ' . stripslashes($ride_name) . ' was added to the database.';


    else


      $ridemsg = 'Ride ' . stripslashes($ride_name) . ' could not be added to the database.';


   select_rides_form($ridemsg);

In the insert functions an "addslashes" is done to each of the values and then the database update is done as per:

[code] $query = "insert into ".$user_prefix."_rides (ride_category, ride_type, ride_name, distance, ride_description, location_key, fd_date, fd_time,member, pace, terrain, created, created_by) values ('$ridecat', '$ride_type','$ride_name', '$distance', '$ride_description', '$location_key', '$add_date', '$fd_time', '$member', '$pace', '$terrain', '$createdate', '$mem')";
if( !($result = $db->sql_query($query)) )
{
$error = $db->sql_error();
$msg = $error[code] . ' ' . $error[message];
$msg .= "<br> for the following sql: ".$query."";
die($msg);
} [/code]

Sorry it took so long, but my question is what's the danger here. I have a vague understanding that the hacker could "inject" something nasty into say the $ride_description but I just don't see how or what it would do. If they want to put some obscenity in they could of course but we'd just erase it and ban them. So the only real danger is that they could use this to somehow get control over the system and I guess I just don't understand how this would work. If more filtering of input is required perhaps you could make a suggestion on what or point me to a source of that information. Thanks.

Posted: Wed Oct 12, 2005 3:08 pm

Quote:

Most of the data is taken from prescribed values on drop down boxes and I believe that there would be no problem there?

Always validate / scrub any input variables. It's very easy to get around drop down boxes.

Having quotes around the variables in the insert / update helps, as does using a standard approach for accessing the database (this lets NukeSentinel do its job). Using $HTTP_POST_VARS limits input to forms (as opposed to changing variables through a URL, but it isn't fool proof.

The other thing you should check is that the text variables don't contain bad HTML - for example, some Javas cript that will be displayed after the record is stored. NukeSentinel will check for this, too, but it's best to only trigger that when it's a true attack. Check the Submit_News module for ideas on how to implement this, but make sure you use something prior to 7.7 since this checking was removed in 7.7 and 7.8 (and maybe 7.9, but I haven't checked).

Finally, if you're expecting an integer (e.g. for a record ID / key), use

Code:

$inputnumber = intval($inputnumber);

to strip out any "extra" stuff that might be in that variable.

Posted: Wed Oct 12, 2005 3:25 pm

I could write a quick script to override your form variables by doing a remote post script. There are a couple of ways to prevent that attack. The most assurred way is to basically have a "whitelist" of values. You could perform the check either before the post or before writing the data, depending on how the script is written. Bottom line, on the server side, compare the posted values against the only legitimate values. escaping/adding slashes does no good if the values are not properly cleansed.

Posted: Wed Oct 12, 2005 3:44 pm

What can the attacker do if he is able to put anything he wants into a data field. I could see spam to some stupid online poker site or something but are they really able to take control of a site simply by entering some hacker bable into a tables field?

Posted: Wed Oct 12, 2005 3:51 pm

I could inject Javascript and/or possible XSS.

Posted: Wed Oct 12, 2005 4:57 pm

http://webmonkey.wired.com/webmonkey/00/18/index3a.html?tw=backend - this is an old article (from 2000) on XSS but it explains it in simple terms that anyone can understand. Kinda funny too

Posted: Wed Oct 12, 2005 5:01 pm

Searching Google will reveal many good and current articles that reveal even more ways that this works and what to watch out for.

Posted: Thu Oct 13, 2005 11:20 am

Thank you all for the suggestions. I did my reading thru Google this morning and found this link which gave me good explanations and a script I could try to "exploit" my input form. Only registered users can see links on this board! Get registered or login!
Within 2 hours I had hacked my site and input form. (The test version I run at home of course).

Then I took kguske's suggestion to look at how the submit news module validates input. So, for the two text fields that I have on the form I run them thru the mainfile routines as per:

Code:

$ride_description = $HTTP_POST_VARS['ride_description'];


    $ride_description = FixQuotes(nl2br(htmlspecialchars(check_words($ride_description))));

That seems to eliminate the script vulnerability since the less than sign is replace by &lt and similar with the greater than. The only problem here is that I currently allow people to put a href into the ride description to link to something they may have on their own home page or to a map file. That won't work this way. I was going to put the hrefs into their own input fields anyway and I was wondering if there is any standard way of "filtering" those. I'm guessing that if you let people input href's they could always link to something malicious?

Checking the values that come from drop down boxes is relatively simple and I'll do it but I'm a bit puzzled by Raven's statement:

Quote:

I could write a quick script to override your form variables by doing a remote post script.

in terms of how it would work. I guess I can see that if you knew the form name and the names of all the variables (form elements) you could create a similar form with bogus values for the drop down variables and then submit it to my "insert_ride.php" program but of course you'd need to know what the name of that is too. I'm not saying this is impossible of course, but it does seem a hacker would have to do a lot of work and experimentation to do this. Or, hummm ... could they do a view source and get the names they need? I wonder.

Incidentally, I have Sentinel running and the text that I inserted in my ride description field was:

Quote:

<xxx.script>alert('CSS Vulnerable')</xxx.script>
<img csstest=javascript:alert('CSS Vulnerable')>
&{alert('CSS Vulnerable')};

(I stuck the xxx's in cause sentinel doesn't like the script thing plain vanilla.)

and it was stored in the database. Before I made the changes to use htmlspecialchars() it was stored with the real greater than and less than signs which triggered the alert when I ran a report on that ride and after I made the changes the symbols were changed to their html entitities, thus not triggering the alert. Is Sentinel supposed to stop the first instance? If so I may have to check out how it is set up. I include header.php at the start of the insert_ride.php and that invokes mainfile.php which should in turn kick off sentinel.php if my reading of the code is right.

Thanks again for all your help on this board.

Posted: Thu Oct 13, 2005 12:23 pm

It's really very simple. If I am on your site that has the form, all I have to do is View Source and now I know everything about the form, including the Action to take on submission. Now do you see?

Posted: Fri Oct 14, 2005 10:29 am

Quote:

It's really very simple. If I am on your site that has the form, all I have to do is View Source and now I know everything about the form, including the Action to take on submission. Now do you see?

Yes, now I see. Would it be correct to assume that the XSS filters in Sentinel would catch this? I realize that it's important to validate the form anyway and I'm working on it.

In that line, I decided to try to strip out all html tags from two of the "freeform" fields on the form. I looked at the submit_news index.php which appears to have a plaintext option and traced it back to mainfile.php and the check_html function. (This is in Nuke 7.4 with the 3.1 patches). Check_html starts out:

Code:

Function check_html ($str, $strip="") {


       include("config.php");


    if ($strip == "nohtml")


       global $AllowableHTML; 


       if (!is_array($AllowableHTML)) $AllowableHTML =array('');

However, after looking at how it works I have concluded that when you say "nohtml" what you are really saying is "nohtml except for the html tags that are specified in config.php in the AllowableHTML array". So there is really no way to use this to prohibit all html from being entered? Is this right? Does anyone know of any functions in PHP or Nuke that will strip out all html tags? [Later edit: htmlentities() will make them "harmless" I guess but doesn't really remove them].

Also, again I'm uncertain about how this works but it appears if you don't pass in the "nohtml" parameter to this function then the AllowableHTML array will be set to null and the edits following:

Code:

if ($a = $AllowableHTML[$tag])

will not be carried out?

Any help interpreting this by someone more expert in PHP than I will be appreciated.

Posted: Fri Oct 14, 2005 1:38 pm

Quote:

Would it be correct to assume that the XSS filters in Sentinel would catch this?

Absolutely not. NukeSentinel is not a cure for the common coding mistakes Wink

NukeSentinel protects against url cracks as well as a few other things Smile

, but there is nothing that prevents the XSS scripting described above except you, the coder, must FIEO..