Textdatei NUR für PHP lesbar machen?

[Chris]

Hi,
ich bin grad in den Anfängen ein neues CMS zu programmieren, welches wir unseren Webseiten-Kunden mitgeben können.

Nun sitz ich am Login.
Da ich mich entschlossen hab, das CMS komplett ohne Datenbank zu betreiben, um es auch auf "Schrott-Servern" funktionieren zu lassen, möchte ich, dass auch die Logindaten in einer Textdatei stehen.

Sicherheit ist so momentan allerdings 0! Jeder könnte die Textdatei rein theoretisch öffnen, wenn er wüsste, wo sie liegt, und die Zugangsdaten klauen. Natürlich wird in dem Skript bei Passwörtern nur MD5 benutzt, aber ich hab im Internet schon ne Reihe md5-decoder gesehn und bin mir nich sicher, ob md5 immernoch so super sicher is.

Um dem ganzen vorzubeugen wäre es optimal, wenn ausschließlich ein PHP-Skript auf die Datei zugreifen kann, man die TXT aber nicht einfach im Browser aufrufen kann.

Is das schon mit CHMOD möglich oder brauch ich da wieder mehr? Oder ist das gar nicht möglich?

Danke
Chris

[Tom]

Hello,

wer richtet denn den Host ein?

Bekommt jeder Kunde sein eigenes CMS?
Lassen sich die Files exact voneinander abgrenzen?
Haben die Kunden auf den Servern auch Konsolen-Zugang?
Gibt es einen FTP-Server?
Wie sollen die Dateien auf den Server geladen werden?
Läuft PHP als Modul oder als CGI oder ist das bei jedem Kunden anders?

Bisschen mehr Input bitte.

Generell sollten alle Daten, die nicht direkt über HTTP zugänglich sein dürfen, außerhalb der DocumentRoot des Webservers liegen. Dann kann man nur mit den passenden Scripten oder eben über die Konsole oder einen anderen Dienst darauf zugreifen.

Ein harzliches Glückauf

Tom vom Berg

[Chris]

Bekommt jeder Kunde sein eigenes CMS?

Jein, jeder Kunde bekommt ein an das Layout voreingestelltes CMS, aber kein eigenes.

Lassen sich die Files exact voneinander abgrenzen?

Hatte eigentlich vor, alle Dateien des Scripts in einen Ordner zu packen. (Sorry, wenns ne dumme Antwort war, hab die Frage warscheinlich falsch verstanden)

Haben die Kunden auf den Servern auch Konsolen-Zugang?

I.d.R nicht. Es sei denn, der Kunde bringt seinen eigenen Server mit Konsolen-Zugang. Wäre aber auch wurscht, der Kunde darf auf seine Passwort-Datei ja zugreifen. Und wenn er den Server vor äußerlichen Angriffen nicht ausreichend schützt, wäre das nicht unser Problem.

Gibt es einen FTP-Server?

Ja, in den meisten Fällen gibt es einen FTP-Server.

Wie sollen die Dateien auf den Server geladen werden?

Die Dateien werden fast immer per FTP auf den Server geladen. Wobei das spätere Einfügen von Inhalten bzw. die Erstellung neuer Content-Dateien ja das CMS übernimmt.

Läuft PHP als Modul oder als CGI oder ist das bei jedem Kunden anders?

Bis jetz lief PHP immer als Modul.

An die Möglichkeit, die Datei einfach in ein übergeordnetes Verzeichnis als htdocs zu packen und dann mit absoluten Pfadangaben zu arbeiten, hab ich noch gar nich gedacht.
Und ich glaube nicht, dass das dann so einfach zu knacken bzw. herrauszufinden wäre.
Auf die Möglichkeit, dass sich evtl. im Ordner ./cms/ ne passwd.txt (natürlich nur bsp) stecken könnte, kommen bestimmt viele, aber nicht darauf, dass sie in einem RootVerzeichnis liegen könnte.

Wobei es dabei ja noch nen anderes Problem gibt. Was ist mit den Webspaces, bei denen man per FTP nur direkt an den htdocs-ordner kommt und nicht an einen Überordner?

[Tom]

Hello,

Bekommt jeder Kunde sein eigenes CMS?

Jein, jeder Kunde bekommt ein an das Layout voreingestelltes CMS, aber kein eigenes.

An die Möglichkeit, die Datei einfach in ein übergeordnetes Verzeichnis als htdocs zu packen und dann mit absoluten Pfadangaben zu arbeiten, hab ich noch gar nich gedacht.
Und ich glaube nicht, dass das dann so einfach zu knacken bzw. herrauszufinden wäre.
Auf die Möglichkeit, dass sich evtl. im Ordner ./cms/ ne passwd.txt (natürlich nur bsp) stecken könnte, kommen bestimmt viele, aber nicht darauf, dass sie in einem RootVerzeichnis liegen könnte.

