1     Einleitung

1.1     Über dieses Buch

Als im Herbst 2004 das Konzept für die erste Auflage dieses Buches erstellt wurde, hatte PHP bereits viele andere Web-Skriptsprachen hinter sich gelassen. Millionen von Websites bauen auf die dynamische Skriptsprache, und von einfachen Gäs­tebüchern bis hochkomplexen mehrstufigen Business-Applikationen sind PHP-Anwendungen in allen Größen, Farben und Formen zu finden.

Seitdem konnte die PHP, nicht zuletzt dank der Fülle verfügbarer Webapplikationen, aber auch dank geringer Einstiegshürden für Entwickler seinen Vorsprung gegenüber anderen Sprachen deutlich ausbauen. Zwar kommen mit dem vielgerühmten „Web 2.0“ neue Herausforderungen und Konkurrenten – man denke an „Ruby on Rails“ – aber auch diese Hürde nimmt PHP spielend.

PHP 5 bietet all denen, die zuvor die etwas lückenhafte Implementie­rung objektorientierter Programmierung von ernsthaften Gehversuchen abgehalten hat, eine umfassendere OOP-Schnittstelle und dazu geführt, dass noch mehr große Projekte und Firmen den Sprung von Lösungen mit Java oder .NET zu der freien Skriptsprache schaffen.

Mit dem immensen Wachstum der Nutzer- und Entwicklergemeinde wuchsen allerdings auch die Schwierigkeiten. Waren sicherheitsrelevante Fehler in PHP-Programmen schon seit jeher ein ernst zu nehmendes Problem, so kam es im Laufe des Jahres 2004 zu einigen mehr oder weniger spektakulären Sicherheitslücken. Die Forensoftware phpBB war besonders schlimm betroffen, ist sie doch (aufgrund ihres reichhaltigen Feature-Umfangs und der relativ einfachen Administration) eine der Killer-Applikationen für PHP. Ohne freie und leicht zu benutzende Produkte wie phpBB wäre die Verbreitung von PHP sicher nicht so schnell gegangen – allerdings auch nicht die Verbreitung des ersten PHP-Wurms Santy^[1], der eine Lücke in der Forensoftware ausnutzt, um Schadcode zu laden und aus­zuführen. Ironischerweise ist Santy ausgerechnet in Perl geschrieben, der Sprache, an der sich PHP lange Zeit messen lassen musste.

Andere Sicherheitsprobleme auf Internetseiten mit dem Label »PHP powered« beschäftigten gleich die Staatsanwaltschaften^[2] oder Mitarbeiter großer Telekommunikationskonzerne^[3]. Bei allen Fehlern handelte es sich um Programmier- oder Designschnitzer, die vermeidbar gewe­sen wären. Obwohl auch in PHP selbst Bugs entdeckt (und behoben) wur­den, die von einem böswilligen Angreifer für seine finsteren Zwecke verwendet werden konnten, liegt die große Mehrzahl der für die erfolgreiche Installation von Rootkits, Backdoors oder anderen Exploits verantwortlichen Sicherheitslücken in den Anwendungen selbst.

Seit 2004 hat sich die Struktur der Angriffe, aber auch die Struktur der Angreifer verändert. Wurden PHP-basierte Webapplikationen noch vor wenigen Jahren hauptsächlich „zum Spaß“ angegriffen oder die sie beherbergenden Server als Ablageplatz für Raubkopien und Ähnliches mißbraucht, stehen nun kommerzielle Interessen im Vordergrund. Professionelle Crackergruppen nutzen automatisierte Tools, um massenhaft Schwachstellen in PHP-Anwendungen auszunutzen, sich Zugang zu Webservern zu verschaffen und diese zu kriminellen Handlungen wie Spam, Phishing, Denial of Service oder gar illegaler Pornographie zu mißbrauchen. Riesige „Botnetze“ gehackter Server- und Clientrechner erwarten die Befehle ihrer mafiös organisierten Beherrscher Obgleich es derlei Aktivitäten in engen Grenzen schon vor der ersten Auflage dieses Werkes gab, ist die Professionalität, Organisationsdichte und programmiererische Fähigkeit der Angreifer stark gewachsen.

In zum Glück stärkerem Maße als Hacker, Cracker und Bauernfänger ist PHP den Kinderschuhen entwachsen, darüber besteht weitgehend Einigkeit. Anders als bei konventionellen Programmiersprachen wird aller­dings in der Netzöffentlichkeit die Qualität einer Sprache nach wie vor an der Quali­tät der Anwendungen gemessen. So hat das Website-Management-System PHP-Nuke dem Ruf der Sprache PHP durch seine zahlreichen Sicherheits­lücken nicht unerheblich geschadet – ähnlich wie das berüchtigte form­mail.pl in Perl das sprichwörtliche Negativbeispiel ist. Das scheint unge­recht, schließlich wird C++ auch nicht für Fehler in Windows verantwortlich gemacht oder Assembler für Bugs im Interrupt-Handling des Linux-Kernels beschuldigt. Dennoch hat diese Haltung auch Vorteile: Sie zwingt das PHP-Team (die »PHP Group«) mittelfristig, »Best Practices« zu entwickeln und PHP-Programmierer zu mehr Sicherheitsbewusstsein zu erziehen. Dieses Buch soll dabei helfen, indem es Problemfelder aufzeigt, Lösungsmöglichkeiten anbietet und anhand klarer Checklisten die Absiche­rung neuer und vorhandener Skripte erleichtert.

