Ein paar Grundlagen

Viele kennen es, wenn WordPress versucht Dateiaktionen auf den Server durchzuführen, z.B. ein Plugin oder Theme zu installieren, wird man nach seinen FTP-Zugangsdaten gefragt. Dabei ist es egal ob man eine Archivdatei direkt hochlädt oder von einen entfernten Server ein Update einspielt. Der Grund dafür liegt nicht bei WordPress, sondern bei Unix bzw. einem Unix-ähnlichen Betriebssystem wie Linux. Die Unix-ähnlichen Betriebssysteme kennen nämlich verschiedene Dateiberechtigungen und vor allem Dateibesitzer. Wenn unter einem Unix-System der (FTP-) Benutzer A eine Datei anlegt, so kann auch nur der Benutzer A diese Datei beschreiben bzw. löschen. Benutzer A ist der Dateibesitzer und hat die volle Kontrolle über die von ihm angelegte Datei. Möchte der Benutzer A das die Datei auch von anderen FTP-Benutzern gelesen bzw. beschrieben werden kann, so müssen entsprechende Berechtigungen vergeben werden. Es gibt drei Gruppen denen man den Zugriff auf die Datei erlauben kann: Nur der Eigentümer (also derjenige der die Datei angelegt hat), eine Gruppe von FTP-Benutzern und Alle anderen (others oder public). Zudem kann auch noch die Art des Zugriffs geregelt werden. Möglich sind: Lesen, Schreiben und Ausführen.
Benutzer A könnte z.B. festlegen das die von ihm angelegte Datei nur von ihm beschrieben werden kann, jedoch z.B. alle FTP-Benutzer aus der Gruppe Tastatursklaven die Datei zumindest lesen können. Alle anderen FTP-Benutzer, so z.B. anonyme Gäste, können die Datei weder lesen noch sie beschreiben.

Dies ist ein grundlegender Schutz vor unberechtigten Zugriffen. Es wäre ja schon ein wenig fatal wenn jeder der will z.B. die Datei wp-config.php lesen, geschweige denn sie nach Lust&Laune verändern könnte. Dieser “Schutz” wirkt sich nun nicht nur auf Dateien aus, sondern auch auf Verzeichnisse. Dateien die in einem Verzeichnis liegen das nur vom Eigentümer gelesen werden kann, können nicht von anderen FTP-Benutzern gelesen werden, egal welche Dateiberechtigung die einzelnen Dateien haben.
Jetzt stellt sich natürlich die Frage was das alles mit WordPress zu tun hat. Schauen wir uns dazu erst einmal die “Ausnahme” an. Das wäre der Fall, wenn WordPress auf einem Server installiert ist auf dem PHP als so genanntes php-cgi läuft. Php-cgi ist eine ausführbare Datei und wird immer unter dem Konto des FTP-Benutzers ausgeführt. Wenn php-cgi also eine Datei auf den Server schreibt, hat die Datei als Eigentümer automatisch den FTP-Benutzer als Dateieigentümer.
Der andere Fall, der weitaus verbreiteter ist, ist der, dass PHP als Apache-Modul (php_mod) ausgeführt wird. In diesen Fall ist nicht der FTP-Benutzer der Dateieigentümer, sondern der Apache-Server, der so gesehen auch ein FTP-Benutzer ist, jedoch mit einen anderen Benutzernamen. Je nachdem wie der Server konfiguriert ist, variiert der FTP-Benutzername des Servers. Häufig ist dies “nobody”, aber auch “wwwrun”, “PHP-User” oder schlicht “PHP”. Welcher Benutzername der Apache-Server genau hat, muss also im Einzelfall jeder selber heraus finden, ist aber für das Verständnis gar nicht so wichtig.

Halten wir kurz fest:

• Unter Unix und Unix-ähnlichen Betriebssystemen haben Dateien und Verzeichnisse einen Besitzer
• Nicht jeder FTP-Benutzer kann auf alle Dateien und Verzeichnisse zugreifen
• Die Zugriffe auf Dateien und Verzeichnisse werden durch Zugriffsrechte geregelt
• Läuft PHP als Apache-Modul, so hat der Server einen eigenen “Benutzernamen” und hat dementsprechend auch Besitzrechte an den von ihm angelegten Dateien und Verzeichnisse.

Was passiert beim Upload?

