Subunternehmer des Kunden aus der Hölle

[dedlfix]

Tach!

Weisst du, es gibt eine grosse Bandbreite von Aufträgen/Arbeitsstellen.

Und nicht nur das. Es gibt auch Projekte ohne Auftraggeber und ohne dass man die Bedingungen kennt oder festlegen kann, unter denen dann diese Anwendungen laufen sollen. Projekte wie - ich hab sie schon erwähnt - WordPress oder Joomla. MediaWiki ist noch ein weiteres. Diese sind also beliebt und man muss damit rechnen, dass sie unter anderem auf Plattformen mit nur minimalen Sicherheitsansprüchen laufen. Bei denen ist das Prinzip, nicht direkt auszuliefernde Daten außerhalb des DocumentRoots zu lagen, nicht anwendbar. Ganz zu schweigen von Konfigurationen über die .htaccess. In solchen Fällen ist es sicherer, die Konfigurationsdaten in PHP-Dateien abzulegen, die (wenigstens das sollte man voraussetzen können, sonst läuft ja gleich gar nichts von der Anwendung) nur geparst ausgeliefert werden, also wenn der Programmierer es nicht ganz verhauen hat, schlimmstenfalls keine verwertbare Ausgabe liefern.

1. Hoster, bei denen PHP-Dateien ausgeführt werden, alles andere an den Client ausgeliefert wird. Keine Möglichkeit, das Verhalten mit .htaccess zu beeinflussen. Alles liegt im doc root.

Sich nun hinzustellen, dass man unter solchen Bedingungen nicht arbeiten will, kann man als hochnäsig ansehen. Natürlich kann man im direkten Kundenkontakt versuchen, bessere Bedingungen auszuhandeln, beziehungsweise den Kunden von den Vorteilen einer besseren Umgebung zu überzeugen versuchen. Doch mit Projekten wie den oben genannten geht das eben nicht. Die Anwender werden das auf den schlimmsten Möhren installieren, derer sie habhaft werden können. Die Publicity, dass reihenweise solche Installationen erfolgreich gehackt worden sind, tut dem Projekt auch dann nicht gut, wenn man Prinzipien verwendet hat, die anderswo als State of the Art gewürdigt werden.

2. Hoster wie Nummer 1, bei denen man das Verhalten einzelner Dateien mit .htaccess beeinflussen kann

Für diese Fälle kann man eine vorbereitete .htaccess mitliefern, die den Zugriff auf wichtige Bereich gleich auf der Ebene sperrt. Da man aber immer noch 1. bedienen muss, kann man schwerlich auf solche Dinge wie leere index.html oder Configs in PHP-Dateien verzichten.

3. Hoster, bei denen man Dateien ausserhalb des doc root ablegen kann

Und dann wird es schon reichlich komplex, wenn man Installationsroutinen schreiben muss, für solche Fälle, bei denen man nicht genau weiß, wie das System aussieht. Der Anwender hat vielleicht auch nicht _die_ Ahnung, welche Pfadnamen anzugeben sind. Macht man die Angelegenheit zu komplex, leidet die Popularität. Zuzuschauen, wie ein sicherheitstechnisch perfektes System bei den Anwendern nicht ankommt, weil sie es nicht zu installieren in der Lage sind, ist auch nicht gerade erbauend.

4. Hoster, bei denen ein spezielles Verzeichnis für Skripte gedacht ist und alle anderen Dateien darin weder ausgeführt noch an den Client geliefert werden
5. Hoster mit Virtual Servern, auf denen man Root-Rechte hat
6. Managed Server
7. Firmen, die Root-Server mieten, um ihre Projekte darauf laufen zu lassen
8. Firmen, die Server in einem Serverraum in ihrem Bürogebäude stehen haben
9. Firmen, die mehrere Rechenzentren - geographisch verteilt - betreiben

Das braucht mindestens Fortgeschrittene bis Profis im echten Sinne, um Software in solchen Umgebungen zu installieren. Schön, wer das ist oder auf solches Personal zugreifen kann. Nützt aber für die obigen Fälle wenig.

Meine Arbeitsstellen erstreckten sich in der Vergangenheit über die Bereiche 7-9

Man könnte nun annehmen, dass du da ein wenig betriebsblind geworden bist und andere Anwendungsfälle aus den Augen verloren hast. Aber ich möchte dir da nichts unterstellen.

Ich weiss nicht, wieviele Hoster es da draussen gibt, bei denen das spezielle Problem mit der Config-Datei auftreten könnte (Nummer 1).

Genügend.

(Gibt es tatsächlich auch Hoster, die Geld nehmen und trotzdem kein .htaccess anbieten?)

Ob da Geld hinzulegen oder Werbeeinblendungen zu ertragen sind, spielt nicht die Rolle, wenn man frei verfügbare Software erstellen will. Man muss das einfach mit einkalkulieren.

Wenn ich eine Plattform für unsicher halte und ich mich anpasse, dann bin ich gut?

Wenn du es schaffst, Software zu entwerfen, die auch auf unsicheren Plattformen eine einigermaßen sichere Figur macht (wenn das überhaupt möglich ist und kein Widerspruch in sich ist), dann bist du gut. Wenn du es nur schaffen würdest, nach Prinzipien zu arbeiten, ohne ihre Nachteile auf bestimmten potentiellen Einsatzorten zu erkennen, dann wärest du nicht gut.

Vielleicht bin ich altmodisch, aber ich bin der Meinung, Software sollte auf möglichst
vielen Serverkonfigurationen ohne Änderungen lauffähig sein.
D.h. deine Software soll auch auf dem fraglichen Server mit dem Config-Problem sicher laufen. Ergo darfst du keine configs benutzen.

In dem Fall ist es jedenfalls nicht sonderlich ratsam, kritische Konfigurationen in anderer Form als PHP-Dateien abzulegen.

Die besten Prinzipien taugen nichts, wenn man sie ungeachtet der Bedingungen der realen Welt anwendet.
Und damit möchte ich die Diskussion dann auch eigentlich abschließen, die Argumente wiederholen sich jetzt schon mehr, als dass neue Erkenntnisse hinzukommen.

dedlfix.