An wen richtet sich dieses Buch?

Das Buch »PHP-Sicherheit« wurde mit Blick auf zwei Gruppen von Lesern geschrieben: Fortgeschrittene und Profis mit Wartungsaufgaben sowie Sys­temadministratoren für Web- und Datenbankserver.

PHP-Neulinge

Gerade Neulinge auf dem Feld der PHP-Entwicklung gehen – das haben die Autoren zumindest in vielen Fällen beobachten können – mit einer erfrischenden Naivität an die Programmierung ihrer ersten dynami­schen Webseite heran. Das ist nicht grundsätzlich falsch, schließlich ist das Prinzip von »Trial and Error« so alt wie die Programmierung selbst. Da aber PHP eine serverbasierte Skriptsprache ist und die Entwicklung direkt auf dem Webserver stattfindet, sind fehlerhafte »Hallo Welt«-Elaborate nicht nur für ihren Schöpfer peinlich, sondern mit etwas Pech auch eine große Gefahr für andere Server im Internet.

Wir möchten mit diesem Buch Einsteiger auf Gefahren und Risiken auf­merksam zu machen, die sie bei der Entwicklung und beim Einsatz von PHP-Skripten beachten müssen. Der Großteil aller Anfängerfehler lässt sich mit einigen grundlegenden Verhaltens- und Implementierungsregeln vermeiden – und damit auch das persönliche Gästebuch sicherer gestalten.

Fortgeschrittene
PHP-Entwickler

Auch fortgeschrittene PHP-Entwickler, die bereits mittlere bis große Anwendungen selbst oder als Teil eines Teams entwickelt haben, stehen oft vor ähnlichen Problemen. Sogenannter »Legacy Code«, also gewachsene Produkte, die seit langer Zeit »mitgeschleppt« werden, strotzen oft nur so vor Sicherheitsmängeln oder Designfehlern. Und doch ist ein kom­pletter Rewrite oft nicht machbar – also steht eine Sicherheitsüberprüfung des gesamten Quellcodes an. Die Checklisten im Anhang helfen, diese Auf­gabe zu systematisieren – und selbst der versierteste PHP-Crack wird einige der in diesem Buch vorgestellten Lücken vielleicht noch nicht kennen.

Systemadministratoren

Der letzte Teil des Buches richtet sich an Systemadministrato­ren, also diejenigen, die unter schlecht geschriebenen und schlampig gewar­teten Programmpaketen leiden und nach einem erfolgreichen oder misslun­genen Hack die Aufräumarbeiten erledigen müssen. Obwohl sie meist Zugriff auf die Anwendung haben, können oder dürfen die Administratoren nur selten selbst sicherheitskritische Änderungen durchführen. Um Scha­den abzuwenden, müssen also die Webserver so konfiguriert werden, dass ein Angreifer auch ein sehr unsicheres Skript nicht für seine Zwecke miss­brauchen kann – der Webserver muss gegen Angriffe abgehärtet (»harde­ned«) werden.

1.2     Was ist Sicherheit?

In der IT existiert ein geflügelter Spruch, der besagt, dass Daten erst dann sicher seien, wenn sie in einem Safe an einer unbekannten Stelle auf dem Meeresboden versenkt würden. So übertrieben das auch klingen mag, die­ses Sprichwort enthält einen Funken Wahrheit. Absolute Sicherheit kann (ohne Tresore und Tiefsee-Lagerung in Betracht zu ziehen) nicht erzielt werden, alle Bemühungen müssen stets als »best effort« gelten.

Eine sinnvolle Definition des Sicherheitsbegriffes kann stets nur kon­textbezogen gefunden werden. Institutionen wie Finanz- oder Meldeämter, die mit hoch- und höchstvertraulichen Daten zu tun haben, werden unter Sicherheit etwas völlig anderes verstehen als jemand, der auf seiner priva­ten Homepage in einem einfachen CMS Bilder seines Goldfisches ausstellt. Daher kann man die Sicherheit von webbasierten Systemen (um die es in diesem Buch letztlich gehen soll) folgendermaßen umschreiben:

Ein System kann als sicher gelten, wenn die Kosten für einen erfolgreichen Angriff den möglichen Nutzen übersteigen.

Cracker und sonstige böse Buben verfügen nämlich nicht über unbegrenzte Zeit und Mittel. Die erste Gruppe von Angreifern, »Scriptkiddies«, rekru­tiert sich überwiegend aus Jugendlichen und jungen Erwachsenen mit weni­gen oder keinen Fachkenntnissen. Das typische Scriptkiddy verfügt über eine gut sortierte Bibliothek vorgefertigter Angriffstools für viele verschie­dene Lücken und sucht sich seine Opfer meist anhand vorhandener Lücken aus. Derartige Angreifer werden sich vor allem leichte Ziele aussuchen, die gleichzeitig vielversprechende Möglichkeiten bieten. Ein Webserver, der schnell ans Internet angebunden ist und auf dem eine uralte Version des Forums phpBB verwendet wird, ist verlockende Beute für Scriptkiddies. Er ist leicht zu »knacken« und kann dann als Ablageplatz für Raubkopien oder als Relay, also Zwischenstation, für weitere Angriffe missbraucht werden.

