FAQ: How to choose secure extensions (Part 1)

This is the archive off all FAQ related threads.
Locked
User avatar
rliskey
Joomla! Guru
Joomla! Guru
Posts: 828
Joined: Tue Jun 06, 2006 7:41 am
Location: California, Germany, Norway
Contact:

FAQ: How to choose secure extensions (Part 1)

Post by rliskey » Thu Oct 05, 2006 6:10 am

Introduction
The following information is extracted from a post by RobS in the Security forum.
http://forum.joomla.org/index.php/topic ... #msg435845

The most important thing anyone can do is make good decisions regarding the extensions they choose to use on a site.  Once an insecure or malicious extension is installed you should consider your entire site compromised. There is NO POSSIBLE WAY to protect or stop a component from accessing database tables it should not be accessing. There is no possible way to stop a component from sending all of the information it found back to a cracker website. Once an insecure or malicious component is installed, your entire site is insecure. 

With all of that said, here are some pretty easy tips for making good choices regarding the extensions you install:

1. When was the last version released?
If it has been over a year, consider the project abandoned and find something else.  Do not install old components.

2. What kind of release is it?  (Stable, Release Candidate (RC), Beta, Alpha)
For production sites you should be sticking to Stable releases as much as possible.  If you cannot wait until a Stable release has been made available, Release Candidates are the only other option you should consider.  I would not suggest anyone install any Beta or Alpha extensions on a production site.  This means they still have bugs, they have not been tested enough, and could have any number of inconvenient bugs or security issues that have not been fixed or worse, found.

3. Does the extension have a history of good security practices? 
This is obviously a bit more subjective but it is still a very valid gauge of future trustworthiness.  It requires a bit of investigation and research.  Look around their download pages and archives, are there many security release or patches?  Are there a lot of reports of cracking activity through this extension?  Are the developers experienced and security conscious?  What do other community members think of this extension?  One example that comes to mind that has little to do with Joomla itself (which makes it a fair example) is phpBB.  This script has had more security issues than I could get my head around and there routinely seems to be newly disclosed issues.  Because of this, I would never use phpBB.  In my opinion its is not trustworthy and there is a high probability that there will be more major security issues. 

4. Is there a support community for this extension? 
This is very important for usability and security awareness.  If there is a support community for an extension there is a better chance of security issues being known and dealt with.  A support community means that people would like to continue using the extension and that they care about the extension.  This furthers the chance that security issues will be found, disclosed, and dealt with promptly.

5. Is there only a Mambo version of this extension?
While this does not in itself make an extension insecure but is rather a gauge of support, how recently the last realease was, and future support.  There is a pretty narrow chance that Mambo components will be supported in 1.5 so save yourself the trouble and find a component made to work with Joomla.  It will make your life easier.

6. Is the extension generally bug free?
I hinted on this a little bit in number three but I think it is worth discussing in more depth.  While it is almost impossible for an extension to be completely bug free, the smaller the number of bugs, the better.  If there are bugs in the software it means there are mistakes in the software.  The more mistakes, the higher risk of usability issues and security issues.  Security issues are often a result of not one bug, but several bugs or bad practices.  For example, the recent 3rd party vulnerabilities that allow for remote file inclusion are a result of:

Bad Practices:
1. Having PHP's Register Globals enabled.
2. Using out of date or abandoned extension.
3. No other security checks enabled for PHP. (url_fopen off, open_basedir restrictions, disabled PHP functions)
4. Poorly configured file permissions.
5. No request filtering or software "firewall". (such as mod_rewrite rules or mod_security Apache modules)

Bugs:
1. Not including defined('_VALID_MOS') or die... statements
2. Poorly constructed include() statements.
Last edited by rliskey on Fri Oct 27, 2006 6:46 am, edited 1 time in total.

Locked

Return to “FAQ Archive”