Behandlung von Formularwerten

[Alex]

Hallo,

gibt es eine bestimmte System, wie man mit POST- und GET-Variablen umgeht, je nachdem, was man damit vorhat?

Ich frage mich nämlich bei dem ganzen Funktionen:
addshlashes, htmlentities, mysql_real_escape_string
und was es noch so gibt, wann ich was anwende. Also nach den Funktionen der Funktionen (klingt komisch ^^) würde ich jetzt vereinfacht sagen:

• htmlentities, wenn ich die Daten in HTML-ausgeben will
• mysql_real_escape_string, wenn ich die Daten in MySQL eintragen will

Liege ich damit in etwa richtig? Gibt es irgendwo ein Tutorial, für diese Funktionen. Ich bin zwar in der Lage, die einzelnen Funktionen zu ergoogeln, aber ich habe keine Seite gefunden, wo ich etwas allgemeines zur sicheren Behandlung von POST-/GET-Variablen finde und wann ich die mit welcher Funktion behandle.

Wen meine Fragen zu allgemein sind, ich habe folgendes vor (in Klammern jeweils meine derzeitige Behandlung der Variable):

1. POST-Variable (Einfacher Text ggf. mit Sonderzeichen) in MySQL-Datenbank eintragen (mysql_real_escape_string($variable))

2. Abfrage aus Datenbank wo Feldwert der POST-Variable entspricht (mysql_real_escape_string($variable))

3. Ausgabe der POST-Variable als Überschrift in HTML (htmlentities($variable))

4. Link aus POST-Variablen (z. B. bild.jpg) basteln. Etwa so:
           <a href="http://eineurl/<?php echo $variable_verzeichnis ?>/<?php echo $variable_datei ?>">Link</a>
      Wie sollte ich hier die POST-Variablen behandeln, wenn ich verhindern möchte, dass z.B. auf übergeordnete Verzeichnisse zugegriffen wird (z.B. wenn Inhalt von $variable_datei = ../../verzeichnis/datei.jpg)

Ist meine Behandlung in 1) bis 3) ausreichend (sicher)?
Lässt sich das möglicherweise garnicht so pauschal sagen und ist von Fall zu Fall zu entscheiden?

[Tom]

Hello,

gibt es eine bestimmte System, wie man mit POST- und GET-Variablen umgeht, je nachdem, was man damit vorhat?

Es gibt Daten.
Diese können in verschiedenen Umgebungen dargestellt, gespeichert und über verschiedene Medien transportiert werden. Beim Transport der Daten vom Browser zum Server spricht man von Parametern des Requests. Was der Server daraus macht, ist ihm überlassen.

Wenn die Werte im Script ankommen, sind es in aller Regel wieder Variablen, denn man hat einen Namen für sie und man kann sie mit Hilfe dieses Namens _ändern_

[Cheatah wollte uns das neulich noch plausibel zu Ende erklären, aber er wird vermutlich mit Schopenhauer noch nicht fertig sein *g*]

Die Daten in den Variablen sollten möglichst in einem neutralen Format, dem "Rohformat" vorliegen. Dieses wird nur bestimmt vom Datentyp und seiner Handhabung auf dem entsprechenden System. Dieses Rohformat sollte für alle anderen Zwecke als Grundlage dienen.

1)  Man kann damit arbeiten (z.B. rechnen)

2)  Man kann es speichern
3)  Man kann es transportieren
4)  Man kann es darstellen

Allerdings müssen die Daten für die Punkte 2-4 immer erst für die vorgesehene Operation vorbereitet werden.

Zur Ausgabe im HTML-Kontext (Browser) müssen sie z.B. mit htmlspecialchars() behandelt werden.
Weitere Behandlungsmethoden sind optional.
Sollen sie aber z.B. in einen Link eingebaut werden, müssen sie zusätzlich mit urlencode() vorbehandelt werden, damit dieser dann "transportbereit" zur Verfügung steht.

Bevor man Daten in eine Datenbank schreibt, muss man überlegen, ob dies über eine Textschnittstelle geschieht (hier werden Befehle und Parameter gemischt übergeben) oder über einen Blockpuffer. Im ersten Fall müssen die Daten "escaped" werden. Man muss alle Zeichen, die für die Textschnittstelle steuernde Wirkung hätten, in den Datenwerten maskieren, also besonders kennzeichnen. Dies übernimmt bei PHP-MySQL z.B. die Funktion mysql_real_escape_string().

Um dieses Escapen ordnungsgemäß durchführen zu können, müssen die Daten aber im Rohformat vorliegen und keinesfalls in einem bereits vorbehandelten. Damit dies bei PHP als Middleware auch funktioniert, muss man sicher sein, dass PHP die Daten an der INPUT-Schnittstelle nicht schon selber vorbehandelt hat. Dies geschieht z.B durch seine Funktionalität der Magic Quotes. Hier wird meistens bereits ein "Escaping" vorgenommen, dass aber nicht zum DBMS MySQL passt. Daher muss man dieses PHP-eigene Escapöing erst wieder rückgängig machen mit stripslashes() http://de3.php.net/manual/en/function.stripslashes.php oder man muss das Feature magic_quotes_gpc ausschalten http://de3.php.net/manual/en/function.get-magic-quotes-gpc.php, http://de3.php.net/manual/en/ref.info.php#ini.magic-quotes-gpc

Wenn man nun z.B. die Rohdaten in einem CSV-File speichern will, muss man sie ebenfalls erst vorbereiten. Denn in den Daten dürche sich keine Trennzeichen und keine Satzendezeichen befinden. Nun könnte man glauben, dass man die einfach entfernt, aber das würde die Daten verändern und vielelicht dadurch unbrauchbar machen. Also "verpackt" man solche Daten in sogenannte "Einschlusszeihen" = Begrenzerzeichen. Das einzige verbleibende Problem ist dann noch das Einschlusszeichen selber. Um dieses wieder unschädlich zu machen, wird es in einem Datenwert einfach verdoppelt. Die Lesefunktion weiß, dass sie ein doppeltes Einschlusszeichen _ohne_ dazwischenstehndes Trennzeichen als Datenwert und nicht als Steuerzeichen werten muss und kann so die Daten VERLUSTFREI wieder ins Rohformat zurücktransformieren.

Mehr Regeln fallen mir eigentlich nicht ein.

Alle anderen Bemühungen sind überflüssig.
(Hoffentlich habe ich jetzt nicht doch 'was wichtiges vergessen?)

Liebe Grüße

Tom vom Berg

[Gonzo]

gibt es eine bestimmte System, wie man mit POST- und GET-Variablen umgeht, je nachdem, was man damit vorhat?

Grundsätzlich vom Schlimmsten ausgehen.

Ich frage mich nämlich bei dem ganzen Funktionen:
addshlashes, htmlentities, mysql_real_escape_string
und was es noch so gibt, wann ich was anwende.

PHP ist ein Sammelsurium aus verschiedenen Quellen, einiges überschneidet sich daher; addslashes() und mysql_[real_]escape_string() sind zum Bleistift sehr verwandt.
htmlentities() hat eine abgespeckte Variante names htmlspecialchars(), sie verarbeitet nur <, > und &, also die wirklich sicherheitsrelevanten Zeichen. htmlentities() verwurstet darüber hinaus aus mehr oder weniger kosmetischen Gründen noch Zeichen jenseits Nummer 127. Die Funktion muss dazu aber wissen, welcher Zeichensatz angewendet werden soll, und diese Angabe wiederum lässt sich andernorts auch besser einbauen, zum Beispiel mit <meta http-equiv="Content-Type" content="text/html; charset=[was-auch-immer]">.

• htmlentities, wenn ich die Daten in HTML-ausgeben will
• mysql_real_escape_string, wenn ich die Daten in MySQL eintragen will

Grundsätzlich richtig.

1. POST-Variable (Einfacher Text ggf. mit Sonderzeichen) in MySQL-Datenbank eintragen (mysql_real_escape_string($variable))

Richtig.

2. Abfrage aus Datenbank wo Feldwert der POST-Variable entspricht (mysql_real_escape_string($variable))

Richtig. Das ist die gleiche Situation wie bei 1), du nimmst von draußen kommende Daten und baust sie in einen SQL-Befehl ein.

3. Ausgabe der POST-Variable als Überschrift in HTML (htmlentities($variable))

Richtig, wobei ich wie oben schon angedeutet htmlspecialchars() vorziehen würde.

4. Link aus POST-Variablen (z. B. bild.jpg) basteln. Etwa so:
           <a href="http://eineurl/<?php echo $variable_verzeichnis ?>/<?php echo $variable_datei ?>">Link</a>

Falsch.

<a href="http://eineurl/<?php echo htmlspecialchars($variable) ?>">Link</a>

Du hast htmlspecialchars() vergessen. Würde der Angreifer als Dateiname "></a><a href="http://boese.bu.ben/boeser/virus.html wählen (einschließlich des führenden Anführungszeichens), hätte er schon Code eingeschmuggelt und du hättest fürdahin eine Virenschleuder in deiner Empfehlungsliste:

<a href="http://eineurl/verzeichnis/"></a><a href="http://boese.bu.ben/boeser/virus.html">Link</a>

Das Aufteilen in Verzeichnis und Datei bringt darüber hinaus keinen Sicherheitsvorteil.

Wie sollte ich hier die POST-Variablen behandeln, wenn ich verhindern möchte, dass z.B. auf übergeordnete Verzeichnisse zugegriffen wird (z.B. wenn Inhalt von $variable_datei = ../../verzeichnis/datei.jpg)

Prüfe immer, ob der Wert deinen Vorstellungen entspricht, nicht umgekehrt, d.h. ob er deinen Vorstellungen widerspricht. Prüfe also in diesem Fall nicht, ob die unerwünschte Zeichenkette ../ drinsteckt, sondern ob der Wert einem erwünschten Pfad entspricht, zum Beispiel mittels preg_match('|^([a-z0-9_-]+/)*[a-z0-9_-]+.[a-z]+$|i', $variable);.

Bei einer Negativprüfung läufst du Gefahr, dass der Angreifer eine andere Lücke ausnutzt, die du nicht überprüfst. Diese Gefahr ist bei einer Positivprüfung zwar nicht ausgeschlossen, aber wesentlich geringer.

[Tom]

Hello,

4. Link aus POST-Variablen (z. B. bild.jpg) basteln. Etwa so:
           <a href="http://eineurl/<?php echo $variable_verzeichnis ?>/<?php echo $variable_datei ?>">Link</a>

Falsch.

<a href="http://eineurl/<?php echo htmlspecialchars($variable) ?>">Link</a>

Du hast htmlspecialchars() vergessen. Würde der Angreifer als Dateiname "></a><a href="http://boese.bu.ben/boeser/virus.html wählen (einschließlich des führenden Anführungszeichens), hätte er schon Code eingeschmuggelt und du hättest fürdahin eine Virenschleuder in deiner Empfehlungsliste:

Unvollständig!

Die gesamte URL muss auch URL-gerecht gebaut sein.
Das bedeutet, dass jeder einzelne Teil der URL auch URL-gerecht sein muss.
Jeder Parametername und jeder Parameterwert müssen einzeln url-codiert werden, z.B. mit rawurlencode() http://de2.php.net/manual/en/function.rawurlencode.php, um dann anschließend zu einer URi zusammengebaut zu werden. Die gesamte URi muss noch HTML-gerecht gemacht werden mit htmlspecialchars(). Erst dann kann man sie ohne Sorgen an den Client schicken.

Liebe Grüße

Tom vom Berg

[Blaubart]

Tach.

htmlentities() hat eine abgespeckte Variante names htmlspecialchars(), sie verarbeitet nur <, > und &, also die wirklich sicherheitsrelevanten Zeichen.

Jepp, zusätzlich jedoch auch noch die doppelten Anführungszeichen, wenn man keine anderlautenden Zusatzangaben beim Aufrufen der Funktion macht.

[ChrisB]

Hi,

4. Link aus POST-Variablen (z. B. bild.jpg) basteln. Etwa so:
           <a href="http://eineurl/<?php echo $variable_verzeichnis ?>/<?php echo $variable_datei ?>">Link</a>

Hoppla, wo ist die Behandlung fuer den Ausgabekontext HTML geblieben?

Wie sollte ich hier die POST-Variablen behandeln, wenn ich verhindern möchte, dass z.B. auf übergeordnete Verzeichnisse zugegriffen wird (z.B. wenn Inhalt von $variable_datei = ../../verzeichnis/datei.jpg)

Mach dir klar, welches Szenario hier (zusatzlich) vorliegt.

Mit dem htmlspecialchars geht es dir erst mal darum, die Zeichen "unschaedlich" zu machen, die im Kontext HTML eine Sonderbedeutung haben koennten.

