PHP-Skripte und Sicherheit - Ein Problem der Struktur?
Philippé
- php
Hallo Community,
auf php.net und php-faq.de kann man einige sehr gute Artikel über die Sicherheit von PHP-Skripten lesen.
Auch im SelfHTML Forum habe ich schon nette Hinweise zum Thema Sicherheit bekommen.
Zu meiner Frage:
Als Beispiel mal eine Klasse für ein Upload-Script. In der Admin-Oberfläche können Dateien hochgeladen werden.
class upload {
var $output;
var $upload_file;
function delete_file($dir) {
$this->upload_file = unlink($dir);
}
function move_file($temp, $destination) {
$this->upload_file = move_uploaded_file($temp, $destination);
return $this->upload_file;
}
}
Funktionieren tut es, nur ist es auch besonders sicher? Nein. Nun gut, man kann es auch übertreiben, schließlich kann nur der Admin Dateien hochladen.
Aber es geht um's Prinzip.
Wenn man das Ganze noch ausbreitet, könnte man fragen: Wie sieht ein gutes PHP-Script überhaupt aus, d.h. von der Strukturierung?
Wenn ich, als Beispiel, ein kleines (winziges...) CMS schreibe, welches nur aus Schreiben, Editieren, Löschen und dem Upload von Bildern besteht, sollte ich dann schon die einzelnen Funktionen der admin.php auslagern und in eine Datei quetschen? Ich will keinen Glaubenskrieg anzetteln, nur findet man massenhaft Tutorials über PHP die den Anfängern erklären wie man was realisiert, nur kommt da im Endeffekt ziehmlich viel Müll raus.
Reicht es, einfach mit addshlashes, htmlspecialchars und mysql_real_escape_string zu arbeiten oder sollte man eine "Sicherheits-Klasse" zur Überprüfung als Standard ansehen? Wo sind die Grenzen bei Code-Komplexität, Usability und Sicherheit?
Just my 2 cents.
MfG Philippé
Hello,
die von Dir zitierte Klasse halte ich für Nonsens.
Es ist irgendwie nicht gewinnbringend, nur einen Wrapper um vorhandene Funktionen zu bauen, ohne dabei neue Funktionalitäten und Prüfungen einzubauen.
Alleine beim Upload von Files gibt es bestimmt ein Dutzen Dinge zu berücksichtigen:
Ist der User authentifiziert?
Ist der authentifizierte User überhaupt berechtigt, Files hochzuladen?
Welche Typen von Files darf der User hochladen?
Welche Ziele (Verzeichnisse) darf er wählen?
Darf der Name des files vom User vorgegeben werden?
Darf er vorhandene gleichnamige Files überschreiben?
Darf er Multiuploads durchführen?
Hat der User (oder irgend jemand anderes) nach dem Upload Zugriff auf die Files?
Enthält der Uploadname mehr als einen Basename?
Liegt ein Mehrfach-Post vor?
Ist die maximale Größe überschritten worde`n?
Ist die maximale Upload-Time überschritten worden?
Enthält das Upload-File Viren/Würmer/... ?
...
usw.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hello,
Hi there,
die von Dir zitierte Klasse halte ich für Nonsens.
Ja, schlechtes Beispiel.
Es ist irgendwie nicht gewinnbringend, nur einen Wrapper um vorhandene Funktionen zu bauen, ohne dabei neue Funktionalitäten und Prüfungen einzubauen.
Stimmt schon.
Alleine beim Upload von Files gibt es bestimmt ein Dutzen Dinge zu berücksichtigen:
[...]
Du hast schon recht, nur gehe ich von dem Punkt aus (das kannst du jetzt natürlich nicht wissen, mein Fehler), dass es nur einen User, den Admin, gibt und dieser dann über eine Admin-Oberfläche Dateien hochladen kann. Insofern trägt der Admin die volle Verantwortung.
Deine Beispiele sind aber trotzdem richtig.
Das ist aber das Kernproblem: Ich habe nur eine Datei (admin.php) und zwei zusätzliche für Klassen und Funktionen. Wenn jetzt per POST eine Datei hochgeladen werden soll, kommt diese als erstes bei der admin.php an. Jetzt hat man nur zwei Möglichkeiten: übergebe ich den ganzen Kram an eine Klasse/Funktion oder soll sich die admin.php um alles kümmern?
Nur ist mein Beispiel nichts Halbes und nichts Ganzen...
Hello,
Das ist aber das Kernproblem: Ich habe nur eine Datei (admin.php) und zwei zusätzliche für Klassen und Funktionen. Wenn jetzt per POST eine Datei hochgeladen werden soll, kommt diese als erstes bei der admin.php an. Jetzt hat man nur zwei Möglichkeiten: übergebe ich den ganzen Kram an eine Klasse/Funktion oder soll sich die admin.php um alles kümmern?
Es sollte auf jeden Fall eine strenge Kontrolle stattfinden, damit der vermeintliche Admin auch nur dorthin hochladen kann, wo es vorgesehen ist. Ein Eindringling könnte sonst sehr leicht den Server übernehmen.
Auch wenn sich die Kotrolle beim Admin nur auf wensentliche Rahmenbedingungen erstreckt, würde ich eine eigene Uploadklasse bauen, in der einheitlich für alle, alle Bedingungen festgelegt und geprüft werden. Über Paramter (ggf. Array) kann dann festgelegt werden, welche Bedingungen GELOCKERT werden dürfen. Das bedeutet, dass mittels der Klasse erst einmal alle dicht gemacht wird, und dann die Restriktionen für jeden User entsprechend gelockert werden. Kommen nachträglich Restirktionen hinzu, gelten die erstmal für alle (auch den Admin) und können dann in einem entsprechenden DB-Datensatz wieder gelockert werden.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom