The Joomla! Community Magazine™

Only a Ninja can kill another Ninja

Written by | Friday, 01 October 2010 00:00 | Published in 2010 October
If you were to provide a short list of the threats against your site, which one would be the number one threat? For me, it's script kiddies. Those pesky individuals who don't have a programming bone inside them, but still can cause a great deal of harm to our sites by using pre-packaged attacks against them. Their success rate is amazingly high, mostly due to our fault. The purpose of this article is to demonstrate some trivial techniques to add a degree of stealth on your site so that script kiddies can't launch their attacks and even if they do, they will most likely be fended off successfully. Just like a ninja, you'll learn how to have your site lurk in plain sight without being spotted by those pesky attackers.

Before beginning with this article, I'd like to disclaim something. I am in no way convinced that Joomla! is a vulnerable application or that Joomla! developers lack a security mind. On the contrary, I think that Joomla! is one of the safest web applications built to date. It's framework gives all the necessary tools for developers to produce useful, stunning and safe extensions. Most of the security concerns I am about to present are more or less shared among all high-profile PHP applications, including the other two big CMS. It's just that I am writing for the Joomla! Community Magazine and my specific passion for Joomla! which makes me talk about those concerns in the context of Joomla!. Now sit back and start inconspicuously quacking because...

...your site is like a sitting duck. Quack!

I'm sorry to be the bearer of bad news, but your site is a sitting duck, merrily quacking while predators pass by it. The simple truth is that all of our sites have some interesting features, commonly used for debugging, which can be exploited by hackers to divulge information about our sites. This information all by itself doesn't create a security threat, but a malicious hacker can exploit it to decide if your site is vulnerable before launching an attack. Since the premise of this article is to add some ninja stealth to your site, let us take a look at how noisy your site is and what we can do about it.

Visual fingerprinting

One of the easiest ways for an attacker to decide if your site is a potential Joomla! target is to perform a rudimentary visual fingerprinting. As you know, appending the tp=1 query parameter to your site's URL will trigger the modules debugging mode, showing all module positions on your template. This provides a tell-tale sign that the site is running Joomla!. Example: http://www.joomla.org?tp=1.

One other, much less known, way to do that is using the template=foobar query parameter, where foobar is any template name. This will change your site's template to the specified template name. If you use a non-existent template name, it will try to revert to the default (Milkyway) template. Example: http://extensions.joomla.org/?template=foobar

Finally, we can trigger the display of a system sub-template by using the tmpl=something query parameter. One of the most useful system sub-templates which can never be turned off is the offline template, i.e. what appears when you put your site off-line. Look, mom, I can make joomla.org appear offline: http://www.joomla.org/?tmpl=offline

The way to avoid exposure to these nasty tricks is to block them by placing mod_rewrite .htaccess rules to cause all URLs including these query parameters to end up to a 404 page:

RewriteCond %{QUERY_STRING} (&|%3F){1,1}tp= [OR] 
RewriteCond %{QUERY_STRING} (&|%3F){1,1}template= [OR] 
RewriteCond %{QUERY_STRING} (&|%3F){1,1}tmpl= [NC] 
RewriteRule ^(.*)$ - [R=404,L] 

PHP has such a big mouth

PHP is a fine programming language, but do you want to tell the world exactly which version of PHP you've got so that they can hack you easier? I didn't think so, but PHP developers seem to disagree with you. What? You don't believe me? PHP developers decided to include hard-coded images inside all PHP executables which get displayed when a special, very long query parameter is present in the URL. These images change from one version of PHP to the other and can be used to easily identify your PHP version. Collectively known as the PHP Easter Eggs, they create a gaping security hole on your site and have to be stopped, again with some .htaccess magic:

RewriteCond %{QUERY_STRING} ^%3F=PHPE9568F36-D428-11d2-A769-00AA001ACF42 [OR] 
RewriteCond %{QUERY_STRING} ^%3F=PHPE9568F34-D428-11d2-A769-00AA001ACF42 [OR] 
RewriteCond %{QUERY_STRING} ^%3F=PHPE9568F35-D428-11d2-A769-00AA001ACF42 [OR] 
RewriteCond %{QUERY_STRING} ^%3F=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 [OR] 
RewriteRule ^(.*)$ - [R=404,L] 

Blind the elephant before it stomps you

Have you ever heard of BlindElephant? It's a very neat script which can be used to identify if your site is running Joomla! and even tell you the exact version with very high accuracy. It doesn't do any magic at all. All it does is download and process the well-known static resources of your site (CSS, Javascript and images). Each Joomla! version has slightly different files and, by deduction, it can figure out which Joomla! version you are using. It is certainly not the first tool to do that, but it's the only open source one which you can download without joining the digital underground.

One common flaw among all those fingerprinting scripts is that they do not try to spoof the referrer URL, i.e. they do not try to pretend that a web page from your site is actually requesting the file. This allows us to write some simple anti-leach rules, i.e. rules which do not allow static files to be referenced from anywhere outside our site. However, we need to add an exception to this rule. We want our images to be indexed by search engines – provided that we have modified the robots.txt file to allow that – so we need to add an exception for images/stories. The rules look like that:

RewriteRule ^(images/stories/*\.(jpe[g,2]?|jpg|png|gif|bmp|css|js|swf|htm[l]?))$ $1 [L]
RewriteCond %{REQUEST_FILENAME} -f 
RewriteCond %{HTTP_REFERER} !^http[s]{0,1}://(.+\.)?www\.example\.com [NC] 
RewriteRule \.(jpe[g,2]?|jpg|png|gif|bmp|css|js|swf|htm[l]?)$ - [R=404,L] 

The first line instructs our web server to unconditionally serve all jpe, jpeg, jp2, jpg, png, gif, bmp, css, js, swf, htm and html files from images/stories and any of their subdirectories. If you don't care about your images being indexed by search engines you can safely remove it.

Please note that in the last line the URL to the site, in this case www.example.com, has to be hard-coded with the dots “escaped” as backslash dot. If you forget this part, the rule will not work properly.

If you really want to dodge fingerprinitng attacks with utilities like BlindElephant and you leave that first line intact, you should also remove the following files and directories from your images/stories directory:

  • Directories: food, fruit

  • Files: articles.jpg, clock.jpg, ext_com.png, ext_lang.png, ext_mod.png, ext_plugin.png, joomla-dev_cycle.png, key.jpg, pastarchives.jpg, powered_by.png, taking_notes.jpg, web_links.jpg

Nothing is served from my site unless I know about it

This is my very own rule when building web-sites, similar to Brian Teeman's rule “Nothing goes in my website unless I put it there” from his famous “Joomla! Hidden Secrets” presentation. The idea is that nothing should ever come out of my site's server unless I have previously positively authorized it. You might wonder why I am so picky, so let me explain my obsession with this rule.

For starters, all Joomla! extensions come with a handy XML file – their “installation manifest” if you like the tech-talk – which has a predictable file name and location, as well as invaluable information, such as the extension's name and the exact version. This information not only tells a potential hacker which extensions you have installed on your site, but also if they have known vulnerabilities which they can exploit to gain unauthorised entrance to your site. In other words, these XML files must be muted and never served to random web visitors.

Then, we have the language directories and their INI files with all the languages available to your site. But how can a language string be a security threat? All by itself it can't, but you might have noticed that newer versions of Joomla! introduce new translation strings or modify some of the existing ones. In plain English, if I can get hold of your site's INI files I can tell within a small margin of error which version of Joomla! you are using. If I happen to know of a specific security vulnerability in that version, your site is doomed.

Most importantly we have PHP files. All of the extensions' PHP files are supposed to have one handy little line in their head to prevent direct access. It looks like this:

defined('_JEXEC') or die('Restricted Access');

We have two problems to face here. First, if this line exists, trying to access such a PHP file directly spits out “Restricted Access” which tells an attacker that you are running Joomla!. If this line is not there, either nothing will happen or – depending on how the PHP file is written and your server settings – might spit out debug information, such as the absolute path to your site. This can be used by a resourceful attacker to fabricate a directory traversal attack against a vulnerable extension on your site to read the contents of your configuration.php file and gain full access to your site. Oops Finally, most common attacks are based on exploiting a vulnerable component to inject a PHP file with malicious code inside your site and have the attacker run it in order to do nasty things, like infect your site with XSS code or even gain access to your site's back-end.

All of these attacks can be prevented very easily, knowing how Joomla! works. Ideally, your site should have only a handful of entry points, namely the index.php and index2.php files inside your site's root and the administrator and xmlrpc subdirectories. Despite that, many extensions provide their own entry points. For example, JoomlaWorks AllVideos have a file plugins/content/jw_allvideos/includes/jw_allvideos_scripts.php to supply their Javscript to the browser. Any such scripts have to be added as exceptions to our rules which block everything by default. A complete rule set with a sample exception would look like this:

## Allow JoomlaWorks AllVideos 
RewriteCond %{REQUEST_FILENAME} -f 
RewriteRule ^(plugins/content/jw_allvideos/includes/jw_allvideos_scripts\.php) $1 [L] 

## Back-end protection 
RewriteRule ^(administrator[/]?)$ administrator/index.php [L] 
RewriteRule ^(administrator/index.htm[l]?)$ $1 [L] 
RewriteRule ^(administrator/index.php)$ $1 [L] 
RewriteRule ^(administrator/index[2,3].php)$ $1 [L] 
RewriteRule ^(administrator/(components|modules|templates|images|plugins)/.*\.(jpe[g,2]?|jpg|png|gif|bmp|css|js|swf|htm[l]?))$ $1 [L] 
RewriteRule ^administrator/(.*)$ - [R=404,L] 

## Explicitly allow access only to XML-RPC's xmlrpc/index.php or plain xmlrpc/ directory 
RewriteRule ^(xmlrpc/index\.php)$ $1 [L] 
RewriteRule ^xmlrpc/(.*)$ - [R=404,L] 

## Disallow front-end access for certain Joomla! system directories 
RewriteRule ^(includes/js/.*)$ $1 [L] 
RewriteRule ^(cache|includes|language|libraries|logs|tmp)/.*$ - [R=404,L] 

## Allow limited access for certain Joomla! system directories with client-accessible content 
RewriteRule ^((components|modules|plugins|templates)/.*\.(jp[g,2,eg]?|png|gif|bmp|css|js|swf|htm[l]?))$ $1 [L] 
RewriteRule ^((components|modules|plugins|templates)/.*index\.php(.*))$ $1 [L] 
RewriteRule ^(templates/.*\.php)$ $1 [L] 
RewriteRule ^(components|modules|plugins|templates)/.*$ - [R=404,L] 

## Disallow access to htaccess.txt and configuration.php-dist 
RewriteRule ^(htaccess\.txt|configuration\.php-dist)$ - [R=404,L] 

SQLi shield: engaged

Another common attack vector is SQL injection (commonly referred to as SQLi) attacks against vulnerable components. The best way to deal with them is to have all of our extensions sanitize their input before passing it to the database. Most developers are aware of that and conform to this rule, but sometimes an extension developer is either unaware of this basic rule, or unwittingly dropped the ball while developing the extension. Even though it's impossible to write a single rule to block all SQLi attacks, Radek Suski – of SOBI2 fame – has proposed a simple rule set to block the most common SQLi attacks. It's certainly better than nothing, but I still suggest keeping an eye on Joomla!'s Vulnerable Extensions List and uninstall or immediately update vulnerable extensions on your site.

RewriteCond %{QUERY_STRING} concat.*\( [NC,OR] 
RewriteCond %{QUERY_STRING} union.*select.*\( [NC,OR] 
RewriteCond %{QUERY_STRING} union.*all.*select.* [NC] 
RewriteRule ^(.*)$ - [R=404,L] 

The mother of all .htaccess files

Based on those simple rule sets we can come up with a master .htaccess file which can provide adequate protection against the most common “script kiddie” class of attacks against Joomla! sites. Do note that if you come up with an extension which no longer works after installing this .htaccess file, the easiest way to figure out why is using the Firefox browser together with its FireBug extension. Simply enable FireBug for the page which doesn't work properly and switch to FireBug's Net panel. Reload the page and look for entries marked in red. Those which result in a 404 error have been blocked by the protection rules and you have to supply exceptions in your .htaccess file. Sample exceptions for a few popular extensions have already been added, but it's up to you to supply the perfect mix of exceptions for your own site. As always, your mileage may vary.

Enough talking, here is the .htaccess file's contents, resulting from the mix of Joomla!'s standard htaccess.txt with all the rules we discused about: my master .htaccess.

A ninja is perfectly capable of killing another ninja

The techniques presented above are only good as a first line of defence – and only work on servers capable of understanding mod_rewrite rules. They can let your site remain cloaked against the less sophisticated attackers, like a ninja is virtually invisible to the untrained eye. But, as the title of this article implies, a ninja can and will kill another ninja. The hidden message in this simile is that if a real hacker targets your website there's little you can do besides having a good and tested backup. Real hackers will not be fooled by your cloaking techniques and will certainly not be stopped by the rudimentary defense we've put in place. A real world hacker might not even attack your site only on the Joomla! level. Most usually he'll combine a wealth of lower level attacks to gain access to your site.

However, I don't think this is likely. Why? All the advanced techniques of a real hacker cost him time. Serious attackers only try to break into a site for experience (hackers) or profit (crackers). If the mark does not guarantee a high return for the time invested in breaking into it, a real hacker will not even bother. He has more important things to do. So, unless you are a high-profile government agency, public service facility or a high profile target the chances of a ninja-like hacker attacking you are minimal. In this case, I deem the protection measures outlined more than adequate.

Thanks for all the fish

This article wraps up this series of basic Joomla! security articles. It has been a great pleasure sharing this information with you, our readers and community. I am now asking for your help. I want your feedback about this series and your ideas about the topic of my next article. All ideas are welcome and, most certainly, will be seriously evaluated. The most promising will be turned into articles for upcoming issues. Don't be shy! Tell me what you'd like to know about Joomla! and I promise I will do my best to share my experience with you.

Read 98285 times
Tagged under Administrators
Nicholas K. Dionysopoulos

Nicholas K. Dionysopoulos

A Mechanical Engineer turned web developer I am mostly known as the lead developer of Akeeba Backup, the leading open source backup solution for Joomla!. When not working on my flagship software I enjoy squashing Joomla!bugs, writing articles about Joomla!, helping out with this magazine and playing the guitar.

avatar
great article!
I've seen your Master htaccess before, and was wondering if there was a comprehensive explanation for each item. Most sections are commented sufficiently, but it bugs me that I don't know exactly what each item is for - kind of like Brian's rule you referenced that nothing goes in his site without him knowing about it.
Great article though, can't wait for next months!
VOTES:0
avatar
I love this series and have tested the .htaccess file. I found two sections that gave a 500 error on the site, but the rest was ok.

Regarding blinding the elephant:

One thing that will give your site away no matter how well you hide everything that you have been talking about is the habit in the Joomla Community to leave a bit of "tagging" in an extension. I am talking about the infamous

"Powered by ....."

Do a search for "Powered by Kunena" and you don't have to run any other test to know that you are on a Joomla site.

I seriously think that there should be an explicit rule in the JED against any form of "Powered by" and links back to a developers site in the html. What is displayed on a site should be under total control of the site owner.

Is there a tool you can use to test your own site for security problems? The BlindElephant script will tell the version (if possible), but is there anything that can test a site?

Of course, this is a two edged sword - anything that can be used to find problems can also be used with intention to harm. But to me it would be better if I could use a tool to test my sites before anyone else do it. If something like this exist, it would be interesting to see an article describing how to audit your own site.
VOTES:0
avatar
Hi there, excellent article, thanks for a much needed and informative look at this tricky subject.

I'm atarting the slow and tedious process of hardening my sites and I'm trying to actually build test scripts to make sure a directive does what I think it should do. I'm having trouble getting the 'Visual Finger Printing' stuff to validate.

If I use the '[R=404,L]' flags I get a '500 server error on the front end and 'RewriteRule: invalid HTTP response code for flag 'R' on my system log.

If I use [R=301,L], [F,L] or other flags, the exploit gets through and displays the module positions. That server is Joomla 1.5.20, and Apache 2.0.63. Do you have any ideas what could be the issue?

Thank you for your efforts in helping our community and making the excellent Akeeba Backup product!
VOTES:0
avatar
This is a fantastic article Nicholas! Thank you very much for the advice.

Definately good practices to put in place.
VOTES:0
avatar
Since the people who need the most help are the most clueless, and the most clueless are likely to install the default Joomla .htaccess file, will J1.6 have a better htaccess file than J1.5 appears to?
VOTES:0
avatar
Nicholas K. Dionysopoulos Tuesday, 05 October 2010
There are pros and cons to having a more thorough default .htaccess. The case for it is that it will increase the security of a site. The downside is that on servers where .htaccess or mod_rewrite is not supported, it either gives a false sense of security or causes immediate white pages upon loading the site. As a result I consider it a bad idea for Joomla! to include such a .htaccess file by default.
VOTES:0
avatar
where are the other articles of this series?
VOTES:0
avatar
Nicholas K. Dionysopoulos Tuesday, 05 October 2010
Just click on my name and you'll see a list of all of the articles that I've written :)
VOTES:0
avatar
i think the article is insightful and you seem to have opened my eyes to certain possibilities i never thought of before now. But, what happens to someone with a very weak coding knowledge. all those code you mentioned in the article, how those one like me actually make use of them. i really want to secure my website.
VOTES:0
avatar
Nicholas K. Dionysopoulos Tuesday, 05 October 2010
There is an abundance of paid and free security extensions listed in extensions.Joomla.org. You can pick one of them. Sorry that I can't be more specific, but recommending a specific extension is against the fair play rules of this magazine.
VOTES:0
avatar
As I am not a developer at all, I can (and will) recommend whatever I care about :-)

For security, you should definitely take a look at tiny.cc/securityfix and for backup, you might want to take a look at tiny.cc/bestbackup .

Both of these tools are extensions that I install on ALL sites I make. Solid extensions and a real lifesaver! Don't ever make a site without them!
VOTES:0
avatar
I have implemented the easter eggs code in my .htaccess
but these templates still show.
Could it be related to sef?
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 07 October 2010
It's the %3F part. It doesn't work on all servers. You can try removing that and see if it works on your server.
VOTES:0
avatar
RewriteCond %{QUERY_STRING} (&|%3F){1,1}tp= [OR] 
RewriteCond %{QUERY_STRING} (&|%3F){1,1}template= [OR] 
RewriteCond %{QUERY_STRING} (&|%3F){1,1}tmpl= [NC] 
RewriteRule ^(.*)$ - [R=404,L]
You try to match the question mark by %3F but that won't work. One should use the following:
RewriteCond %{QUERY_STRING} (&|^){1,1}tp= [OR] RewriteCond %{QUERY_STRING} (&|^){1,1}template= [OR] RewriteCond %{QUERY_STRING} (&|^){1,1}tmpl= [NC] RewriteRule ^(.*)$ - [R=404,L] [code][code]
RewriteCond %{QUERY_STRING} (&|^){1,1}tp= [OR]
RewriteCond %{QUERY_STRING} (&|^){1,1}template= [OR]
RewriteCond %{QUERY_STRING} (&|^){1,1}tmpl= [NC]
RewriteRule ^(.*)$ - [R=404,L]
[code]
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 07 October 2010
Thank you for the hint! Which server and version did you try this on? Apache 2.2 seems to work with %3F
VOTES:0
avatar
I used Helicon Ape (APache Emulator) on IIS 7.5. However, the question mark (normally, besides those PHP Easter Eggs) is not included in %{QUERY_STRING}. So I'm wondering why Apache 2.2's mod_rewrite hasn't got a hickup
VOTES:0
avatar
Does anyone know how to prevent the Google Chrome Sniffer extension (www.nqbao.com/chrome-sniffer) from "sniffing" Joomla sites?
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 07 October 2010
This is just another case of fingerprinting software. The same rules apply, with a few extras that I left off the article (as I didn't want to self-promote my own software). The first thing as that you have to remove or modify the generator meta tag in your template file. The other thing is that Joomla! adds an HTTP header when you turn on the GZip encoding. Modifying it requires editing a core file or using a tool capable of doing so.
VOTES:0
avatar
I have GZIP Page Compressions off in the Global Config and I have my Generator Meta Tag set to a custom value, but still Chrome Sniffer picks up that we use Joomla. Any other ideas?

Thanks in advance!
VOTES:0
avatar
Chrome Sniffer detects Joomla! based on both the Generator tag ( easy to hide) and it looks for "components/com_" in the source code...which isnt that easy to hide


anybody has any ideas? what could we do without hacking our components to bits?
VOTES:0
avatar
Perhaps it would be a good idea to point something out to fellow total beginners with .htaccess files:

Do not use a Joomla file manager component such as Extplorer to put this file on your site, because when it makes your site totally inaccessible, you wont be able to fix it from within Joomla.
Instead use the file manager provided by your hosting account's CPanel, which will still allow you to edit the .htaccess file.

The specific problems that I had were in the Advanced Server Protection section:
This one killed the site template -
## Referrer filtering for common media files.
Solution was easy and obvious, do as it says and replace domain\.com with myowndomain\.co\.uk

This one kills the whole site -
## Disallow PHP Easter Eggs
Yikes, this looks pretty complicated. Here is the whole section
## Disallow PHP Easter Eggs (can be used in fingerprinting attacks to determine
## your PHP version). See www.0php.com/php_easter_egg.php and
## osvdb.org/12184 for more information
RewriteCond %{QUERY_STRING} ^%3F=PHPE9568F36-D428-11d2-A769-00AA001ACF42 [OR]
RewriteCond %{QUERY_STRING} ^%3F=PHPE9568F34-D428-11d2-A769-00AA001ACF42 [OR]
RewriteCond %{QUERY_STRING} ^%3F=PHPE9568F35-D428-11d2-A769-00AA001ACF42 [OR]
RewriteCond %{QUERY_STRING} ^%3F=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 [OR]
RewriteRule ^(.*)$ - [R=404,L]


I have no idea what it all means, but that last [OR] looks odd, I removed it and it worked!

And at the start of the file it says to replace domain.com and domain\.com with my own domain, but what am I supposed to do with this section - olddomain.net? :
########## Begin - Redirect olddomain.com to www.domain.com
RewriteCond %{HTTP_HOST} ^olddomain.net [NC]
RewriteRule ^(.*)$ www.domain.com/$1 [L,R=301]
########## End - Redirect olddomain.com to www.domain.com
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 07 October 2010
Yikes! That last [OR] is misplaced. I shouldn't have put it there. Good catch :)

The olddomain.net section, I thought it was self-explanatory. The header reads "Redirect olddomain.com to http://www.domain.com". You have to change both domains and use it if and only if you want to redirect an old domain to the new one. This is what I do to transparently redirect traffic from www.joomlapack.net to www.akeebabackup.com
VOTES:2
avatar
Hi Nicholas,
First this is just an excellent article like the rest of your articles.(I always try hard to follow whatever you write).
The topic of your next article could be how to speed up joomla,sometimes loading multiple pages takes time compared to other cms and webistes with almost the same content.
Even another security article would be most welcomed.
Thanks
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 28 October 2010
Ah, that sounds like a Mythbusters challenge :) The truth is that all you have to do is get rid of plugins and modules you don't really use (or can be replaced with something less resource intensive) and then start using a CDN on your site. Doing those tricks on my own business site improved the page speed by an astounding 250%.
VOTES:1
avatar
Thanks will try using CDN for my website also I have tried removing unwanted extensions but that did not do the trick will try this.Hope it helps thanks again
VOTES:0
avatar
Great article. Hopefully will not put the non-technical people off - if they ask their hosting company or developers for assistance in implementing then the job is half done. Awareness is the starting point that is too often ignored.
VOTES:1
avatar
I have tried the blindelephant code on my site but it messes up the template.
Could it be because my site is in a subdirectory?

How should the code be changed if the joomla is in a subdir: e.G. www.sitename.com/subdir
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 28 October 2010
I have since updated my .htaccess file and made it available on-line at snipt.net/nikosdion/the-master-htaccess/

As a bonus tip, the file on the link above is the exact .htaccess file being generated by my distributed-for-a-fee Admin Tools Professional software with all the options turned on. Yes, I am really giving away the secret recipe for my special sauce :)
VOTES:0
avatar
Thanks for this insightful article! By the way: for some reason the part of the article after the image of the ninja isn't rendered on the iPhone. Perhaps it has something to do with the following?

VOTES:0
avatar
the visual fingerprinting code blocks the preview article in the backend

-> error message:
The requested URL /administrator/index.php?option=com_content&id=1045&tmpl=component&task=preview was not found on this server.
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 28 October 2010
I have since updated my .htaccess file and made it available on-line at snipt.net/nikosdion/the-master-htaccess/
VOTES:0
avatar
WOW , great great Article and being a security enthusiast i'll share it to the masses ..
VOTES:0
avatar
Hi Nick. I am a big fan of yours. Use your akeeba backup pro. And always waiting for your articles. This is very good. I'm sharing this with my joomla's friend in the Facebook. Thanks again.
VOTES:0
avatar
Consider also adding these to the list

## Deny access to extension xml files

Order allow,deny
Deny from all
Satisfy all


and these from old Joomla! 1.0 times

# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a tag in URL
RewriteCond %{QUERY_STRING} (\|%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})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]

I like also to implement basic anti bandwidth stealing for my images = more performances

# avoid bandwidth stealing by redirecting people using my picture in form to a fix page/home
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?waltercedric.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?wiki.waltercedric.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?forums.waltercedric.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?bugs.waltercedric.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?demo.waltercedric.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?demo2.waltercedric.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mirror.waltercedric.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?images.google.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?.google.com(/)?.*$ [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp|zip|css)$ www.waltercedric.com [R,NC]
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 28 October 2010
Hello Cedric,

Well, this article only scraped the surface. My complete master .htaccess file can be found on-line at snipt.net/nikosdion/the-master-htaccess/ and includes your tips and much, much more.

BTW, the XML files rule didn't come up correctly, as the commenting software strips out all XML tags ;)
VOTES:0
avatar
anti-Visual fingerprinting tips are not working for me :(
I've tried all combination here, but no luck

By the by, my apache version is 2.2.16 and using .htaccess file
VOTES:0
avatar
Nicholas K. Dionysopoulos Thursday, 28 October 2010
As I just replied above, try my Master .htaccess
VOTES:0
avatar
Great work, thanks for sharing... :)
VOTES:0
avatar
Thanks for all your work. I am having trouble trying to figure out why a redirect file results in permission error. I have a redirect index.html file inside a directory with a short name to make a short URL to put in a news release, i.e. domain.com/foo would redirect to domain.com/index.php?option=com_content&view=article&id=386

Your master htaccess file won't allow that, but I can't figure out why. Any suggestions?
VOTES:0
avatar
I found the offending line the prevents an html redirect file from working...

RewriteRule .(jpe[g,2]?|jpg|png|gif|bmp|css|js|swf|htm[l]?)$ - [F,L]
VOTES:0
avatar
Thanks, Nicholas! Much needed and much appreciated.
VOTES:0
avatar
Hi

Nice and well written article.
I'm probably wrong but I have a question.
Isn't it the quickest way to check whether a site is made with joomla just to have a look at the robots.txt file?
All those Disallows speak by themselves.
Is there any known protection for this.
VOTES:0
avatar
Great article. I have really enjoyed reading it.
VOTES:0
avatar
great tips thanks Wednesday, 11 May 2011
thanks great tips
VOTES:0
avatar
Milan Solaris Monday, 23 May 2011
Hey, thanks for the article, I just found that my Joomla installation is so "drillable" like a swiss cheese! I will definitely have to work on those security issues which I certainly was not aware of!!!
VOTES:0
avatar
Oh that's a great Post...
VOTES:0
avatar
Kenneth Jørgensen Monday, 14 November 2011
After hearing your seminar on Joomladay Denmark. I have set out to read your articles more firmly. Since my knowledge i website security is limited. But i like it to be of the same standard my own systems are at home.
I only have good things to say about your articles, and your seminar in Denmark aswell. The reason is simple. You tell what needs telling in a simple way, so everyone (even newbies in Joomla!) can understand. Even the code bits, you make easy for everyone to understand. Something many "nerds" in their own fields, se as a daily struggle.
In short, you get the message across and i for one are greatful for that.

Kind Regards

Kenneth Jørgensen
VOTES:0
avatar
Hi, First of all great article it was a great help in setting up my first site. Just run into a snag.

I have a module that calls a php file in the modules folder the only way to make it work is to add the php file to the line below, which I assume maybe defeats the purpose.

RewriteRule ^((components|modules|plugins|templates|libraries)/.*\.(jp[g,2,eg]?|png|gif|bmp|css|js|swf|htm[l]?))$ $1 [L]

Is there are way in which i can only allow access to that one and only file thats located in modules/mod_something folder? Been racking my brains out.
VOTES:0
avatar
Thanks for the article and some of the answers. I am considering the use of Joomla but have to admit I get a bit scared by the tittle and some of the text here! the advices are good and all in all it is clear it is much better to only start a joomla project if the rigth person can get on to work on it.. Thanks again
VOTES:0
avatar
Thanks for some interesting insights... Much appreciated...
VOTES:0

Language Switcher