PHP ist ein leistungsfähiges und flexibles Werkzeug. Diese Leistungsfähigkeit und Flexibilität kommt daher, dass PHP ein sehr kleines System ist, das auf Dutzenden von verschiedenen Drittanbieterbibliotheken aufsetzt. Jede dieser Bibliotheken hat eigene einzigartige Möglichkeiten zur Dateneingabe.
Daten, die man sicher an eine Bibliothek weitergeben kann, können Sicherheitssprobleme darstellen, wenn man sie zu einer anderen Bibliothek weitergeben würde.
Der neue Web-Wurm, "
NeverEverNoSanity", zeigte einen Fehler in der Eingabeüberprüfung des populären PHP-Forums "
phpBB" auf. Die Codehervorhebungfunktion dieser Software hat eine, mit "
urlencode" doppelt codierte, Eingabe falsch verarbeitet. Eine zu ungenaue Prüfung von nicht vertrauenswürdigen Nutzereingaben kombiniert mit dem Einsatz von PHP Funktionen, die Code ausführen oder in das Dateisystem schreiben, sorgen für ein potenzielles Sicherheitsrisiko. Trotz einiger Verwirrung bezüglich einiger PHP Sicherheitsfixes und dem "NeverEverNoSanity" Wurm, hatte der Wurm selbst nichts mit einem Sicherheitsproblem von PHP zu tun.
Wenn wir über Sicherheit in Webanwendungen sprechen, reden wir von 2 Arten: Remote und Lokal. Jede "Remote"-Schwachstelle kann durch sehr sorgfältige Überprüfung der Eingabe vermieden werden. Wenn man eine Anwendung schreibt, die nach dem Namen und dem Alter des Benutzers fragt, sollte man überprüfen, dass man nur Zeichen erhält, die man auch erwartet. Außerdem sollte man sichergehen, dass nicht zu viel Daten gesendet werden, die dann einen
Überlauf beim Speichern oder der Weiterverarbeitung in Funktionen verursachen.
Eine Variation der "Remote"-Sicherheitslücke stellt
XSS (Cross-Site Scripting) dar. Sie wird dadurch ausgenutzt, dass ein Benutzer Javascript Code eingibt, welcher dann beim nächsten Benutzer ausgeführt wird.
Bei lokalen Schwachstellen hören wir meistens von "open_basedir" oder "
Safemode" Problemen, die meist bei gemeinsam genutzten Hosts auftreten. Diese beiden Features sind als Erleichterung für System Administatoren gedacht und sollten keinesfalls als ein gesamtes Sicherheits-System angesehen werden. Mit all den Bibliotheken von Drittherstellern, die in PHP eingebunden werden können, und den vielfältigen Möglichkeiten mit denen diese wiederum Zugriff auf das Dateisystem zu bekommen, kann man keine Sicherheit durch diese Direktiven garantieren. Zum Beispiel haben die Erweiterungen
Oracle und
Curl die Möglichekit, durch ihre Bibliotheken lokale Dateien zu lesen. Eine Lösung könnte die Modifikation dieser Fremdsoftware darstellen. Dies wäre allerdings bei einer "Closed-Source" Software wie Oracle schwer; so kann PHP von seiner Seite nicht viel dagegen ausrichten.
Wenn man PHP allein, mit nur wenigen Erweiterungen einsetzt, sind "Safemode" und "open_basedir" in der Regel ausreichend, um den gewöhnlichen "Bad Guy" zu frustrieren. Für komplexere Situationen sollte man aber die Sicherheitsfunktionen seines Betriebsystems nutzen, indem man mehrere Webserver gleichzeitig am Laufen hat: Jeder Webserver mit seiner eigenen User-ID und zusätzlich in einem seperaten gerooteten Dateisystem. Besser wäre es, jede Anwendung auf einem komplett separaten physischen Server zu legen. Bei geteilten Servern mit vertrauensunwürdigen Mitnutzern ist eine 100% Sicherheit nicht zu gewährleisten.
Quelle: http://www.php.net - A Note on Security in PHPSiehe auch:
SQL Injections vermeiden
Daten richtig verarbeiten
Autor
Gespeichert