Hier kommt jetzt der Kontext "Pfadangabe" hinzu (bloed gewaehlt, aber mir faellt gerade nichts besseres ein).
Da sind bestimmte andere Zeichen(kombinationen) ggf. "schaedlich". Natuerlich musst du erst mal vorher definieren, welche das sein koennten - mit "../ macht etwas, das ich hier nicht will" hast du ja bereits einen Fall gefunden.
Dann ueberlege dir, wie du damit umgehen willst - ganz verbieten (Daten mit Fehlermeldung ablehnen), entschaerfen (../ einfach rauswerfen), ...?
Stringfunktionen, regulaere Ausdruecke helfen dabei weiter.
Und in diesem speziellen Fall u.U. auch noch Funktionen wie basename, realpath o.ae.

MfG ChrisB

[dedlfix]

echo $begrüßung;

gibt es eine bestimmte System, wie man mit POST- und GET-Variablen umgeht, je nachdem, was man damit vorhat?

Die Einträge in den EGPCS-Arrays (.../$_GET/$_POST/...) sind zunächst einmal Eingabedaten. Auch Daten aus Dateien oder anderen Quellen wären das. Mitunter müssen Eingabedaten von ihrer "Transportsicherung" befreit werden.

Unter PHP kommt das Feature Magic Quotes hinzu, dass an der falschen Stelle die Eingabedaten bereits für eine bestimmte Ausgabe vorbereitet. Sie sind damit oftmals unbrauchbar für die eigentliche Verarbeitung und müssen erst einmal bereinigt werden, wenn man nicht die Magic Quotes generell deaktivieren kann.

Hat man die Eingabedaten in ihre Rohform gebracht kann man sie nun je nach Vorhaben verarbeiten.

Meist möchte man anschließend die Daten irgendwohin ausgeben. Viele Medien haben gemeinsam, dass sie sowohl Anweisungs- als auch Datenbestandteile in gemischter Form transportieren. Und da kommt der hier im Forum leider sehr oft notwendige Lehrsatz "Ausgabewerte müssen kontextgerecht behandelt werden!" zur Anwendung. Um über die angemessene Behandlung der Daten entscheiden zu können, muss sich man zunächst über den jeweiligen Kontext informieren, und welche Regeln für Daten dafür anzuwenden sind. Der Kontext HTML verlangt, die HTML-eigenen Zeichen in einer bestimmten Schreibweise. Der Kontext SQL (je nach Datenbank verschieden) verlangt die Notation einiger Zeichen in besonderer Form. Usw. usf. Manchmal sind mehrere Kontexte auf einmal zu beachten, z.B: Daten in einer URL, die in HTML eingefügt wird.

Ich frage mich nämlich bei dem ganzen Funktionen:
addshlashes, htmlentities, mysql_real_escape_string
und was es noch so gibt, wann ich was anwende.

Für die wichtigsten Kontexte im Webumfeld stellt PHP Funktionen zur Verfügung, die die Daten gemäß den Kontextregeln behandeln. Mitunter finden sich auch Funktionen, die zu unspezifisch sind (addslashes) oder zu viel machen (htmlentities).

• htmlentities, wenn ich die Daten in HTML-ausgeben will

htmlspecialchars() ist für den HTML-Kontext ausreichend. Die Zeichen, die htmlentities() außerdem noch behandelt, notiert man besser in einer passenden Kodierung (die man dem Ausgabemedium in geeigneter Form mitteilt).

• mysql_real_escape_string, wenn ich die Daten in MySQL eintragen will

Ja, das heißt: immer dann, wenn man ein SQL-Statement mit Datenbestandteilen zusammenstellt. Einige DBMS kennen Prepared Statements, bei denen Anweisung und Daten getrennte Wege gehen. In dem Fall ist keine Behandlung der Daten notwendig.

Liege ich damit in etwa richtig? Gibt es irgendwo ein Tutorial, für diese Funktionen. Ich bin zwar in der Lage, die einzelnen Funktionen zu ergoogeln, aber ich habe keine Seite gefunden, wo ich etwas allgemeines zur sicheren Behandlung von POST-/GET-Variablen finde und wann ich die mit welcher Funktion behandle.