Ist aber die verwendete Software auf dem neuesten Stand oder auch recht unbekannt, wird mehr Aufwand notwendig, um in den Server einzu­dringen – ein Einbruch lohnt sich oft nicht mehr und die meisten Scriptkiddies werden schnell von einem Server ablassen, der auf den ersten – meist auto­matisierten – Blick keine Angriffsfläche bietet.

Ein Unternehmen, das sehr viele wertvolle Daten verwaltet, ist jedoch auch für erfahrenere Cracker, die ihre Raubzüge aus kommerziellen Grün­den durchführen, ein sehr attraktives Ziel. Hacker werden viel Zeit und Mit­tel aufwenden, um an diese Daten zu gelangen, es reicht daher nicht, die Datei mit sämtlichen Kundendaten in einem versteckten, aber für den Web­server zugänglichen Verzeichnis abzulegen. Sobald die möglichen Ein­dringlinge das Ziel als sehr attraktiv eingestuft haben, werden sie sich so lange an den frei zugänglichen Teilen verbeißen, bis sie einen Zugang fin­den. Mit einer Kundendatenbank voller Kontoinformationen können sie schließlich wesentlich mehr anfangen als mit den Bildern einer erfolgrei­chen Goldfischzucht.

1.3     Wichtige Begriffe

Um in den folgenden Kapiteln nicht stets neue Erklärungen finden zu müs­sen, möchten wir einige wichtige Begriffe aus dem Sicherheitsjargon vorab erklären.

Defense in Depth

Werden Sicherheitskonzepte angesprochen, taucht das Schlagwort »Defense in Depth« immer öfter auf, um ein möglichst schlagkräftiges Sicherheitsprinzip zu beschreiben. Und tatsächlich ist das Prinzip der »Tie­fenverteidigung«, wie eine deutsche Übersetzung des Begriffes lauten könnte, bei konsequenter Umsetzung sehr wirksam.

Der von Defense in Depth verfolgte Ansatz geht von einer zwiebelscha­lenförmigen Sicherung aus, bei der eine Anwendung durch Sicherheitsmaß­nahmen auf mehreren Ebenen geschützt ist.

Netzwerk

Diese Sicherung beginnt bereits auf der Netzwerkebene: Firewalls trennen die Webinfrastruktur vom inter­nen Netzwerk oder VPN des Betreibers, und Paketfilter sorgen dafür, dass nur diejenigen Benutzer Zugriff auf sensitive Bereiche haben, die auch administrativ dafür zugelassen sind.

Betriebssystem

Auf Betriebssystemebene setzt die zweite Verteidigungslinie gegen Cracker und sonstige Finsterlinge an: Ein gehärteter Linux-Kernel wehrt selbsttätig Angriffe gegen den IP-Stack oder interne Funktionen ab und erlaubt kein Nachladen und Ausführen von Kernel-Modulen. Eine im Ker­nel implementierte Changeroot-Umgebung (chroot) separiert Anwendun­gen voneinander – und weitere Maßnahmen, die auf Betriebssystemebene implementiert werden.

Web Application Firewall

Eine Web Application Firewall (WAF), die webbasierte Angriffe aus dem produktiven Traffic herausfiltert und die Administratoren informiert, ist die dritte Verteidigungsebene.

Webserver

Bei Webapplikationen ist die nächste Ebene einer Defense-in-Depth-Strategie der Webserver, der im Rahmen seiner Möglichkeiten gehärtet wer­den sollte. Dazu gehören nicht nur Techniken zur Vermeidung von Informa­tionslecks, sondern auch Sicherheitsmaßnahmen wie der Einsatz von SSL. Auch das Apache-Modul mod_security, das sich selbst bereits als WAF bezeichnet, oder chroot- und suExec-Mechanismen sind Teil dieser Ebene.

PHP-Anwendungen

Die nächste Ebene des Defense in Depth sind die PHP-Anwendungen selbst, und damit der Hauptgegenstand dieses Buches. Auch diese Anwen­dungen lassen sich wiederum in Schichten aufteilen, die separat voneinan­der gesichert werden.

Ein-/Ausgabeu

Auf der Datenebene sollte gewährleistet sein, dass keine schadhaften oder in böswilliger Absicht erstellten Daten (wie XSS-Angriffe zweiter Ord­nung, siehe den nächsten Abschnitt) in die Datenspeicher gelangen können. Die Datenabfrageschicht sollte so implementiert sein, dass Angreifer nicht durch Tricks andere Daten als die vom Entwickler vorgesehenen abfragen können – und die Ein-/Ausgabeschicht muss Eingaben auf Schadcode über­prüfen, diesen abfangen und möglicherweise unerwünschte Ausgaben ver­hindern.

Der Vorteil an dieser Sicht der Dinge ist, dass die Zusammenarbeit zwi­schen den verschiedenen Schichten ähnlich wie im OSI-Modell geregelt ist: Jede Schicht kommuniziert nur mit der ihr direkt vorangehenden und nach­folgenden Ebene. Dadurch können Entwickler und Administratoren mit der größtmöglichen Unabhängigkeit voneinander arbeiten, um ihren jeweiligen Teil der Anwendung abzusichern.

First und Second Order

Bei Angriffen gegen andere Systeme geht man grundsätzlich von zwei ver­schiedenen Angriffstypen aus, und zwar von direkten Angriffen der ersten Ordnung und indirekten oder Angriffen der zweiten Ordnung.