Wobei es dabei ja noch nen anderes Problem gibt. Was ist mit den Webspaces, bei denen man per FTP nur direkt an den htdocs-ordner kommt und nicht an einen Überordner?

Warum sollte das so sein?
"CustumerRoot", Customer-Home und DocumentRoot können vollkommen verschiedene Dinge sein.

Ich quäle mich auch gerade damit rum, weil einige User nun eine eingeschränkte SSH-Konsole bekommen sollen, Root aber auch über ssh auf den Server muss (also als User und dann su), es keine  unverschlüsselte Anmeldung und/oder Transfer mehr geben soll...

Das klassische FTP wird dann abgeschafft
Aber ich befürchte, dass ich da noch einen weiten Weg vor mir habe, bis es rund läuft.

Ein harzliches Glückauf

Tom vom Berg

[Chris]

Also ich habs mir grad ausprobiert.
Der Weg, den ich anfangs gehn wollte, funzt wunderbar.
Man gebe eine Datei CHMOD 707 und voilà, versucht man die Datei im Browser aufzurufen, gibts lediglich nen Forbidden.. ;) Skripte können aber weiterhin ungehindert auf die Datei zugreifen.

Weiß nich, ob das die sicherste Variante is, aber ausreichend denke ich, oder?

Trotzdem vielen Dank für eure Bemühungen! Werd mir die anderen Schritte auch mal angucken!

@Tom:
Ich hatte mal nen Linux Root Server von Strato.
Die beiden Programme für den Serverzugriff sind ja puTTy (konsole) und WinSCP (FileTrans).. bei beiden gibt es eine Möglichkeit eine speziell erstellte Schlüsseldatei generieren zu lassen.
Diese muss man dann MIT dem jeweiligen Programm laden und nur wenn auch die Kombination von Loginname, Passwort und KeyFile richtig ist, wird Zugriff gewährt.
Und diese Schlüsseldatei wird 256Bit verschlüsselt. Und ans nachgenerieren solcher Schlüsseldateien ist nichtmal zu denken.
Man hat mir damals nach einem Hackangriff mal erklärt, dies sei so ziemlich die sicherste Methode, um seinen Server zu sichern.

Wenn dir das Hilfreich sein könnte, sag mal bescheid (email oder so), dann guck ich nochmal wie das ging.

Grüße
Chris

[dedlfix]

echo $begrüßung;

Der Weg, den ich anfangs gehn wollte, funzt wunderbar.
Man gebe eine Datei CHMOD 707 und voilà, versucht man die Datei im Browser aufzurufen, gibts lediglich nen Forbidden.. ;) Skripte können aber weiterhin ungehindert auf die Datei zugreifen.
Weiß nich, ob das die sicherste Variante is, aber ausreichend denke ich, oder?

Die reinen Rechte für den Besitzer, die Gruppe und alle anderen sagen für sich allein nichts aus. Man muss dazu immer auch die Eigentümer und Gruppe der Datei sowie die Zugehörigkeit der beteiligten Parteien betrachten.

Wenn der Benutzer, unter dem PHP ausgeführt wird, zugreifen kann, aber der Webserver mit seinem Benutzer nicht, dann wird bei dir wohl PHP als CGI ausgeführt. Mit mod_php, bei dem der PHP-User gleich dem Webserver-User ist, ginge das beispielsweise nicht.

echo "$verabschiedung $name";

[Der Martin]

Hi,

Wobei es dabei ja noch nen anderes Problem gibt. Was ist mit den Webspaces, bei denen man per FTP nur direkt an den htdocs-ordner kommt und nicht an einen Überordner?
Warum sollte das so sein?

weil das -auch nach meiner Erfahrung- bei den Feld- Wald- und Wiesenhostern eher die Regel ist.
Der Zugriff auf andere Verzeichnisse "neben" oder oberhalb des DocRoot ist wohl nur bei den etwas "besseren" Angeboten selbstverständlich.

"CustumerRoot", Customer-Home und DocumentRoot können vollkommen verschiedene Dinge sein.

Können, sind aber oft nicht.

So long,
 Martin

[dedlfix]

echo $begrüßung;

Um dem ganzen vorzubeugen wäre es optimal, wenn ausschließlich ein PHP-Skript auf die Datei zugreifen kann, man die TXT aber nicht einfach im Browser aufrufen kann.

