[h.ju]

Wie kann ich folgendes Problem lösen?

Wir hatten eben einen kurzen Serverausfall zu verzeichnen. Die Maschine führte im wiederanfahren einen Zustand herbei in dem der Apache schon reagiert, aber die php-enginge noch nicht. Somit wurde beim Request eines php-files browserseitig die Downloadoption angeboten.

Wenn das ein böswilliger Zeitgenosse mitbekommt, der weiß, das ein joomla verwendet wird, hat er in diesem Moment die Chance durch einen Request an
http://www.xyz.de/configuration.php sich eine Menge relevante Informationen einzuholen.

Mir ist jetzt extrem unwohl und ich werde das mysql-Passwört ändern, was ein wenig aufwändig ist, da einige lamp-Apps auf dem Server laufen.

Was wäre aber wenn ich nicht zufällig die Existenz des Szenarios im ersten Absatz mitbekommen hätte?

vgh

[admin]

Das ist eine gute Frage, die sich so leider nicht beantworten lässt. Es ist dann wirklich so, dass das ein Sicherheitsrisiko darstellt, das wir in der Form auch nicht absichern können. Hier wäre vielleicht der Hack von 1.0 ganz praktisch, mit dem man die configuration.php außerhalb von /html und somit auch nicht über den Browser aufrufbar ablegen kann. Somit ist diese von außen gar nicht einsehbar.

[h.ju]

Im IIS habe ich mir sagen lassen, ist es möglich festzulegen für bestimmte Dateitypen den direkten Request zu  unterbinden, so dass es beispielsweise konfigurierbar ist, nie eine .config-Datei zu senden. Ich weiß aber nicht, ob sich der alte Indianer diesbzgl. konfigurieren lässt.

Als Trost bleibt, dass m. E. SQL nur über localhost herbeiführen lässt.

Aber die Gedankenspinnerei verfolgt mich weiter:
Ich kann mir im derzeitigen Zustand die configration.php ein jeder Joomla-Konfiguration erschleichen, wenn ich es schaffe mit einer DoS-Attacke den Server zum Neustart zu bewegen und dann rechtzeitig mit einem Request nach der configuration.php  zuschlage?

Kann man diese Frage eventuell einmal vom Joomla-Entwicklerteam beleuchten lassen? Die bekommen doch einen Teil der Registrierungsgebühr 

vgh