PHP Parser

[lengsel]

Mal ne eher akademische (und vermutlich überflüssige) Frage:

Wenn mit einem Client eine php-Datei auf einem Server aufgerufen wird, geht sie ja erstmal (aus gutem Grund) an den Apache zum parsen, der dann den generierten HTML-Code an den Client weiterreicht.
Soweit zur Praxis.

Jetzt die Frage:
Wäre es (wenn ja, wie?) möglich einen entsprechend präparierten user-agent-String im Request zu übermitteln, der die Datei glauben lässt, sie übergibt ihren php-Code dem Apache, tatsächlich aber ungeparst beim Client landet? Ich vermute mal nein.

Hoffentlich war das wenigstens halbwegs verständlich formuliert...

Grüße,
Flo

 

[michis0806]

Nein, wenn das gehen würde, wäre es ein Sicherheitsloch, da ja in PHP-Dateien regelmäßig z.B. mysql-Passwörter abgelegt sind...

 

[lengsel]

Danke, das hatte ich ja bereits erwähnt auch schon vermutet. Ich wollte es aber wohl nicht wahr haben...manchmal hilfts einfach etwas von anderen bestätigt zu bekommen.

Grüße,
Flo

 

[Nogger]

Wenn mit einem Client eine php-Datei auf einem Server aufgerufen wird, geht sie ja erstmal (aus gutem Grund) an den Apache zum parsen, der dann den generierten HTML-Code an den Client weiterreicht.

Nicht ganz.

Es kommt eine Anfrage beim Apache an. Angeforderte Ressource ist /test.php

Apache schaut nach, welche reale Datei der Ressource /test.php zugeordnet ist (hier: /var/www/test.php).

Apache sieht in der Konfiguration, daß für *.php Dateien das PHP-Modul (der PHP-Parser) aufgerufen werden soll.

Also aktiviert Apache das PHP-Modul und übergibt ihr die /test.php Datei und wartet auf die Rückgabe.

PHP arbeitet und übergibt das Ergebnis an Apache.

Dieser übergibt das Ergebnis dann als Antwort auf die Anfrage an der Client ("hier, das ist /test.php").

Verbindung wird geschlossen.

Vereinfacht gesagt.

Die (optionale) user-agent Angabe spielt da keine Rolle.

Wäre es (wenn ja, wie?) möglich einen entsprechend präparierten user-agent-String im Request zu übermitteln, der die Datei glauben lässt,

Eine "Datei" ist passiv. Sie ist Objekt von Aktionen, sie agiert nicht selbst. Sie kann nicht "glauben".

sie übergibt ihren php-Code dem Apache, tatsächlich aber ungeparst beim Client landet? Ich vermute mal nein.

Man kann natürlich den Apache entsprechend konfigurieren.

Es kommt eine Anfrage beim Apache an. Angeforderte Ressource ist /test.php, User-Agent ist "Source-Viewer".

Apache schaut nach, welche reale Datei der Ressource /test.php zugeordnet ist (hier: /var/www/test.php).

Apache sieht in der Konfiguration, daß beim User-Agent "Source-Viewser" die Datei direkt an den Client zurückgegeben werden soll (Ausnahme zu der Regel, daß für *.php Dateien das PHP-Modul aufgerufen werden soll.)

Apache liest die Datei ein und übergibt sie als Antwort auf die Anfrage an der Client ("hier, das ist /test.php").

Verbindung wird geschlossen.

Vereinfacht gesagt.

Ich habe aber noch nie gehört, daß sich jemand so eine Konfiguration betreibt Wozu auch.

 

[baumschubser]

Nein, wenn das gehen würde, wäre es ein Sicherheitsloch, da ja in PHP-Dateien regelmäßig z.B. mysql-Passwörter abgelegt sind...

Wobei das ja mal ziemlich "pfui ba" ist, um es noch nett auszudrücken. Passwörter werden über `ne externe Datei included die in einem mit htaccess geschützten verzeichnis liegt. So !

 

[maceis]

Wobei das ja mal ziemlich "pfui ba" ist, um es noch nett auszudrücken. Passwörter werden über `ne externe Datei included die in einem mit htaccess geschützten verzeichnis liegt. So !

Noch besser ist es, wenn diese Datei außerhalb der DocumentRoot des Apachen liegt. Es bieten aber nicht alle hoster ein solches Verzeichnis an.

 

[wegus]

ganz elegant ist nat. die Speicherung der User-Paßworte in einer DB!
Wobei dann wieder das Problem des DB-Passwords für die Zugangsdaten übrig bleibt !

 

[michanismus]

am sichersten ist wohl die variante des includes, ausserhalb des DocumentRoot, wie maceis schon sagte. nur der nötige shell zugriff ist dann bedingung

 

[maceis]

am sichersten ist wohl die variante des includes, ausserhalb des DocumentRoot, wie maceis schon sagte. nur der nötige shell zugriff ist dann bedingung

Nicht unbedingt.
Es gibt Provider, die bieten den Benutzern neben der Documentroot Verzeichnis noch ein oder mehrere Verzeichniss(e) z. B. für Datanbankbackups und eben für files an, auf die man einfachen ftp-Zugriff hat.
IMHO eigentlich eine sehr gute Lösung, da sie den Interessen des Kunden und denen des Providers Rechnung trägt.

 

[wegus]

Das Speichern von Paßworten ist nat. auch immer eine Frage der gewünschten Sicherheit. Es gibt diverse Möglichkeiten. Hier nur einige:

(1) analog zu .htacess und .htpasswd weitere Dateien vom Apache kaschieren lassen. Auf diese Dateien kann per http nicht zugegriffen werden und sie können (auch) paßworte enthalten.

(2) Paßworte nur und ausschließlich in PHP-Dateien abspeichern. Die Paßworte können nur gelesen werden, wenn PHP-Code ausgegeben und nicht interpretiert wird. Das ist nur dann der Fall, wenn Apache ohne PHP läuft. Achtung: Der Provider kann einem da eine böse Falle stellen...

(3) Paßworte codieren und deren Generierung auf mehrere PHP-Dateien verteilen. das Paßwort ist damit nicht besser gesichert als in (2), wer es aber haben möchte muß ein wenig Fleißarbeit leisten. In der Regel reicht eine solche Absicherung aus,
wenn das Paßwort regelmäßig gewechselt wird.

(4) Paßworte gar nicht speichern, sondern eingeben lassen ( als Zugangsberechtigung). Sprich User-Passwd ist DB-Passwd und wird in einer Session gehalten. Da diese Daten den Server nicht wieder verlassen ist das ausreichend sicher. Allerdings erfordert diese Lösung die Nutzung von n DB-Usern oder aber die tollerierung das sich n-Nutzer ein gleiches Paßwort teilen ( was nur selten Sinn macht).

 

[maceis]

(5) Die Passwörter (besser auch Datenbankname und Tabellen) werden in einer Textdatei gespeichert, die man im cgi-bin Verzeichnis abspeichert. Der direkte Zugriff auf cgi-bin ist i. d. R. providerseitig schon ausreichend abgesichert.
Beim Login-werden diese Daten ausgelesen.

(6) Ein Verzeichnis in dem auschließlich der php-Code für das login steht.
Dieses Verzeichnis wird per .htaccess geschützt, so dass kein Zugriff von außen möglich ist. Ein zusätzlicher Schutzeffekt entsteht dadurch, dass der Name des Verzeichnises und der php-Datei, die den Login-code enthält dem Benutzer normalerweise verborgen bleiben.
Der Logincode wir dann per include() in Seiten eingebunden, die auf die Datenbank zugreifen müssen.