Anbieter von Webspace plus mehreren Domains bieten oftmals auch die Möglichkeit, jedem Domainnamen ein eigenes Unterverzeichnis zuzuweisen. Dann beginnt das Documentroot jeweils erst in diesen Unterverzeichnissen und man hat das Hauptverzeichnis als über HTTP nicht abfragbaren Ablageplatz zur Verfügung. Wessen Provider das nicht anbietet, hat ihn sich schlecht rausgesucht.

Is das schon mit CHMOD möglich oder brauch ich da wieder mehr? Oder ist das gar nicht möglich?

Man kann mit diversen Konfigurationen einen Zugriff auf bestimmte Ressourcen per HTTP verbieten. Doch das geht immer nur solange gut, bis man per Zufall oder Fehlkonfiguration dieses Verbot ausgehebelt hat.

echo "$verabschiedung $name";

[Tom]

Hello,

Anbieter von Webspace plus mehreren Domains bieten oftmals auch die Möglichkeit, jedem Domainnamen ein eigenes Unterverzeichnis zuzuweisen. Dann beginnt das Documentroot jeweils erst in diesen Unterverzeichnissen und man hat das Hauptverzeichnis als über HTTP nicht abfragbaren Ablageplatz zur Verfügung. Wessen Provider das nicht anbietet, hat ihn sich schlecht rausgesucht.

Beispiel für PHP als Modul

<VirtualHost *>
    ServerName selfhtml.bitworks.de
    ServerAlias www.selfhtml.bitworks.de

ServerAdmin [e-mail]

DocumentRoot /var/www/selfhtml.bitworks.de/htdocs

php_admin_value open_basedir /var/www/selfhtml.bitworks.de/
    php_admin_value upload_tmp_dir /var/www/selfhtml.bitworks.de/tmpdir/
    php_admin_value session.save_path /var/www/selfhtml.bitworks.de/sessions/

<Directory /var/www/selfhtml.bitworks.de/htdocs>
        AddDefaultCharset ISO-8859-1
#       CharsetDefault ISO-8859-1  #Funktion nicht mehr vorhanden in Ver2.2
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

ErrorLog /var/www/selfhtml.bitworks.de/logs/error.log

# Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

CustomLog /var/www/selfhtml.bitworks.de/logs/access.log combined
    ServerSignature On

</VirtualHost>

Und die Verzeichniseinrcihtung dann

drwxrwx---  5 www-data www-data 4096 2008-04-10 20:02 .
drwxr-xr-x 13 www-data www-data 4096 2008-04-10 20:02 ..
drwxrwx---  2 www-data www-data 4096 2008-04-21 00:56 data
drwxrwx--- 23 www-data www-data 4096 2008-04-20 10:44 htdocs
drwxrwx--- 23 www-data www-data 4096 2008-04-20 10:44 logs
drwxrwx---  2 www-data www-data 4096 2008-04-21 00:56 sessions
drwxrwx---  2 www-data www-data 4096 2008-04-18 18:02 tmpdir
84-16-224-202:/var/www/selfhtml.bitworks.de#

So kann der Domainbetreiber dann seine Daten mittels FTP in 'data' speichern. Er ist Mitglied in der Gruppe www-data, genauso wie der Webserver (user = www-data).

Durch die open_basedir Direktive greift PHP aber nur auf die Verzeichnisse dieses Virt Host zu und nicht auf die auf dem übrigen Server.

Mit PHP als CGI oder FastCGI geht es allerdings vollkommen anders :-)

Ein harzliches Glückauf

Tom vom Berg

[Paul]

Da ich mich entschlossen hab, das CMS komplett ohne Datenbank zu betreiben, um es auch auf "Schrott-Servern" funktionieren zu lassen, möchte ich, dass auch die Logindaten in einer Textdatei stehen.

Und warum so kompliziert?
Anstatt Endung Text könnte es doch die Endung php haben und die Logindaten
zwischen
<?php
/*
1;user;pass
2;user2;pass2
usw....
*/
?>

Da gibt es nichts zum runterladen nur ne leere Seite. Allerdings ist natürlich ausserhalb vom Root der sicherste Weg.

Paul

[Tom]

Hello,

Und warum so kompliziert?
Anstatt Endung Text könnte es doch die Endung php haben und die Logindaten
zwischen
<?php
/*
1;user;pass
2;user2;pass2
usw....
*/
?>

Das ist relativ unsicher, weil bei einem Ausfall des Parsers der Webserver dann die Files ggf. im Klartext ausliefern würde. Zumindest sollte ein zusätzlicher Schutz mittels .htaccess stattfinden, indem man das File z.B. .ht_logindata.php nennt. Das gilt für eine Standardeinrichtung bei Apache. Dort werden alle Files, die mit '.ht' anfangen, nicht per HTTP ausgeliefert.