Bei jedweden Daten, die irgendwohin ausgegeben werden sollen, muss der o.g. Lehrsatz berücksichtigt werden. Das betrifft also nicht nur Werte, die per GET/POST übertragen wurden.

Da immer wieder Fragen und Scripte hier auftauchen, die dieses Thema nicht berücksichtigen, ist das Archiv voll von diesbezüglichen Informationen.

4. Link aus POST-Variablen (z. B. bild.jpg) basteln. Etwa so:
      <a href="http://eineurl/<?php echo $variable_verzeichnis ?>/<?php echo $variable_datei ?>">Link</a>

Du hast hier den Kontext URL, der sich in zwei Teile aufteilt, wovon du aber nur einen dargestellt hast. Und diese URL kommt im Kontext HTML zu stehen. Du benötigst eine URL-gerechte Behandlung der Daten und anschließend eine HTML-gerechte Behandlung der URL.

Werden Daten im Pfad-Teil transportiert, ist rawurlencode() die passende Funktion. Für den Querystring-Teil ist es urlencode(). Und für HTML kommt dann noch htmlspecialchars() zum Einsatz.

Wie sollte ich hier die POST-Variablen behandeln, wenn ich verhindern möchte, dass z.B. auf übergeordnete Verzeichnisse zugegriffen wird (z.B. wenn Inhalt von $variable_datei = ../../verzeichnis/datei.jpg)

Das ist kein Thema der Ein- und Ausgabedatenbehandlung. Das ist eine Prüfung im Zuge der Datenverarbeitung. Wenn es dir um den HTTP-Kontext geht, dann sorgt (hoffentlich) der Webserver dafür, dass er keine Ressourcen ausliefert, die das nicht werden sollen.

Wenn du mit PHP auf Dateien zugreifen willst, deren Name sich aus Eingabedaten zusammensetzt, so gibt es nicht nur die folgende Prüfungsmöglichkeit: Löse den Dateinamensstring mit realpath() in einen absoluten Pfad auf. Prüfe dann, ob er auf ein freigegebenes Verzeichnis zeigt.

Ist meine Behandlung in 1) bis 3) ausreichend (sicher)?
Lässt sich das möglicherweise garnicht so pauschal sagen und ist von Fall zu Fall zu entscheiden?

Wenn du das Prinzip verstanden hast, kannst du dir diese Frage nun selbst beantworten. Die ...-Injection-Sicherheitslücken entstehen immer dann, wenn es gelingt, Zeichen, die eigentlich Daten sein sollen, vom Empfänger als Anweisungsteil interpretieren zu lassen.

Solange man das nicht möchte, ist eine korrekt ausgeführte kontextgerechte Behandlung der Daten sicher. (Dass dann vielleicht verunglückte Injection-Versuche als Nutzdaten auftauchen, ist ein anderes Thema.) Schwierig wird es, wenn man den Anwendern teilweise Zugeständnisse machen möchte und einige Anweisungsteile erlauben möchte. Hier muss man genauestens aufpassen, was man erlaubt und was nicht. Einfacher ist es sicher, wenn man eine andere Syntax mit eingeschränktem Funktionsumfang (z.B. BBCode) statt eines zwar gefilterten aber ansonsten umfangreichen Systems (HTML) zur Verfügung stellt. Wenn nämlich der Filter unerkannte Lücken aufweist, ...

echo "$verabschiedung $name";

[zwerg]

Glück auf!

Und vielen Danke an dedlfix, ChrisB, Gonzo und Tom für die so hilfreichen Antworten. Ich werde mir diesen Thread gut einprägen und für alle Fälle auch nochmal in meine Favoriten packen.

Da ich vorhin, auf der Arbeit (Schande über mich) ohne Anmeldung unterwegs war, hab ich anonym gefragt. Mit der Folge, dass ich gerade vor lauter Freude meine Frage als hilfreich bewertet hab *schäm*

Eine Frage hätte ich aber noch.
Wenn ich preg_match('|^([a-z0-9_-]+/)*[a-z0-9_-]+\.[a-z]+$|i', $variable); richtig verstanden habe, dann trägt er ja in $variable alle Treffer der genannten Zeichen ein, oder? Da finde ich aber doch auch einen Slash (oder war / ein Backslash?) und einen Punkt. Genau das wollte ich doch verhindern. Was erreiche ich also damit?

Freundliche Grüße
zwerg Alex

[dedlfix]

echo $begrüßung;

Wenn ich preg_match('|^([a-z0-9_-]+/)*[a-z0-9_-]+\.[a-z]+$|i', $variable); richtig verstanden habe, dann trägt er ja in $variable alle Treffer der genannten Zeichen ein, oder?

Du hast es nicht richtig verstanden. Der zweite Parameter ist das zu untersuchende Subjekt. Im dritten Parameter werden die Fundstellen der Gruppierungen zurückgegeben, wenn er vorhanden ist.

Da finde ich aber doch auch einen Slash (oder war / ein Backslash?) und einen Punkt. Genau das wollte ich doch verhindern. Was erreiche ich also damit?

Wenn du schauen möchtest, ob $variable dem Muster entspricht, musst du den Rückgabewert der Funktion auswerten.

echo "$verabschiedung $name";

[zwerg]

Glück auf!

echo $begrüßung;

Wenn ich preg_match('|^([a-z0-9_-]+/)*[a-z0-9_-]+\.[a-z]+$|i', $variable); richtig verstanden habe, dann trägt er ja in $variable alle Treffer der genannten Zeichen ein, oder?

Du hast es nicht richtig verstanden ...

Du hast Recht. Diese ganze Aneinanderreihung von (Sonder-)zeichen verstehe ich nicht. Leider auch nicht nach deiner Erklärung, nachlesen in verschiedenen Büchern und recherchieren auf diversen Internetseiten. Das ist mir einfach zu kompliziert. Die Einzelnen Bedeutungen der Zeichen verstehe ich; aber bei dieser komplexen Art ... ich glaub da bin ich zu doof für :(

Die $variable_verzeichnis um den Link zusammenzubasteln überprüfe bzw. ändere ich jetzt so ab:
$clean_variable_verzeichnis = preg_replace('/[^a-zA-Z_0-9]/', '', $variable_verzeichnis);
Damit verhindere ich, dass man mit "." bzw. ".." auf übergeordnete Ordner zugreift bzw. auf andere (externe) Ziele verweist. Andere kranke Ideen will ich mir jetzt gerade nicht vorstellen und neben der Sicherheit ist mir auch wichtig, dass ich verstehe, was ich schreibe.

Freundliche Grüße

zwerg Alex

[dedlfix]

echo $begrüßung;

Wenn ich preg_match('|^([a-z0-9_-]+/)*[a-z0-9_-]+\.[a-z]+$|i', $variable); richtig verstanden habe, dann trägt er ja in $variable alle Treffer der genannten Zeichen ein, oder?
Diese ganze Aneinanderreihung von (Sonder-)zeichen verstehe ich nicht. Leider auch nicht nach deiner Erklärung,

Meine Erklärung bezog sich nicht auf den Regulären Ausdruck sondern auf die Anwendung der Funktion preg_match().

nachlesen in verschiedenen Büchern und recherchieren auf diversen Internetseiten. Das ist mir einfach zu kompliziert. Die Einzelnen Bedeutungen der Zeichen verstehe ich; aber bei dieser komplexen Art ... ich glaub da bin ich zu doof für :(

Was willst du eigentlich erreichen? Dieser Ausdruck prüft, ob in $variable ein Wert gemäß des angegebenen Musters enthalten ist. Das gibt die Funktion über ihre Ergebnis bekannt.

Die $variable_verzeichnis um den Link zusammenzubasteln überprüfe bzw. ändere ich jetzt so ab:
$clean_variable_verzeichnis = preg_replace('/[^a-zA-Z_0-9]/', '', $variable_verzeichnis);
Damit verhindere ich, dass man mit "." bzw. ".." auf übergeordnete Ordner zugreift bzw. auf andere (externe) Ziele verweist.

Was hast du denn gegen meinen Vorschlag mit realpath()? Wenn du den Zugriff auf ein Verzeichnis und dessen Unterverzeichnisse beschränken willst, dann vergleiche das Hauptverzeichnis mit dem Anfang des Ergebnisses von realpath(). Das ist ein simpler Stringvergleich plus ein wenig String-Zurechtschneiden.

echo "$verabschiedung $name";

[zwerg (@work)]

Hallo dedlfix,

Was hast du denn gegen meinen Vorschlag mit realpath()?

Jetzt, da ich ihn verstanden habe, eigentlich garnichts mehr. Thx