Nils hat es innerhalb eines Jahres geschafft zu einer festen Größe in der deutschen PHP-Szene zu werden. Er öffnete seinen Blog mit dem Anspruch jeden Tag einen Artikel zu schreiben. Ein hochgestecktes Ziel, denn es ist ja sehr oft so, das viele nach ein paar Monaten wieder aufgeben. Doch Nils hat es durchgehalten, jeden Tag einen Beitrag zu schreiben. Mit der Zeit sind auch einige super Co-Autoren und Gast-Autoren dazu gekommen, die Nils ein wenig unter die Arme greifen.

Ich lese phphatesme schon in etwa so lange wie es in gibt. Glaube ich war ab dem 10 Artikel dabei. Im Grunde kann man sagen, das Nils mich zum Bloggen gebracht hat, wenn auch indirekt. Danke Nils!

Bedanken möchte ich mich auch für die Möglichkeit Gast-Artikel bei phphatesme.com zu schreiben. Einen hab ich bis jetzt geschafft. Aber ich denke da kommen noch ein paar dazu.

So, ich wünsche phphatesme.com, Dir Nils und den Co-Autoren eine weitere Erfolgreiche Zeit. Auf das bald der Feedreader die 1000er Grenzen packen mag.

Wichtig ist mir euere Meinung! Ihr habt was zu sagen? Bitte, dann schreibt es in die Kommentare. Nur so kann ich kann ich versuchen euere Wünsche umzusetzen.

Ich möchte diesen Artikel als Ankündigung nutzen, den Morgen erscheint mein erster Artikel für www.phphatesme.com. Also schaut dort mal vorbei und seht was ich tolles für einen der bekanntesten deutschen PHP Blogs geschrieben habe. Thema: Eclipse PDT

Also dann, hier wird die Tage auch mal wieder ein Artikel mit “Mehrwert” veröffentlicht.

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.

1. Remote Code Execution
2. XSS – Cross Site Scripting
3. SQL Injection
4. PHP Konfiguration
5. 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.

Die für PHP relevanten Ergebnisse möchte ich hier etwas genauer erläutern.

An dieser Stelle sei mir aber noch ein kleiner Nachtrag zu meinem Artikel gestern erlaubt. Heut bin ich auf einen sehr interessanten Link im Bezug auf Browser Updates gestoßen. www.browser-update.org, bietet die Möglichkeit, Besuchern der Website dezent anzuzeigen, dass ihr Browser veraltet ist. Eine Super Idee, werde ich hier wohl auch einbauen!

So aber nun zur Umfrage.

Unter anderem wurde auch danach gefragt, welche der angebotenen Skriptsprachen man am Häufigsten einsetzt. PHP, Perl und Shell hängen hier die “Konkurrenz” deutlich ab. Und PHP hat die Nase knapp vor Perl. Die Frage nach der verwendeten Sprache im Bezug auf Internet und Intranetanwendungen, gewann PHP sehr deutlich. Der Anteil betrug hier 53%. Auch in der Kategorie Datenanalyse und -bearbeitung liegt PHP vorne, allerdings nur mit 34% Gesamtanteil. Bei Administrativen Aufgaben hat, als hätte irgendwer je etwas anderes vermutet, Shell das größte Stück vom Kuchen bekommen.

Zu einzelnen Fragen konnte man noch zusätzlich einen Kommentar schreiben, was auch sehr viele gemacht haben. Ein paar der Kommentare zu PHP sei hier nachfolgend zitiert

• Uebersichtlicher als perl, besonders bei der analyse/nutzung von fremdcode.
• Geringe Lernkurve, gute Frameworks, breite Entwicklerbasis, professioneller Support (z.B. von Zend), Verfügbarkeit auf vielen Verschiedenen Plattformen (inkl. iSeries)
• quick and dirty
• Einfach, schnell und es stehen viele Funktionen und Scripte zur Verfügung. Gute Anbindung an MySQL.
• Die Eigenschaften der Sprache sind mir wurscht, Hauptsache, wir finden Mitarbeiter, welche die Sprache beherrschen.
• Leicht zu erlernen – große Community – gut dokumentiert – Plattformunabhängigkeit(Shell läuft nicht ohne weiteres auf Windows) – große Einsatzreichweite durch die Vielfalt der Module
• PHP unterstützt schnelle Entwicklung. Es sind viele Bibliotheken, Frameworks und Tools verfügbar. Aktive Community. Einsatz in kleinen und großen Projekten. Hervorragende Unterstützung von Web-Technologien.
• Geringe Einstiegsbarriere, Einfachheit
• Die einfache Syntax, viele Einsatzmöglichkeiten (besonders natürlich in Web-Anwendungen), sehr gute Community.
• OOP Features in PHP 5, gute Entwicklungstools, Robustheit, C-ähnliche Syntax, große Anzahl an verfügbaren Bibliotheken, große Benutzergemeinde
• Objektorientierung
• Einfach, Schnell Umsetzbar, Weit verbreitet
• Syntaktische Nähe zu C/C++, hohe Verfügbarkeit
• Vielseitig, viele array und stringfunktionen, magic
• Leicht erlernbar. – Datenbankzugriff ungeschlagen einfach – Seit Vers. 5 Unterstützung OOP – Zahlreiche Snippets oder Skripte im Internet – Zahlreiche sehr gute Frameworks, einige sogar Enterprisefähit
• Sehr einfache Sprache Orientiert sich an C/C++Syntax. Seit V5 OOP möglich
• OOP-Fahigkeit – Funktionsumfang – Zugänglichkeit – Support
• Leichte Erlernbarkeit, Verbreitung
• Die große Entwicklergemeinde und damit vielen verfügbaren fertigen Anwendungen und Skripte (allerdings leider auch in variierender Qualität)
• Die Einfachheit bei der Entwicklung von Webanwendungen. Inzwischen auch die verfügbaren Sprachfeatures. Die pragmatische Weiterentwicklung der Sprache und zugehörigen Bibliotheken.Sowohl prozedural als auch OOP möglich.

Interessant ist ebenfalls das verwendete Perl Framework WebGui.
Der erste Eindruck ist gar nicht mal so übel und Perl ist eine tolle Sprache, wenn auch nicht so toll wie PHP, aber das steht ganz ausser Frage. Vielleicht werde ich mir das bei Gelegenheit etwas näher anschauen. Natürlich teile ich euch dann meine Ehrfahrungen mit.