First Order

Ein Angriff erster Ordnung liegt vor, wenn durch eine SQL-Injection, XSS (was dies alles ist, erfahren Sie in den folgenden Kapiteln) oder eine sonstige Attacke direkte Ergebnisse geliefert werden, also etwa die Liste der Administratorpasswörter aus der entsprechenden Datenbanktabelle gelesen und angezeigt wird, oder JavaScript-Code direkt im Kontext der angegriffe­nen Webseite ausgeführt wird. Angriffe erster Ordnung erlauben dem Angreifer, aufgrund der Antwort des angegriffenen Systems sein Vorgehen zu optimieren und sein Ziel zu erreichen. Dadurch sind First-Order-Angriffe in der Regel leichter durchzuführen als Second-Order-Attacken.

Second Order

Die Angriffe zweiter Ordnung müssen meist »blind« durchgeführt werden. Der Angreifer weiß oder vermutet, dass an einer bestimmten Stelle in der Zielanwendung nur ungenügende Eingabevalidierung vorgenommen wird, kann diese Tatsache jedoch nicht direkt ausnutzen, weil er an das betroffene Subsystem nicht herankommt. Ein klassisches Beispiel wird im Kapitel 4 »Cross-Site Scripting« behandelt: Log-Dateien oder -Datenban­ken sind ein prädestiniertes Ziel für Second-Order-Angriffe. Der Angreifer sorgt dafür, dass mit Schadcode versehene Anfragen gespeichert werden, und wartet nun darauf, dass ein Administrator der Zielanwendung diese Daten auswertet. Ob und wann das geschehen wird und ob der Angriff dann auch erfolgreich sein wird, kann er nur selten vorhersagen.

Somit sind Second-Order-Angriffe häufig wesentlich komplizierter und langwieriger in der Durchführung, was dazu führt, dass Entwickler und Administratoren ihnen nur geringe Bedeutung beimessen. Die Tatsache, dass sie jedoch meist direkt gegen Inhaber hoch privilegierter Accounts gerichtet sind, macht diese Angriffsklasse für Angreifer wie Verteidiger gleichermaßen zu einer lohnenden Herausforderung.

1.4     Sicherheitskonzepte

Security is a process, not a product.
        Bruce Schneier^[4]

Seitdem elektronische Datenverarbeitung existiert, haben sich kluge Köpfe Gedanken um die Sicherung der Daten und Systeme gegen Missbrauch gemacht. Die resultierenden Sicherheitskonzepte sind oft grundsätzlich feh­lerhaft – etwa indem sie nur zur Zeit der Erstellung aktuelle Technologien berücksichtigen oder sich auf die Geheimhaltung bestimmter Daten verlas­sen. Beides hat sich in der Vergangenheit oft als Trugschluss erwiesen.

Auch Verschlüsselungsalgorithmen oder Verfahren zur Erhöhung der Sicherheit sind nicht dadurch vertrauenswürdig, dass sie von ihrem Entwickler geheim gehalten werden. Obwohl die Mechanismen zur Passwort­verschlüsselung z.B. bei Microsoft Windows nicht öffentlich zugänglich waren, konnten sie doch überwunden werden.

Der lange Zeit als unüberwindbar geltende RC5-64-Verschlüsselungs­algorithmus wurde von einem Projekt Zehntausender Anwender auf der ganzen Welt in gut vier Jahren geknackt. Laut Moores Gesetz verdoppelt sich die Leistung der jeweils aktuellen Prozessorgeneration immer noch alle 18 Monate.

Prüfsummen, die mit den Algorithmen SHA-1 oder MD5 erstellt wur­den, lassen sich inzwischen in endlicher Zeit durch sogenannte »Kollisio­nen«, also die Erstellung einer identischen Prüfsumme für zwei verschie­dene Ausgangswerte, überlisten^[5].

Daher sollte ein Sicherheitskonzept nicht daraus bestehen, sich auf die Vertraulichkeit der eingesetzten Werkzeuge zu verlassen oder darauf zu ver­trauen, dass die für einen Angreifer verfügbare Rechenleistung nicht ausrei­chen wird, um Ihren Verschlüsselungsalgorithmus zu brechen. Mit Seiten wie passcracking.com^[6] und neuartigen zeitsparenden Brute-Force-Verfah­ren sind selbst MD5-Passwörter in einer recht kurzen Zeit zu knacken.

Um zu einem tragfähigen Sicherheitskonzept für Ihre Firma oder auch nur Ihre privat entwickelte PHP-Applikation zu gelangen, sind einige Schritte notwendig. Die tatsächliche Absicherung Ihrer PHP-Skripte ist nur einer dieser Schritte, wenn auch der wichtigste.

Betreiben Sie eine dynamische Website auf einem eigenen Server, müs­sen Sie (oder Ihre Mitarbeiter) dafür sorgen, dass nicht nur die verwendeten PHP-Anwendungen sicher sind, sondern auch dass alle anderen von außen erreichbaren Dienste keine Angreifer hereinlassen. Ihre Systeme sind nur so sicher wie das schwächste Glied in der Kette – in vielen Fällen ist das jedoch mit heißer Nadel gestrickte PHP-Software. Einen kompletten Leitfa­den zur Absicherung Ihrer Serversysteme zu schreiben, würde den Rahmen dieses Buches sprengen – wir werden uns hauptsächlich mit PHP und eini­gen von PHP verwendeten Subsystemen wie Web- und Datenbankservern beschäftigen.

In einem Unternehmen, das vertrauliche Informationen behandelt, muss ein Sicherheitskonzept integraler Bestandteil der Firmenprozesse und -politik sein. Datenverluste oder – schlimmer noch – Datendiebstähle gehö­ren im Informationszeitalter zu den unangenehmsten Vorkommnissen für jede Firma.

Ein tragfähiges Sicherheitskonzept ist sehr umfangreich und kann nicht auf wenige Punkte reduziert werden. Ein guter Anhaltspunkt ist die interna­tionale Richtlinie ISO 17799, »Code of Practice for Information Security Management«, die als industrieweit anerkannter Standard für den sicheren Umgang mit IT-Systemen und allen dazugehörigen Subsystemen gilt. Wie alle ISO-Standards ist die Richtlinie leider nicht kostenlos erhältlich, kann aber direkt bei der ISO bestellt werden. Obgleich in ISO 17799 (die in vie­len Unternehmen als BS 7799, kurz für »British Standard«, bekannt ist) kein Bezug auf webbasierte Systeme genommen wird, enthält die Richtlinie viele wichtige Anregungen, die Sie benutzen können, um die sicherheitsre­levanten Abläufe in Ihrem Unternehmen zu verbessern.

Im nächsten Abschnitt fassen wir die wichtigsten Punkte der Richtlinie kurz für Sie zusammen und erläutern den Zusammenhang mit PHP-Sicherheit.

1.5     ISO 17799

Besonders in großen Unternehmen ist die Sicherheit der IT-Infrastruktur und ganz besonders der unternehmensinternen Daten eines der wichtigsten Ziele. Um Abläufe zu standardisieren und das Handling sicherheitsrelevan­ter Prozesse auf einen einheitlichen Nenner zu bringen, wurde von der Bri­tish Standards Institution (BSI, nicht zu verwechseln mit dem deutschen Bundesamt für Sicherheit in der Informationstechnik) der Standard 7799 ins Leben gerufen. In diesem Dokument werden ausführlich »Best Practices«, also als vorbildlich anerkannte Abläufe für die Sicherheit in Informations­systemen, aufgeführt. Neben Aspekten wie der physischen Zugangssiche­rung enthält das Standardwerk, das mittlerweile als internationaler Standard ISO 17799 aufgelegt wurde, auch für Webanwendungen wichtige Punkte.

Die ISO unterteilt Sicherheit in Informationssystemen in drei Faktoren, die in einem sicheren System stets erfüllt sein sollten:

 Vertraulichkeit, also die Sicherheit, dass Information nur dem zugäng­lich ist, der über die notwendige Autorisierung verfügt.

 Integrität – Informationen und informationsverarbeitende Vorgänge müssen stets akkurat und vollständig sein.

 Die ständige Verfügbarkeit aller Informationssysteme für berechtigte Benutzer ist der dritte wichtige Faktor.

Der Standard schreibt vor, dass alle Mechanismen, die zur Wahrung dieser Faktoren etabliert werden, regelmäßig kontrolliert werden sollen, um auch auf neue Anforderungen reagieren zu können. Das werden die meisten Administratoren von Webservern intuitiv beherzigen – ist doch die Kon­trolle auf neue Software-Updates nichts anderes als das, was der Standard fordert.

Auch auf die Absicherung bei »third-party access«, also dem Zugriff Dritter auf die eigene Infrastruktur, legt ISO 17799 Wert. In der PHP-Welt ist das beispielsweise ein API Ihrer Anwendung, an die Ihre Kunden ihre eigenen Anwendungen anschließen können, um Funktionen und Informationen mit Ihrem System auszutauschen. Hier sollten Vereinbarungen vor Missbrauch schützen.

Auch die Sicherheit von Zugangskennungen wird behandelt – dem Standard folgend, sollten Sie Ihren Benutzern – sei es in einem PHP-Forum, einem CMS oder einer Administrationsoberfläche – nur exakt die Privile­gien geben, die für die Ausführung der jeweiligen Aufgabe notwendig sind, und darauf achten, dass Passwörter sicher sind und geheim bleiben. Tempo­räre Passwörter, die direkt nach der Registrierung oder auf Anforderung durch den Benutzer vergeben werden, sollten auf einem sicheren Weg (nicht im Klartext per E-Mail, wie leider meist üblich, sondern möglichst per SSL-geschützter HTTP-Verbindung) übergeben und vom Benutzer sofort geän­dert werden.

Eine vollständige Besprechung der ISO 17799 bzw. der Nachfolger dieser Richtlinie würde den Rahmen die­ses Buches sprengen. Sie ist jedoch als Zusammenfassung der Vorgänge und Arbeitsweisen, die guten Systemadministratoren in Fleisch und Blut übergegangen sind, eine wertvolle Hilfe. ISO 17799 kann kostenpflichtig im Internet direkt über den Onlineshop der ISO^[7] bestellt werden.

1.6   Wie verkaufe ich Sicherheit?