Wenn wir nun versuchen Dateien oder Verzeichnisse in unser Blog hochzuladen, dann muss WordPress erst einmal feststellen wie es dies bewerkstelligen kann. Die einfachste Methode wäre natürlich WordPress würde die Daten einfach mal so auf dem Server ablegen. Genau genommen versucht WordPress dies auch, lässt es aber meistens aus Sicherheitsgründen sein. Um festzustellen ob WordPress die Daten direkt auf den Server speichern kann, schreibt es eine kleine Testdatei. Danach prüft WordPress ob der FTP-Benutzer mit dem Dateibesitzer der Testdatei übereinstimmt.
Im Fall von php-cgi stimmen die Besitzrechte überein und WordPress kann ohne weitere Nachfrage weiter machen.
Im Fall von PHP als Modul hat die Testdatei jedoch den Server als Besitzer und nicht den FTP-Benutzer. WordPress entscheidet sich in diesen Fall dagegen die Daten direkt auf den Server zu schreiben und sucht nach einer anderen Methode.

Natürlich stellt sich jetzt die Frage warum WordPress nicht doch einfach die Daten auf den Server ablegt. Der Grund liegt in den Zugriffsrechten und und einer Sicherheitslücke die sich (theoretisch) daraus ergibt.
Stellen wir uns mal vor Benutzer A und Benutzer B haben auf dem Webserver C jeweils einen Webspace gemietet. Alle Dateien und Verzeichnisse die von Benutzer A angelegt werden, können auch nur von Benutzer A gelesen und beschrieben werden. Genauso verhält es sich mit den Dateien und Verzeichnissen von Benutzer B. Was ist aber mit den Dateien und Verzeichnissen von “Benutzer C“? Benutzer C wäre in diesem Fall der Webserver. Und wenn der Webserver im Webspace von Benutzer A eine Datei anlegt, dann ist der Webserver der Besitzer dieser Datei. Da sich Benutzer A und B einen Webserver teilen, hat Benutzer B theoretisch über den Webserver Zugriff auf die Dateien im Webspace von Benutzer A, die vom Webserver angelegt wurden. Theoretisch könnte Benutzer B also den Webserver anweisen Dateien die er im Webspace von Benutzer A angelegt hat, auszulesen und im Webspace von Benutzer B zu kopieren. Möglich wäre dies, da der Webserver als Dateibesitzer ja die nötigen Rechte dazu hat.
Dies ist eine eher theoretische Sicherheitslücke. Theoretisch deshalb, da auf einen vernünftig konfigurierten Server so etwas nicht möglich sein sollte. Der Server sollte so konfiguriert sein, dass kein Benutzer auf Dateien oder Verzeichnisse außerhalb seines Webspaces zugreifen kann. Andernfalls könnte jeder Benutzer auch problemlos die Konfigurationsdateien des Webservers manipulieren.
Doch grau ist alle Theorie, die Praxis hat schon andere Fälle hervor gebracht. Und genau deswegen geht WordPress auf Nummer sicher und zieht es vor die Daten nicht direkt auf den Server abzulegen sofern es unter PHP als Apache-Modul läuft.

Kurz zusammen gefasst: Stellt WordPress fest das es nicht mit den gleichen Benutzernamen wie der FTP-Benutzer läuft, weigert es sich schlichtweg die Daten direkt auf den Server zu schreiben um nicht eine Sicherheitslücke bei den Zugriffsberechtigungen zu öffnen.

Und es nervt doch

Da PHP als Apache-Modul sehr verbreitet ist, werden auch viele WordPress-Nutzer regelmäßig nach ihren FTP-Zugangsdaten gefragt. FTP ist die zweite Variante mit der WordPress die Daten auf den Server bekommt. Dazu tut WordPress einfach so, als sei es der FTP-Benutzer unter dem der Blog angelegt wurde und der rechtmäßig Zugriff auf alle Dateien hat. Somit werden die Daten nicht mit dem FTP-Benutzer “nobody” (oder PHP-Run, oder PHP, oder oder oder) geschrieben, sondern mit dem von uns angegebenen Benutzernamen und Passwort.

