So, mein erster Artikel zu PHP und dazu noch etwas was jedem Programmierer am Herzen liegen sollte, zusätzlich zu sauberem und schlanken Code.
Ein Thema welches man nie oft genug wiederholen kann, Sicherheit in PHP Anwendungen. Ein sehr wichtiges Thema sogar. Wer hat schon gerne “Müll” in seiner Datenbank, oder schädlichen Fremdcode innerhalb der eigenen Seiten. Die Beispiele könnte man nun ewig so weiterführen.
Im ersten Teil informieren wir uns über Sicherheitslücken im Allgemeinen, klären woher die Gefahr kommt und wie man sich Verhalten sollte beim programmieren von sicheren Anwendungen. Zuletzt gehen wir etwas genauer auf die einzelnen Lücken ein und definieren sie Allgemein.
Sicherheitslücken gibt es in den verschiedensten Variationen, Facetten und Farben. Grob lassen sie sich aber in 4 Kategorien einteilen. Angefangen mit Fehlern im verwendeten Betriebssystem, also offene Hintertüren, Bugs usw. Ein weiteres Problem sind fehler in verwendeten Komponenten, sprich Apache, PHP und MySQL. Und natürlich schlampig programmierte Anwendungen, sowohl eigene als auch fremde.
Die Gefahr kommt von überall, man kann den Benutzereingaben nie wirklich trauen. Generell sollte man seine Programme so entwickeln, als sei man Paranoid und jeder Besucher will einem an die Wäsche. Diese Einstellung bringt einem einen großen Mehraufwand, wird meist nicht extra bezahlt und man bekommt vom Auftraggeber erst recht nicht mehr Zeit für so einen Quatsch wie Sicherheit. Das Ende vom Lied, im schlimmsten Falle wird der Server gekapert. Und dann ist das Geschrei groß!
Aber von wem geht den jetzt eigentlich die Gefahr aus? Prinzipiell kann einem jeder Nutzer gefährlich werden. Ich mein, wer hätte den nicht einmal gern die Adminrechte und sei es nur um ungeliebte voreinstellungen im Forum, Gästebuch usw. zu ändern.
Wirkliche Gefahr allerdings, geht von Crackern und Scriptkiddies aus.
Lange Rede kurzer Sinn, programmiere sicher, update dein Betriebssystem mit den nötigen Sicherheitspatches, sowie die verwendeten Komponenten.
Fangen wir mit den 5 häufigsten Sicherheitslücken an.
- Remote Code Execution
- XSS – Cross Site Scripting
- SQL Injection
- PHP Konfiguration
- Dateisystem Attacken
Remote Code Execution
Dieses Problem bekommt man ziemlich schnell beim einbinden von externen Dateien in das eigene Script. Externe Dateien kann man Beispielsweise über require(), include(), fopen() etc. und den entsprechenden Pfad (z.B. bei register_globals=on und allow_url_fopen=on in der php.ini) einbinden. So brauch der Angreifer nicht mal den Schadcode auf den Server bringen, sondern muss ihn nur über die URL einbinden.
Häufige Ursachen für das auftreten dieser Schwachstelle:
- Fehlerhafte Validierung von Benutzereingaben oder sogar überhaupt keine Validierung, was nicht selten der Fall ist.
- Erlaubtes “allow_url_fopen”, was die Einbindung von Programmcode ausserhalb der eigenen Domain erlaubt.
- Zugriff auf Bereiche ausserhalb des eigenen Webroot, dank fehlerhafter Zugriffsbeschränkungen oder gar fehlenden Beschränkungen.
Cross Site Scripting
Welches auch als HTML-, JavaScript- und User-Agent Injektion bekannt ist, beruht in aller Regel auf der Anzeige von Fremddaten. Also Content der von ausserhalb in die Website kommt, meist über Formulare. Deswegen auch, traue niemandem, der Inhalte hinzufügen kann, ohne diese vorher zu prüfen.
Das heisst der Angreifer braucht eine Dynamische Website, die die Nutzereingaben nicht ausreichend prüft um einen Cross Site Scripting-Angriff auszuführen.
SQL Injection
Wenn man Daten an eine Datenbank weitergibt und diese nicht entsprechend validiert, hat der Angreifer die Möglichkeit, über das Formular SQL Code auszuführen um so die eigentliche Abfrage zu Manipulieren und sich so, möglicherweise Zugang zum System verschaffen kann.
Die möglichen Konsequenzen daraus, ein Angreifer mit Admin Rechten, der einem das CMS zerschießt. Oder bei einer Kundendatenbank, alle relevanten Nutzdaten auslesen und im Internet verbreiten. Ok dazu bedarf es keinen Hacker, man brauch nur mal nach liegengelassenen CD’s suchen, vielleicht findet sich da ja was.
Hier gilt auch. Nutzereingaben filtern, prüfen usw.
PHP Konfiguration
Es braucht gar nicht einmal eine schlecht programmierte Anwendung sein um das System einem Angreifer schutzlos zu überlassen. Meist reichen auch vom Provider zu lasch gesetzte Einstellungen in der Konfiguration.
Dateisystem Attacken
Hier ist es schwierig Sicherheit zu finden, vor allem auf “shared” Webhosting angeboten. Ausserdem wird PHP bei vielen Providern als Nutzer Nobody ausgeführt und betreffen so nicht nur einzelne Scripte sondern sind auch eine Gefahr für den ganzen Server. Unter Remote Code Execution findet man die Gründe warum.
Für heute sind wir am Ende unseres kleinen Exkurses zum Thema Sicherheit angekommen. Morgen, werden wir uns das ganze mal in der Praxis mit Beispielen anschauen. Und zuletzt lernen wir dann noch ein paar kleine Helferchen kennen, die uns in beim programmieren von sicheren Anwendungen unterstützen.
Soweit nicht anders gekennzeichnet, stehen alle Inhalte auf miyuato.com unter
einer