如果你要列出针对你网站的威胁，哪一个会是首要威胁？对我来说，是脚本小子。那些没有编程天赋但仍然可以通过对网站使用预包装攻击造成大量伤害的讨厌鬼。他们的成功率非常高，这主要是因为我们的错误。本文的目的是展示一些简单的技巧，以在您的网站上增加一定程度的隐蔽性，使脚本小子无法发动攻击，即使他们发动攻击，也很可能成功防御。就像忍者一样，您将学习如何使您的网站在明处潜伏而不会被那些讨厌的攻击者发现。

在开始这篇文章之前，我想声明一些事情。我根本不相信 Joomla! 是一个易受攻击的应用程序或认为 Joomla! 开发者缺乏安全意识。相反，我认为 Joomla! 是迄今为止构建的最安全的 Web 应用程序之一。它的框架为开发者提供了所有必要的工具，以生产有用、令人惊叹且安全的扩展。我将要提出的许多安全问题都与所有知名 PHP 应用程序大致相同，包括其他两个大型 CMS。只是因为我为 Joomla! 社区杂志写作，并且我对 Joomla! 有特殊的热情，所以我才在 Joomla! 的背景下谈论这些关注点。现在请放松，开始悄悄地嘎嘎叫，因为...

...你的网站就像一只坐着的鸭子。嘎嘎！

很抱歉带来坏消息，但您的网站就像一只坐在鸭子，快乐地嘎嘎叫着，而捕食者却在它身边经过。简单地说，我们所有的网站都有些有趣的功能，通常用于调试，黑客可以利用这些功能来泄露我们网站的信息。这些信息本身并不会造成安全威胁，但恶意黑客可以利用它来判断您的网站是否容易受到攻击，然后再发起攻击。由于本文的目的是为您的网站添加一些忍者隐秘性，让我们来看看您的网站有多嘈杂以及我们可以做些什么。

视觉指纹识别