Wer nur selten Daten auf seinen Server kopiert, den wird es nicht stören ab und an mal seine FTP-Daten anzugeben. Es gibt aber so einige Fälle wo es doch sehr nervig werden kann. Als Entwickler schiebt man ständig zu Testzwecken Daten auf den Server und löscht sie dort wieder. Das man auch beim Löschen von Daten die FTP-Zugangsdaten angeben muss, dürfte mittlerweile klar sein. Denn WordPress kann aufgrund der fehlenden Zugriffsberechtigungen nicht als Benutzer “PHP-Run” auf die Daten von FTP-Benutzer “Horst4711″ zugreifen.
Manchmal ist es aber auch einfach zu unbequem die FTP-Zugangsdaten, die sich natürlich kaum einer merkt weil das Passwort kryptisch³ ist, raus zu suchen. Und manchmal hat ausgerechnet der Mitarbeiter die FTP-Zugangsdaten, der gerade in Kambodscha Urlaub macht und nicht erreichbar ist.

Für solche Fälle gibt es einige Möglichkeiten die FTP-Zugangsdaten direkt in WordPress zu hinterlegen. Alle Möglichkeiten haben ihre Vor- und Nachteile. Einige sind sogar, m.E. nach, ein wenig gefährlich.

Speichern ist einfacher als raus suchen

Ab Werk kann man WordPress seine FTP-Daten also nur per Formular übergeben. Wer häufig unterwegs ist und sich dementsprechend genauso häufig in ungesicherte WLAN-Netzwerke einloggt (oder einloggen muss), wird immer ein mulmiges Gefühl haben wenn er die FTP-Zugangsdaten ungesichert quer durch die Bahnhofshalle zum Router schicken muss. Gerade wenn es um Kunden-Server geht ist hier etwas Vorsicht geboten. Falls jetzt jemand die Idee hat SSL wäre ja eine Lösung, der hat im Prinzip Recht. Jedoch denken die meisten Kunden da ganz anders. Wenn SSL extra kostet, dann braucht man das nicht. So denken zumindest die meisten Kunden.
Diese Lösung hat allerdings auch einen Vorteil. Legt man auf dem Server für jeden Admin einen FTP-Konto an, so kann Admin B nicht aus versehen (oder mit voller Absicht) die Dateien und Verzeichnisse von Admin A löschen oder überschreiben.

wp-config

Die erste Alternative zur Übertragung via Formular wäre die FTP-Zugangsdaten in der wp-config.php abzulegen. Dazu stellt WordPress drei Konstanten bereit: FTP_HOST, FTP_USER und FTP_PASS. Die Namen sprechen für sich und es dürfte klar sein für was die einzelnen Konstanten stehen. Wer mehr über die Konstanten von WordPress erfahren will, sollte mal einen Blick bei Dominik Schilling (G+ Profil)  rein werfen. Er hat eine umfangreiche Auflistung alle Konstanten.
Beispiel:

// defining the ftp-account data
if( ! defined( 'FTP_HOST' ) )
  define( 'FTP_HOST', 'meine-dmoain.de' );

if( ! defined( 'FTP_USER' ) )
  define ( 'FTP_USER', 'Horst4711' );