Wenn Sie dieses Buch lesen, sind Sie vielleicht auf irgendeine Weise profes­sioneller PHP-Entwickler – entweder als freiberuflicher Programmierer oder als Angestellter in einem Unternehmen. Möchten Sie Ihre bestehenden PHP-Anwendungen sichern oder eine neue Anwendung mit besonderem Augenmerk auf die Sicherheit entwickeln, werden Sie feststellen, dass dies mit höherem Aufwand verbunden ist, als das Skript einfach »herunterzuha­cken«. Ihr Auftrag- oder Arbeitgeber muss diesen Aufwand finanzieren, und Sie müssen begründen können, warum diese Zusatzkosten zwingend notwendig sind.

Was für Sie völlig einleuchtend sein dürfte – schließlich hätten Sie sonst nicht dieses Buch gekauft, ist Managern oder Projektleitern oft leider nicht ganz so leicht zu vermitteln.

Insbesondere in Unternehmen, deren Hauptgeschäftsfeld nicht die IT ist, ist die »Security Awareness«, also das Sicherheitsbewusstsein, oft nur ungenügend ausgeprägt. Das äußert sich in Problemen wie per Post-It-Haft­notiz am Monitor befestigten Passwörtern, aber auch in einer gewissen Nai­vität für Applikationssicherheit.

Für Manager zählt hauptsächlich, wie sich eine Ausgabe rechnet: Ergibt sich nach Gegenrechnung aller Kosten noch immer ein Gewinn für das Unternehmen, sind Ausgaben leicht zu vermitteln. Sicherheit bringt allerdings direkt keine zusätzlichen Umsätze, ist also zunächst als Kosten­faktor ohne Gewinn einzustufen.

Genauer betrachtet, stimmt das natürlich nicht – das müssen Sie dem Management vermitteln. Entwickeln Sie ein Softwareprodukt, das später von Ihrer Firma verkauft oder lizenziert werden soll, ist Sicherheit ein wich­tiges Produktmerkmal, das die Verkäufe äußerst positiv beeinflussen kann. Setzen Sie webbasierte Anwendungen für das eigene Unternehmen ein, können Sie Datensicherheit nur dann gewährleisten, wenn die Anwendung gegen Diebstahl von Sessions, SQL-Injection und XSS abgeschottet ist.

Der Verlust von Kundendaten kann ernste juristische Konsequenzen nach sich ziehen und zum Ruin Ihres Unternehmens führen. So musste das amerikanische Unternehmen CardSystems im Juni 2005 zugeben, dass die Kreditkartendaten von über 40 Millionen Kunden durch Hacker gestohlen worden waren.[8] Die Firma führte als sogenannter »Third Party Processor« Kreditkartentransaktionen im Auftrag von Händlern durch und leitete diese an die Kreditkartenunternehmen weiter.

Da der Diebstahl durch eine Sicherheitslücke im Netzwerk des Unter­nehmens und fahrlässiges Verhalten einiger Mitarbeiter möglich wurde, kündigten daraufhin einige Kreditkartenfirmen ihre Verträge mit CardSys­tems und entzogen der Firma dadurch die Grundlage ihrer Dienstleistungen.

Bei webbasierten Anwendungen ist ein Beispiel für den durch Sicher­heitslücken entstehenden Vertrauensverlust das Portalsystem phpNuke. Obgleich die Idee und der Funktionsumfang von phpNuke prinzipiell sehr nützlich sind, hat die Menge an konzeptbedingten Sicherheitslücken das Open-Source-Projekt so weit diskreditiert, dass man von einer Installation inzwischen nur noch abraten kann. Auch das freie Forensystem phpBB hat in letzter Zeit durch viele kritische Sicherheitslücken, die unter anderem den Wurm »Santy« ermöglichten, von sich reden gemacht – einige Hosting-Firmen verbieten in der Konsequenz den Einsatz dieses Forums auf ihren Servern.

Verdient Ihr Unternehmen sein Geld mit der Entwicklung und dem Ver­kauf webbasierter Applikationen, können solche Boykottaktionen empfind­liche Umsatzeinbußen bedeuten – schon eine auf Security-Mailinglisten veröffentlichte kritische Lücke wird viele Administratoren davon abhalten, Kaufempfehlungen für Ihr Produkt auszusprechen. Denn: Wo ein Fehler ist, sind meist noch ein paar ähnliche Schnitzer, und viele Sicherheitslücken beruhen nicht nur auf nachlässiger Programmierung, sondern auf einem fehlerhaften Programmkonzept. Haben Sie Ihren guten Ruf als fähige Ent­wickler erst einmal durch einige Sicherheitslücken verspielt, ist es praktisch unmöglich, diesen wiederherzustellen – denken Sie nur an Sendmail, Bind oder wu-ftpd, die Musterbeispiele bekannter Open-Source-Produkte mit ellenlanger Fehlerliste.

Neben den direkten Folgen juristischer oder strafrechtlicher Art hat ein »Hack« in einem Ihrer Produkte somit auch verheerende Auswirkungen auf den Ruf Ihrer Firma. Das sollten Sie und auch Ihre Vorgesetzten sich stets vor Augen führen, wenn es darum geht, auf Kosten der Sicherheit zu sparen.

1.7   Wichtige Informationsquellen