Ein harzliches Glückauf

Tom vom Berg

[Paul]

Das ist relativ unsicher, weil bei einem Ausfall des Parsers der Webserver dann die Files ggf. im Klartext ausliefern würde. Zumindest sollte ein zusätzlicher Schutz mittels .htaccess stattfinden, indem man das File z.B. .ht_logindata.php nennt. Das gilt für eine Standardeinrichtung bei Apache. Dort werden alle Files, die mit '.ht' anfangen, nicht per HTTP ausgeliefert.

Hi Tom,
warum zitierst du 90% meiner Antwort aber der entscheidende Satz, eben das es nicht die sicherste Methode ist, zitierst du nicht?

Klar ist bei einem Ausfall des Parsers deine beschriebene Gefahr da, allerdings sind dann auch alle Scripte downloadbar und Funktionen und somit in sehr vielen Fällen Datenbanklogindaten, etc. anzeigbar.

Ich würde jetzt ja sagen deine beschriebene Gefahr sei von der Wahrscheinlichkeit eigentlich zu ignorieren, wenn tja, wenn mir nicht tatsächlich mal genau dieser Fall passiert wäre. Zu Anfangszeiten hatte ich mal mit .htaccess und der Möglichkeit rumgespielt eigene 404 fehler auszugeben. Die .htaccess war aus dem Netz und vollkommen OK und der Server von Verio. Bis heute weiss ich nicht warum, aber der Parser fiel aus und all meine schönen Scripte standen der Öffentlichkeit zur Verfügung, nicht nur das, auch alle .inc, .conf, usw.... Dateien.

Das war aber auch bis dato das erste und einzige Mal.

Aber nochmal, der sicherste Weg ist ausserhalb vom ROOT, zumal ich deine Idee schon ablehne, weil

1. bei vielen Billig-Angeboten wird eine .ht-Datei gar nicht erst angezeigt im FTP Bereich, schlecht zu warten.

2. Meine damalige Situation mir eine lebenslange .htacess-phobie in Bezug auf Verzeichnismanipulation gegeben hat.

Paul

[Vinzenz Mai]

Hallo Paul,

warum zitierst du 90% meiner Antwort aber der entscheidende Satz, eben das es nicht die sicherste Methode ist, zitierst du nicht?

Klar ist bei einem Ausfall des Parsers deine beschriebene Gefahr da, allerdings sind dann auch alle Scripte downloadbar und Funktionen

das ist in aller Regel erstens nicht schlimm, zweitens sollten sich die Funktions- und Klassenbibliotheken ebenfalls außerhalb der Documentroot befinden, erst recht ...

und somit in sehr vielen Fällen Datenbanklogindaten, etc. anzeigbar.

... solche Daten. Wenn dies nicht machbar ist, wäre dies ein Grund, den Provider zu wechseln.

Freundliche Grüße

Vinzenz

[Helmuth]

leg in den Ordner wo die txt-Datei liegt einfach eine .htaccess mit dem Inhalt:

order allow,deny
deny from all

Dann funkts!
Helmuth

[Tom]

Hello,

leg in den Ordner wo die txt-Datei liegt einfach eine .htaccess mit dem Inhalt:

order allow,deny
deny from all

Dann funkts!

Ja, dann kann gar keine Ressource aus dem Verzeichnis mehr per HTTP angefordert werden, bzw. es wird keine mehr ausgeliefert...

Warum nicht einfach einen passenden Namen für die Textdatei wählen?

.ht_textdatei.dat

auch ohne den Unterstrich oder Extension wird in der Standardkonfiguration des Apachen nicht ausgeliefert, alle anderen Ressourcen werden aber noch behandelt.

Ein harzliches Glückauf

Tom vom Berg

[Jonathan]

Hallo Chris,

Sicherheit ist so momentan allerdings 0! Jeder könnte die Textdatei rein theoretisch öffnen, wenn er wüsste, wo sie liegt, und die Zugangsdaten klauen. Natürlich wird in dem Skript bei Passwörtern nur MD5 benutzt, aber ich hab im Internet schon ne Reihe md5-decoder gesehn und bin mir nich sicher, ob md5 immernoch so super sicher is.

Bau halt noch Salt in den Hash ein. Du kannst natürlich auch zusätzlich einen stärkeren Hash verwenden, z.B. RIPEMD, aber für normale Anwendungen reicht MD5 mit Salt mehr als aus.

Jonathan