if( ! defined( 'FTP_PASS' ) )
  define( FTP_PASS', '&SchmierMaxe$0815!' );

Man sieht schon wo hier das Problem liegen könnte. Das Passwort liegt unverschlüsselt in einer PHP-Datei von der so ziemlich jeder Hacker weiß das dort was zu holen ist. Auf der anderen Seite steht in der selben Datei aber auch das Passwort für die Datenbank, ebenfalls unverschlüsselt. Man kann jetzt so oder so argumentieren. Die einen sind der Meinung das eh Hopfen&Malz verloren ist wenn die wp-config.php geknackt ist. Die anderen sagen das man einen Hacker nicht noch freien FTP-Zugang zum Server geben muss wenn er sich schon die Datenbank unter den Nagel gerissen hat.
Diese Methode spart auf alle Fälle die lästige Tipparbeit und man muss, sofern man mit mehren Mitarbeitern an einen Blog arbeitet, die FTP-Zugangsdaten nicht jedem aufs Auge drücken. Irgendwo gibt es immer einen der Zugangsdaten auf einen PostIt schreibt und diesen dann irgendwo vergisst oder verliert.
Hier wird deutlich das WordPress eigentlich ein Single-User-System ist dem man notdürftig eine Benutzerverwaltung aufgepflanzt hat. Denn so kann jeder Benutzer mit Admin-Rechten auf alle Dateien und Verzeichnisse zugreifen. Ob nun gewollt oder ungewollt. Es ist durchaus denkbar das Admin B ein Verzeichnis löscht oder überschreibt das von Admin A angelegt wurde und das auf gar keinen Fall gelöscht oder überschrieben werden durfte.

FS_METHOD

Eine andere Alternative zum Formular besteht darin, WordPress dazu zu zwingen die Daten direkt auf den Server zu schreiben. Indem man die Konstante FS_METHOD auf direct setzt, lässt man WordPress erst gar nicht dazu kommen auszuwählen ob es die Daten direkt oder per FTP auf den Server schreibt.
In meinen Augen ein Fauxpas sofern man dies auf einen Shared-Host anwendet. Für die möglichen Gefahren, siehe oben.
Nun ist aber nicht jedes Blog auf einen Shared-Host angelegt. Wer stolzer Besitzer eines eigenen Servers ist, kann diese Methode durchaus dazu nutzen den FTP-Upload zu umgehen. Wenn es auf dem ganzen Server nur einen FTP-Benutzer gibt, gibt es auch keinen zweiten der unberechtigt auf die Dateien zugreifen kann. Wobei man diese Aussage ein wenig relativieren muss. Denn als Apache-Modul ausgeführt, ist der Webserver natürlich auch ein FTP-Benutzer. Durch setzen der Konstante FS_METHOD auf direct, werden alle Dateien und Verzeichnisse mit dem Besitzer “Webserver” (oder so ähnlich) erstellt. Das kann in sofern problematisch werden, wenn in einem Plugin oder Theme “versehentlich” etwas wie exec( "rm -rf /" ); drin steht. Dann werden halt mal alle Dateien und Verzeichnisse die vom aktuellen Benutzer, sprich Webserver, angelegt wurden, gelöscht. Ohne Rückfrage versteht sich. Aber auch ein unlink() kann an der falschen Stelle mit dem falschen Pfad ausreichend Schaden anrichten.
Ein weiteres Problem dürfte zwar nur selten auftreten, ist mir persönlich aber durchaus schon mal passiert. Daten die vom Webserver geschrieben worden sind konnte ich als FTP-Benutzer nicht mehr löschen. Sicherlich auch eine Sache der Server-Konfiguration, man sollte aber vor Einsatz dieser Alternative erst einmal ausprobieren ob man denn die Daten die der Webserver geschrieben hat auch wieder löschen kann. Das Selektive Löschen einzelner Dateien oder Verzeichnisse kann sich dann sehr mühsam gestalten.

Die Konstante FS_METHOD kann jedoch auch sehr nützlich sein. Wir erinnern uns an php-cgi bei dem alle Daten unter dem Benutzernamen geschrieben werden. WordPress muss unter php-cgi nicht nachfragen ob es die Methode “direct” oder “ftp” benutzen soll, dadurch kann es gleich loslegen. Das ist vielleicht aber gar nicht immer erwünscht. Mit FS_METHOD können wir WordPress auch dazu zwingen FTP als Methode zu verwenden und jedes mal Benutzernamen und Passwort (und Hostname) abzufragen. Für Blogs die unter php-cgi laufen also ein kleiner Workaround wie man ganz einfach eine Authentifizierung vor dem Schreiben/Löschen von Daten erzwingen kann.

/*
 * force users to use ftp
 *
 * use 'ftpext' for using Apache FTP Extension
 * use 'ftpsockets' for ftp-sockets (Socket-Class or PHP-Extension)
 *
 */

if( ! defined( 'FS_METHOD' ) )
  define( 'FS_METHOD', 'ftpext' );

Obwohl ich hier nur mehr oder minder die Oberfläche angekratzt habe, sieht man schon wie komplex die gesamte Thematik ist. Gänzlich ausgeklammert habe ich z.B. die ganze Thematik um SSH/SSL, SFTP und das WordPress-Filesystem sowieso. Das ist genug Stoff für weitere drei oder vier Artikel.

Eine Plugin-Lösung

Meiner Philosophie zur Folge muss ein Blogartikel nicht komplett und vollständig sein, sondern vielmehr zum Nachdenken, Experimentieren und vor allem Diskutieren anregen. Sicherlich gibt es den einen oder anderen Aspekt den ich übersehen, falsch oder missverständlich dargestellt habe oder der mehr Interesse geweckt hat als der Artikel bedienen kann.
Genauso halte ich es auch mit meinen Plugins. Keine fertige Allroundlösung mit allen erdenklichen Features, sondern ein Lösungsansatz für ein Problem. Das folgende Plugin liegt in der Version 0.1 vor, ist also der erste Entwurf und eher ein PoC (Proof of Concept). Sowohl Artikel als auch Plugin sind beide an einen Tag entstanden, dementsprechend unausgiebig wurde das Plugin von mir getestet. Ich bitte dies beim Ausprobieren zu berücksichtigen.

FTP-Account to UserMeta

Dieses Plugin macht in etwa genau das was der (uninspiriert gewählte) Name aussagt. Es speichert die FTP-Zugangsdaten in den Benutzer-Daten des jeweiligen Benutzers. Damit sind zwei Anforderungen die im Laufe des Artikels aufgetaucht sind erledigt. Zum einen, und wichtigsten, muss man die FTP-Zugangsdaten nicht mehr ständig eintippen. Einmal im Benutzerprofil eingegeben stehen sie ab dann immer zur Verfügung wenn WordPress diese anfordert. Zum anderen können mehrere FTP-Benutzer ihre Daten hinterlegen da für jeden Benutzer separate FTP-Zugangsdaten gespeichert werden. Dadurch kann z.B. verhindert werden das Benutzer A die Dateien von Benutzer B versehentlich löscht, das Plugin kommt also aus der Ecke “Betreutes Bloggen”.

Das Plugin hinkt noch an der einen oder anderen Stelle. So werden die FTP-Passwörter (noch) im Klartext in der Datenbank gespeichert. Es sollte aber kein Problem darstellen eine entsprechende Ver- und Entschlüsselung nachzurüsten.
Auch fehlt noch die Unterstützung für SFTP/SSL da mir hierfür derzeit die nötige Umgebung fehlt (ja, ich habe weder SSL noch sonst was auf meinen lokalen Server. Nicht mal mod_ftp). Gegen Bereitstellung von etwas Platz auf einen entsprechenden Server mit SSL/SFTP bin ich gerne bereit das zu ändern Ansonsten muss man halt warten bis ich das auf meinem lokalen Server nachgerüstet habe.

Die Bedienung des Plugins ist recht simple. Nach der Installation und Aktivierung werden im Benutzerprofil drei Felder für FTP-Hostname, FTP-Benutzername und FTP-Passwort hinzugefügt. Sind die drei Felder ausgefüllt und wird das Profil aktualisiert, verschwindet ab diesen Zeitpunkt für diesen Benutzer die Aufforderung seine FTP-Zugangsdaten einzugeben sofern diese erforderlich sind. Alle anderen Benutzer die FTP benutzen können aber keine Zugangsdaten hinterlegt haben, werden weiterhin aufgefordert ihre Zugangsdaten bei Bedarf einzugeben.
Die Kontrolle darüber welche Benutzer überhaupt die drei Felder zu sehen bekommen, erfolgt hardcodiert im Plugin selber. Voreingestellt sind Administratoren (Role administrator), was wahrscheinlich am meisten Sinn macht. Es können aber auch andere Rollen bzw. Fähigkeiten (Capabilities) angegeben werden, womit eine recht feine Einstellung möglich ist wer seine FTP-Zugangsdaten eingeben kann.
Damit nach der Deinstallation des Plugins keine sensiblen Daten in der Datenbank verbleiben, werden diese bei der Deinstallation (nicht deaktivierung!) gelöscht. Sofern man das Plugin also über das Backend entfernt, kann man es gefahrlos ausprobieren.

Das Plugin findet ihr auf Github. Für diejenigen die es nicht so mit Git haben, als Zip-Datei. Die anderen dürfen gerne forken, pullen und commiten.

Update

Da das Plugin auf  einiges Interesse gestoßen ist, habe ich den Code mal etwas bereinigt und glatt gezogen. Neue Funktionen sind in dieser Version (v0.1.2) nicht hinzugekommen, dafür aber die eine oder andere Funktion für die nächsten Versionen notiert. Es wird sicherlich noch das eine oder andere umgesetzt werden, da ich hierdurch auch die Möglichkeit bekomme verschiedene Sachen auszuprobieren und ggf. darüber etwas zu schreiben.

Meistens ist ein Aufruf a lá http://www.example.com/wp-content/plugins/a-plugin/conection_data.php eher harmlos, da versucht wird das Script auszuführen anstatt es anzuzeigen. Nicht zuletzt bleibt aber jedoch die Möglichkeit via include(_once) und require(_once) das Script auch von entfernten Servern aus einzubinden und auszuführen.
Wie dem auch sei, ein mulmiges Gefühl bleibt immer zurück wenn jeder auf alle möglichen Dateien einfach per Browser oder PHP-Funktion zugreifen kann. Daher ist es bereits jetzt Best Practice seine Scripte und Dateien mit einer Kontrolle vor solch ungewollten Zugriffe zu schützen.

In vielen Plugins sieht man solchen und vergleichbaren Code

<?php 
  if ( ! defined( 'My_PLUGIN_VAR' ) ) 
    die( 'No direct script access allowed' );
?>

In der Plugin-Datei wird eine Konstante definiert (MY_PLUGIN_VAR) und in allen anderen Dateien wird abgefragt ob diese Konstante definiert ist. Ist sie es nicht, wurde womöglich direkt auf diese Datei zugegriffen was unerwünscht ist. Es gibt hier verschiedene Techniken diese Kontrolle durchzuführen.
Und die Plugin-Datei selber will ja auch noch davor geschützt sein direkt aufgerufen zu werden:

<?php 
  if ( ! function_exists( 'add_action' ) ) 
    die( 'No direct script access allowed' );
?>

Falls die Funktion add_action nicht definiert wurde, was darauf schließen lässt das WordPress nicht gestartet wurde, kann man von einem direkten Zugriff auf die Plugin-Datei ausgehen. Auch hier gibt es verschiedene Wege um zu prüfen ob WordPress bereits gestartet wurde oder nicht.

Das ist alles schön und gut, aber auch aufwendig und fehleranfällig. Stellen wir uns mal ein Plugin mit mehreren Unterverzeichnissen und in jedem Unterverzeichnis wiederum mehreren Dateien vor. Arbeitet man alleine an dem Plugin, ist es schon schwer den Überblick zu behalten ob man wirklich jede Datei geschützt hat. Bei einem Projekt an denen mehrere Personen mitarbeiten ist die Gefahr um so größer das einer der Mitarbeiter vergisst einen entsprechenden Schutz einzubauen. Und so wie Murphy es will, ist es ausgerechnet die Datei, mit den größten Schwachstellen die niemand kontrolliert hat.
Hinzu kommt das man mit diesen Techniken unter Umständen nicht jede Datei schützen kann. In JavaScript-Dateien wird es schon schwer mit diesen Techniken einen unerwünschten Zugriff zu verhindern. Spätestens bei CSS-Dateien müsste man gänzlich aufgeben.

Besser wäre es wenn man zentral regeln könnte auf welche Dateien zugegriffen werden darf und welche nicht. Der Apache Webserver bietet uns solch eine Möglichkeit in Form von .htaccess. Dazu benötigen wir im Grunde genommen nur zwei Regeln. Eine die die erlaubten Zugriffe beinhaltet und eine die die unerlaubten Zugriffe beinhaltet.

<FilesMatch "\.(php|xml)$">
    Order allow,deny
    Deny from all
</FilesMatch>

<FilesMatch "(\.txt|\.htm?l|index\.php)$">
  Order allow,deny
  Allow from all
</FilesMatch>

Im ersten Block verbieten wir sämtliche Zugriffe auf alle PHP- und XML-Dateien. Die Liste kann man noch um weitere Dateitypen erweitern, je nach Bedarf. Da wir aber nicht alle Zugriffe grundsätzlich sperren wollen, heisst ja readme.txt und nicht readme_not.txt, erlauben wir im zweiten Block den Zugriff auf bestimmte Dateitypen (.txt und .htm[l]), sowie auf die index.php. Auch hier kann man je nach Bedarf bestimmte Dateitypen und Dateien hinzufügen bzw. entfernen.
Das Beste an der Sache ist aber, es wirkt sich auch auf alle Unterverzeichnisse aus, wir müssen uns also keine Gedanken darüber machen ob nicht zufällig die eine Datei, die die Schwachstelle im System darstellt, nicht geschützt ist.

Wo viel Licht ist, ist natürlich auch viel Schatten. Denn auf anderen Webservern als den Apache (z.B. lighttpd, IIS, usw.) funktioniert das natürlich nicht. Entweder man legt für jeden Webserver dann entsprechende Konfigurations-Dateien an, sofern möglich, prüft auf die Server-Software und verweigert den Dienst oder nutzt diese Technik nur zusätzlich um auf Nummer sicher zu gehen.