攻击者判断您的网站是否是潜在的Joomla!目标的一种最简单的方法是进行基本的视觉指纹识别。正如您所知，在您网站的URL中添加tp=1查询参数将触发模块调试模式，显示模板上所有模块的位置。这为网站正在运行Joomla!提供了明显的迹象。例如：[https://www.joomla.net.cn?tp=1](https://www.joomla.net.cn?tp=1)。

另一种更少为人知的方法是使用template=foobar查询参数，其中foobar可以是任何模板名称。这将把您的网站模板更改为指定的模板名称。如果您使用一个不存在的模板名称，它将尝试还原到默认（Milkyway）模板。例如：[https://extensions.joomla.net.cn/?template=foobar](https://extensions.joomla.net.cn/?template=foobar)

最后，我们可以通过使用tmpl=something查询参数来触发显示系统子模板。一个最实用的系统子模板是离线模板，即您将网站离线时显示的内容。看，妈妈，我能够让joomla.org看起来离线：[https://www.joomla.net.cn/?tmpl=offline](https://www.joomla.net.cn/?tmpl=offline)

避免暴露于这些恶作剧的方法是使用mod_rewrite .htaccess规则，将这些查询参数包括在内的所有URL都重定向到404页面

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有如此大的嘴巴

PHP是一种优秀的编程语言，但您想让全世界都知道您使用的是PHP的哪个版本，以便他们更容易地攻击您吗？我想不是这样，但PHP开发者似乎不同意您的看法。什么？您不相信我？PHP开发者决定在所有PHP可执行文件中包含硬编码的图像，当URL中存在特殊、非常长的查询参数时，这些图像将被显示出来。这些图像随着PHP版本的不同而变化，并且可以用来轻松地识别您的PHP版本。统称为PHP Easter Eggs，它们在您的网站上造成了巨大的安全漏洞，必须使用一些.htaccess魔法来阻止

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] 

在它踩您之前，先让大象失明

您听说过BlindElephant吗？这是一个非常棒的脚本，可以用来识别您的网站是否运行Joomla!，甚至可以非常准确地告诉您确切的版本。它根本不做任何魔法。它只是下载并处理您网站上众所周知的一些静态资源（CSS、JavaScript和图像）。每个Joomla!版本都有略微不同的文件，通过推理，它可以找出您使用的是哪个Joomla!版本。这当然不是第一个这样做的小工具，但它是最开放源代码的一个，您可以下载而不必加入数字地下世界。

所有指纹脚本中一个常见的缺陷是它们没有尝试伪造引用URL，也就是说，它们没有尝试假装一个来自您网站的网页实际上正在请求文件。这允许我们编写一些简单的反泄露规则，即不允许从我们网站之外的任何地方引用静态文件。然而，我们需要为这个规则添加一个例外。我们希望我们的图片被搜索引擎索引——前提是我们已经修改了robots.txt文件来允许这样做——因此，我们需要为images/stories添加一个例外。规则看起来是这样的

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] 

第一行指示我们的Web服务器无条件地提供来自images/stories及其任何子目录的所有jpe、jpeg、jp2、jpg、png、gif、bmp、css、js、swf、htm和html文件。如果您不介意您的图片被搜索引擎索引，您可以安全地删除它。

请注意，在最后一行中，网站的URL，在本例中为www.example.com，必须用点“转义”为反斜杠点进行硬编码。如果您忘记这部分，规则将无法正常工作。

如果您真的想使用BlindElephant等工具来规避指纹攻击，并且保留第一行不变，您还应该从images/stories目录中删除以下文件和目录

• 目录：food、fruit

• 文件：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

除非我知道，否则我的网站不提供任何内容

这是我在构建网站时的一个独特规则，类似于Brian Teeman在其著名的“Joomla! 隐藏秘密”演示文稿中提出的“我的网站上没有东西进来，除非是我放的”规则。这个想法是，除非我事先明确授权，否则我的网站服务器上不应该有任何东西流出。您可能会想知道我为什么如此挑剔，让我解释一下我对这个规则的痴迷。

首先，所有Joomla!扩展都附带一个实用的XML文件——如果您喜欢技术术语，就是它们的“安装清单”——它有一个可预测的文件名和位置，以及非常有价值的信息，例如扩展的名称和确切版本。这些信息不仅告诉潜在的黑客您在网站上安装了哪些扩展，而且还告诉他们是否有已知的漏洞，他们可以利用这些漏洞未经授权进入您的网站。换句话说，这些XML文件必须被屏蔽，永远不向随机网络访客提供。

然后，我们有语言目录及其INI文件，其中包含您的网站可用的所有语言。但是，一个语言字符串怎么可能是安全威胁呢？它本身不能，但您可能已经注意到，Joomla!的新版本引入了新的翻译字符串或修改了一些现有的字符串。用简单的话说，如果我能得到您的网站INI文件，我可以在小误差范围内知道您使用的是Joomla!的哪个版本。如果我恰好知道该版本中存在特定的安全漏洞，您的网站就完了。

最重要的是，我们有PHP文件。所有扩展的PHP文件都应该在其头部有一行便捷的小命令来防止直接访问。它看起来像这样

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

我们在这里面临两个问题。首先，如果这一行存在，尝试直接访问这样的PHP文件会显示“访问受限”，这会告诉攻击者你在运行Joomla！。如果这一行不存在，要么什么也不会发生，或者——取决于PHP文件的编写方式和你的服务器设置——可能会显示调试信息，例如你的网站的绝对路径。资源丰富的攻击者可以利用这一点对你的网站上易受攻击的扩展执行目录遍历攻击，读取你的配置.php文件的内容，并完全访问你的网站。哎呀，最后，大多数攻击都是基于利用易受攻击的组件在你的网站上注入恶意PHP文件，并让攻击者运行它来执行恶意的操作，比如用XSS代码感染你的网站，甚至访问你的网站的后端。

了解Joomla！的工作原理后，这些攻击都可以很容易地防止。理想情况下，你的网站应该只有少数几个入口点，即网站根目录中的index.php和index2.php文件，以及管理员和xmlrpc子目录。尽管如此，许多扩展提供了自己的入口点。例如，JoomlaWorks AllVideos有一个plugins/content/jw_allvideos/includes/jw_allvideos_scripts.php文件，向浏览器提供JavaScript。所有此类脚本都必须作为例外添加到我们的规则中，这些规则默认阻止一切。一个完整的规则集和示例例外看起来如下

## 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盾牌：已启用

另一个常见的攻击向量是针对易受攻击组件的SQL注入（通常称为SQLi）攻击。处理它们最好的方法是让所有我们的扩展在传递到数据库之前对输入进行清理。大多数开发者都知道这一点，并遵守这一规则，但有时扩展开发者可能不知道这项基本规则，或者在开发扩展时不小心疏忽了。尽管不可能制定一个单一的规则来阻止所有SQLi攻击，但SOBI2的Radek Suski提出了一个简单的规则集来阻止最常见的SQLi攻击。这当然比没有好，但我仍然建议你关注Joomla！的易受攻击的扩展列表，并立即卸载或更新你网站上易受攻击的扩展。

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

所有.htaccess文件之母

基于这些简单的规则集，我们可以制定一个主.htaccess文件，它可以为Joomla！网站提供足够的保护，以防止最常见的“脚本小子”类型的攻击。请注意，如果你安装了此.htaccess文件后某个扩展不再工作，最简单的方法是使用Firefox浏览器及其FireBug扩展。只需为工作不正常的页面启用FireBug，并切换到FireBug的Net面板。重新加载页面，寻找标记为红色的条目。那些导致404错误的结果已被保护规则阻止，你必须在你的.htaccess文件中提供例外。已经为几个流行的扩展添加了示例例外，但需要你自己为你的网站提供完美的例外组合。就像往常一样，你的效果可能会有所不同。

够说了，以下是主.htaccess文件的内容，它是基于Joomla！的标准htaccess.txt和我们讨论的所有规则混合而成的： 我的主.htaccess。

一个忍者可以完美地杀死另一个忍者

上述介绍的技术仅作为第一道防线——并且只有在能够理解mod_rewrite规则的服务器上才能有效。它们可以让您的网站对不那么复杂的攻击者保持隐藏，就像忍者对未受训练的眼睛几乎是不可见的。但是，正如这篇文章的标题所暗示的那样，忍者可以并且会杀死另一个忍者。这个比喻中隐藏的信息是，如果真正的黑客针对您的网站，您除了有一个良好且经过测试的备份外，几乎无能为力。真正的黑客不会被您的隐藏技术所欺骗，也不会被我们设置的基本防御措施所阻止。现实世界的黑客甚至可能不会仅在Joomla!层面攻击您的网站。通常，他将会结合多种低级攻击来获取对您网站的访问权限。

然而，我认为这不太可能。为什么？真正的黑客的所有高级技术都花费了他时间。严肃的攻击者只会尝试入侵一个网站以获取经验（黑客）或利润（黑客）。如果目标不能保证对破解时间的投资有高额回报，真正的黑客甚至不会费心。他还有更重要的事情要做。所以，除非您是高调的政府机构、公共服务设施或高调的目标，否则类似忍者的黑客攻击您的可能性很小。在这种情况下，我认为概述的保护措施是绰绰有余的。

感谢所有鱼类

本文总结了这一系列基本Joomla!安全文章。与您，我们的读者和社区分享这些信息是一大乐事。我现在请求您的帮助。我想了解您对这一系列的反馈以及您对我的下一篇文章主题的想法。所有想法都欢迎，并且肯定会认真评估。最有希望的想法将被转化为即将出版的问题的文章。不要害羞！告诉我您想了解的关于Joomla!的内容，我承诺我会尽我所能与您分享我的经验。