Dieses Buch bemüht sich, Ihnen einen Überblick über die heute bekannten Angriffsklassen bei webbasierten Applikationen zu verschaffen, kann jedoch nie auf dem neuesten Stand sein. Serveradministratoren und PHP-Entwickler sollten daher andere Informationsquellen nutzen, um stets »up to date« zu sein. Das betrifft sowohl ganz konkrete Lücken in PHP-Applika­tionen als auch generelle Techniken und Konzepte. So tauchte etwa im Jahr 2005 die Angriffsklasse »HTTP Response Splitting« erstmals auf, die zuvor völlig unbekannt war und daher auch nur von wenigen Anwendungen abge­federt wurde. Derlei neuartige Angriffsmuster werden oft zunächst theore­tisch in einer Veröffentlichung diskutiert, bevor sie praktisch implementiert und schließlich von Scriptkiddies aus aller Herren Länder ausgenutzt werden.

1.7.1     Mailinglisten

Das Gros dieser Diskussionen findet auf den Mailinglisten »BugTraq«, »Full Disclosure« und »WebAppSec« statt. Insbesondere die ersten beiden Listen gelten als die besten Adressen für die neuesten Exploits und Fehler – jeder Serveradministrator ist in der Pflicht, mindestens eine der beiden zu abonnieren.

Die übliche Netiquette gilt natürlich auch hier – insbesondere sollten Sie darauf achten, bei Abwesenheit nicht mit einem Autoresponder den mehreren Tausend anwesenden Hackern mitzuteilen, dass Ihre Server momentan leider ungeschützt sind, da Sie im Urlaub weilen. Autoresponder auf »BugTraq« sollen schon für den einen oder anderen Servereinbruch gesorgt haben – und zudem können Sie sicher sein, das Ziel des teilweise recht drastischen Spottes der Liste zu werden.

1.7.2   Full Disclosure

Die Liste »Full Disclosure« ist nicht nur eine Mailingliste, sie steht für eine Art Lebensgefühl in der Security-Gemeinde. Mit »Full Disclosure« wird die Praktik beschrieben, Sicherheitslücken nach Bekanntwerden und Behebung durch den Softwarehersteller mit allen Details zu melden – und zwar eben an die Mailingliste Full Disclosure. Postings an FD, so der Kurzname der Liste, enthalten neben ausführlichen Informationen zu einer gefundenen Sicherheitslücke oft sogenannten »Proof of Concept«-Code, also ein kurzes Skript oder Programm, das das Vorhandensein der Lücke demonstriert. Da diese Nachweise eines Problems nicht selten den Entwicklern von Wür­mern, Rootkits oder Exploits als nützliche Vorlage dienen, ist Full Disclos­ure bei Sicherheitsexperten umstritten. Insbesondere ein großer Software­hersteller aus Redmond hat sich in der Vergangenheit vehement gegen dieses Vorgehen gewehrt, sei es doch unverantwortlich und führe zu einer massiven Bedrohung der Internet-Infrastruktur. Auch das US-Heimat­schutzministerium versuchte in der Vergangenheit, vollständige Veröffentli­chungen von Lücken zu unterbinden, die US-Copyright-Gesetze im Digital Millenium Copyright Act (DMCA, siehe Glossar) sollten dabei helfen.

Trotz dieser Widrigkeiten hält sich die Praxis der Full Disclosure wei­terhin, was die Liste für Systemadministratoren zu einer unentbehrlichen Quelle macht: Zum einen werden Security-Hinweise (die sogenannten »Advisories«) auf keiner anderen Mailingliste so schnell veröffentlicht wie auf FD, und zum anderen kann die tatsächliche Gefahr, die von einer Lücke ausgeht, anhand der Liste gemessen werden. Sobald ein Exploit dort veröf­fentlicht wurde, können Sie davon ausgehen, dass jeder mit einfachsten Mitteln Angriffe gegen die verwundbare Software starten kann – spätestens dann sollten Sie eine Nachtschicht einlegen, um Ihre Systeme zu patchen.

Da FD nicht moderiert wird, ist die Latenz zwischen Posting und Veröf­fentlichung zwar sehr kurz, es kommt jedoch fast täglich zu äußerst unange­nehmen und ermüdenden Flamewars zwischen den anwesenden Security-Experten, vereinzelten Scriptkiddies und den wie auf jeder großen Liste reichlich vorhandenen Unruhestiftern. Diese Scharmützel ziehen sich teil­weise über Tage hin und sorgen für ein sehr schlechtes Signal-Rausch-Ver­hältnis.

Die Liste Full Disclosure sollte trotzdem Ihre tägliche Pflichtlektüre werden – abonnieren können Sie sie einfach mit einer Mail an die Adresse full-disclosure-request@lists.grok.org.uk; das Subject sollte »subscribe« (ohne Anführungszeichen) lauten. Alternativ können Sie über das Webinterface^[9] ein Abonnement anfordern.

Der Sicherheitsexperte Kurt Seifried betreibt eine inoffizielle, mode­rierte Version von Full Disclosure, auf der er unerwünschte oder überflüs­sige Postings ausfiltert. Diese Liste können Sie online^[10] bestellen – ob Sie die Moderation durch einen Dritten benötigen, sollten Sie jedoch selbst ent­scheiden. Der zentrale Vorteil von Full-Disclosure – die geringe Latenz zwischen Veröffentlichung einer Sicherheitslücke und ihrem Bekanntwerden auf der Liste – geht so nämlich weitgehend verloren.

1.7.3     BugTraq

Im Gegensatz zur ungefilterten Full Disclosure ist BugTraq eine moderierte Mailingliste. Der Moderator David Ahmad überprüft jedes Posting, um Fla­mewars und »Trolle«, also Störenfriede, nach Möglichkeit fernzuhalten. Der Traffic auf BugTraq ist daher meist um eine Größenordnung geringer als auf FD.

Andererseits sind die Diskussionen dort bei Weitem nicht so lebhaft und aufschlussreich wie in der Nachbarliste – meist beschränken sich Postings auf Advisories aller Art. Sicherheitsexperten melden gefundene Lücken in Softwareprodukten, und die Hersteller reagieren mit einer Benachrichti­gung, sobald das Problem behoben ist.

Einen Gutteil des Verkehrs auf BugTraq machen Advisories der Anbie­ter von verschiedensten Linux-Distributionen aus, die ihre Nutzer auf sicherheitsrelevante Updates hinweisen.

BugTraq ist mittlerweile mehr oder minder eine reine Ankündigungsliste, der Diskurs findet inzwischen an anderen Stellen statt. Wenn Sie Zeit sparen möchten, empfiehlt sich ein Abonnement dieser Mailingliste statt eines FD-Abos.

BugTraq können Sie abonnieren, indem Sie eine leere Mail an die Adresse bugtraq-subscribe@securityfocus.com senden.

1.7.4     WebAppSec

Für Entwickler von Webapplikationen hochinteressant ist die Liste WebAppSec (kurz für »Web Application Security«). Hier tauschen sich Webentwickler jeder Couleur über Sicherheitsfragen aus. Nicht nur Lücken und Exploits gehören zum Thema der Liste, sondern auch Diskussionen über den Einsatz von SSL, Webserver-Sicherheit und Firewalls. Auf der Liste gehen üblicherweise nicht mehr als zehn Postings pro Tag ein, und die Schnittmenge mit Beiträgen auf BugTraq oder Full Disclosure ist praktisch null. Daher sollten Sie ein Abonnement in Erwägung ziehen – Postings sind in der Regel von hoher Qualität und für Webentwickler interessant.

Auch für ein WebAppSec-Abonnement genügt eine leere Mail, in die­sem Fall an die Adresse webappsec-subscribe@securityfocus.com.

1.8     OWASP

Open Web Application Security Project

Eine der wichtigsten Ressourcen für an Sicherheit interessierte Web­entwickler ist das Open Web Application Security Project, kurz OWASP. Hier versammeln sich Programmierer aus aller Herren Länder, um gemein­same Richtlinien für Web Security zu definieren und zu pflegen. Eine sehr umfangreiche Bibliothek enthält Checklisten, How-Tos und Filterbiblio­theken für verschiedene Sprachen.

Ein Ziel des OWASP ist es, feste Standards zu definieren, die jeder Ent­wickler befolgen sollte, um ein Mindestmaß an Sicherheit für seine Appli­kationen garantieren zu können. Das Projekt stützt sich hierbei besonders auf die ISO-Richtlinie 17799 (bzw. ihr britisches Äquivalent BS7799). Zusätzlich gehen die Projektmitglieder auf andere internationale Standards für Sicherheit im Allgemeinen und speziell für Applikationssicherheit ein – für jeden Entwickler, dessen Software auf der ganzen Welt eingesetzt wer­den soll, ist die Konformität mit diesen Standards unverzichtbar.

Von besonderem Interesse für jeden PHP-Entwickler ist der »Guide to Building Secure Web Applications and Web Services«^[11]. Dieses über 200-seitige Dokument enthält zahlreiche Anregungen und Best Practices für Entwickler webbasierter Applikationen – auch die Autoren dieses Buches konnten noch das eine oder andere vom OWASP-Guide lernen.

Ein weiteres interessantes Dokument ist die »OWASP Web Application Penetration Checklist«, die als Grundlage für die Security-Checkliste im Anhang diente. Neben den auch in unserem Buch enthaltenen sicherheitsre­levanten Punkten zum Abhaken geht sie auch auf den Ablauf eines »Pen­tests«, also eines Penetrationstests für Webapplikationen ein, um Entwick­lern und externen Sicherheitsexperten Hilfestellung für Sicherheitsüberprüfungen zu geben.

Das als PDF erhältliche Dokument steht – ebenso wie der »Guide for Building Secure Web Applications« – unter der GNU Documentation License und kann von jedermann frei verwendet, geändert und für die eigene Dokumentation eingesetzt werden.

Die Teilnahme an der OWASP steht jedem offen – es werden für einige Themen noch Freiwillige gesucht, die Inhalte liefern können.

1.9   PHP-Sicherheit.de

Natürlich gibt es zu diesem Buch auch eine Website, getreu dem Motto »Nichts ist so alt wie die Sicherheitslücke von gestern«. Neben Errata und Aktualisierungen werden wir versuchen, in einem Weblog aktuelle Lücken in PHP-Applikationen aufzulisten und zu kommentieren. So können sich PHP-Entwickler an einem Ort über Lücken und Bugs in der von ihnen eingesetzten Software informieren und sparen sich im besten Falle das Abonnement der oben aufgeführten Security-Mailinglisten.

Darüber hinaus werden Artikel zu PHP-Sicherheit und Vorträge über dieses Thema auf der Website^[12] zum Buch veröffentlicht.