Rezension des Buches „Web-Sicherheit“ von Sebastian Kübeck

Inhalte des Buches

Der Autor gliederte das Buch in folgende Teile:

1. Grundlagen der Informationssicherheit
2. Die häufigsten Schwachstellen und deren Vermeidung
3. Testen und Absichern von Webanwendungen

Im ersten Teil gibt es einen kurzen historischen Abriss zu Computern und deren (Un)sicherheit. Es wird auf die Auswirkungen von Sicherheitsproblemen eingegangen. Schließlich werden einige Prinzipien der Informationssicherheit erklärt und auf kryptografische Verfahren sowie Verfahren zur Authentifizierung erklärt.

Der zweite Teil des Buches beschreibt dann konkrete Schwachstellen. Das Themengebiet reicht von Injections, XSS und CSRF über fehlerhafte Authentifizierung und Autorisierung bis hin zu Buffer Overflows sowie DoS-Attacken.

Der letzte Teil des Buches beschreibt schließlich, wie die Sicherheit von Webanwendungen getestet und wie gefundene Schwachstellen behoben werden können. Es gibt einen Abschnitt zu sicherer Entwicklung von Webapplikationen, Code Reviews und zu Penetration Tests.

Neben dem Buch stellt der Autor eine Demoanwendung zur Verfügung. Die ZIP-Datei besteht aus dem Quellcode sowie einer WAR-Datei zum Einsatz mit dem Apache Tomcat.

Meine Einschätzung

Allgemeines zum Buch

Die grobe Struktur des Buches hat mir gut gefallen. Der Leser kann dadurch an die Hand genommen werden und bekommt zunächst einen Überblick über die Theorie. Später lernt er dann die praktischen Seiten kennen. Schließlich sieht er, wie Fehler zu vermeiden oder zu erkennen sind. Dennoch glaube ich, dass das Buch an einigen Stellen dieser Erwartung nicht gerecht wird. Im Rahmen einer neueren Auflage sollte eventuell an den unten stehenden Punkten gearbeitet werden.

Eine Sache, die mich nach wie vor erstaunt, ist die Wahl der Programmiersprache. Es wird fast einheitlich Java verwendet. Nach meinen Beobachtungen spielt Java bei vielen Schwachstellen im Web eher eine untergeordnete Rolle. Des Weiteren halte ich Java für eine schwierige Lehrsprache. Der Aufwand, den Quellcode zu verstehen, ist beim Leser wahrscheinlich höher, als bei Skriptsprachen, wie PHP, Python oder Ruby. Aus meiner Sicht sollten eben diese Sprachen präferiert werden. PHP-Programmierer erschaffen noch immer eine hohe Zahl verwundbarer Anwendungen. Daher sollte die Sprache die erste Wahl sein. Denn dies macht es den Programmierern unter Umständen einfach, das durch das Buch erworbene Wissen auf den eigenen Arbeitsalltag zu übertragen. Python halte ich für eine sehr gute Lehrsprache. Man merkt dieser immer noch an, dass sie eben genau zu dem Zweck entwickelt wurde. Daher wäre dies ein guter Kandidat. Aber auch in Ruby lassen sich einfache und klare Programme schreiben.

Anfangs habe ich mich sehr über die Demoanwendung gefreut. Denn dies sollte den Lesern des Buches helfen, die Beispiele zu verstehen und sie anleiten, selbst zu experimentieren. Jedoch spielt die Anwendung im Buch nahezu keine Rolle. Obwohl im Buch Quellcode aus der Demoanwendung verwendet wird, gibt das Buch darauf keine (oder zu wenige) Hinweise. Die Codebeispiele erscheinen autark und fallen mehr oder weniger vom Himmel. Hier wäre es sehr zu wünschen, dass auf die Demoanwendung verwiesen wird. Die Codebeispiele sollten immer den Dateinamen enthalten.

Die Referenzen sind nach Kapiteln geteilt. Dabei fehlt auf der Seite 314 „Teil 2“ bzw. es müsste auf Seite 309 „Teil 1“ weggelassen werden. Weiterhin sollte die Referenz auf Seite 317 zu dem Buch von Jeffrey Friedl auf einer eigenen Zeile stehen. Ich finde die umfassende Liste der Referenzen sehr wichtig und gut. So kann der Leser sich weiterführend informieren. Mich hat die Zitierweise der Form [Autor Jahr] bei zitierten Request for Comments (RFCs) und diversen anderen Dokumenten irritiert. Hier wäre es besser, beispielsweise [RFC Nummer] zu verwenden. Dadurch wird klarer, worauf im Text verwiesen wird. Weiterhin bin ich unsicher, wie ich die Trennung der Referenzen in die Teile bewerten soll. Einerseits gefiel mir diese Idee gut. Bei der Lektüre des Buches stellte ich jedoch fest, dass es immer Schwierigkeiten gab, die entsprechende Referenz zu finden. Weiterhin sind durch die Trennung Werke doppelt zitiert. Vielleicht wäre es daher besser, die Trennung wegzulassen. Schließlich wurde der Schlüssel [Daswani 2007] (Seite 310) doppelt vergeben. Mir fiel auf, dass es sehr oft Verweise auf Sekundärquellen (SPIEGEL, Heise etc.) gab. Der interessierte Leser muss schließlich recherchieren, bis er den Originalartikel findet. Ein Verweis zu den Primärquellen wäre daher angebracht.

Der Index des Buches ist sehr gut aufgebaut und sollte den Leser schnell zu den gewünschten Stellen bringen. Hier würde ich mir nur wünschen, dass der Wortanfang bei zusammengesetzten Worten weggelassen wird. Also z.B. bei Sicherheit, Sicherheitsnetz und Sicherheitstest sollte im Index Sicherheit, -netz und -test mit dem Seitenverweis stehen.

Zum ersten Teil

Der erste Abschnitt im ersten Teil möchte eine kurze Geschichte der Computerkriminalität erzählen. Der Autor startet bei frühen Computern in den sechziger Jahren und arbeitet sich bis zum heute vor. Mir kommt dieser Abschnitt zerhackt vor. Denn zuerst wird die Geschichte bis zu den Phreakern erzählt. Im folgenden geht der Autor auf Time-Sharing und den Hacker-Begriff sowie anderes ein. Aber gerade ausgehend von den Phreakern liesse sich die Geschichte gut weiterentwickeln. Denn aus diesen Kreisen entstand letztlich die Hackerbewegung und es entwickelte sich die Forschung um Sicherheit von Rechnersystemen. Weiterhin hätte ich mir gewünscht, dass der Morris-Wurm genauer beschrieben wird. Denn diesen kann man als Prototyp für viele der aktuellen Würmer ansehen.

In „2.2 Was passiert, wenn etwas passiert“ behauptet Kübeck, dass das Bundesinnenministerium Kontakt mit den Betreibern kompromittierter Systeme aufnehmen würde. Dies halte ich für sehr gewagt und mir ist bislang noch kein Fall bekannt, in dem das der Fall war. Falls es überhaupt eine Kontaktaufnahme seitens der Behörden gibt, so eher vom BKA bzw. einem der LKAs oder von Polizeidienststellen. Es wäre dringend nötig, diesen Abschnitt klärend zu gestalten. In der jetzigen Form führt das zu Verunsicherung auf Seiten der Nutzer.

Im Buch wird auf den Abschnitt „2.3 Vorbereitungen für den Ernstfall“ als nähere Erläuterung für das Vorgehen bei Sicherheitsvorfällen verwiesen. Neben allgemeinen Hinweisen gibt es nur einen Verweis auf BSI-Maßnahmen. Der Abschnitt könnte daher ebenso gut weggelassen und vorher ein Verweis eingebaut werden.

Der erste Absatz auf Seite 50 sollte genauer formuliert werden. Es bleibt auch beim mehrmaligen Lesen unklar, welchen Fakt der Autor zum Ausdruck bringen will.

Auf der Seite 56 und anderen ist die Rede von Linux. Es sollte hier besser GNU/Linux heißen.

Die Überschrift auf Seite 60 ist aus meiner Sicht falsch gewählt. Im militärischen Bereich spricht man seit längerem von „Verteidigung in der Tiefe“ (also als 1:1-Übersetzung). Es wäre besser, dies hier beizubehalten bzw. ausnahmsweise mit dem englischen Begriff zu arbeiten. Weiterhin erscheint mir das Beispiel in dem Abschnitt unpassend gewählt. Der Autor geht hier eher auf die Einhaltung der Prinzipien von Kerckhoffs ein. Es sollte besser herausgearbeitet werden, wie gute Defense in Depth aussieht.

Die Referenz auf Seite 61 könnte besser [DSA1571] lauten. Siehe dazu meine oben stehenden Erläuterungen.

Auf der Seite 62 und einigen anderen werden immer wieder Filmbeispiele gebracht. Gerade auf dieser Seite wäre es besser, auf das vielfach angewendete 4-Augen-Prinzip zu verweisen. Dies ist „realer“ als ein Beispiel aus einem Film.

Die Verwendung des Namens „Chuck“ für den Bösewicht ist ungebräuchlich. In der Fachliteratur wird Eve für den passiven bzw. Mallory für den aktiven Angreifer verwendet. Die Begriffe wurde 1978 von Rivest et. al. in „A method for obtaining digital signatures and public-key cryptosystems“ festgelegt.

Auf der Seite 86 wird die Schlüssellänge und das Mooresche Gesetz diskutiert. Hier wäre es wünschenswert, wenn der Autor eine konkrete Empfehlung für Schlüssellängen abgibt. So könnte beispielsweise die ohnehin erwähnte Empfehlung des NIST gedruckt werden.

Beim Listing 6.1 wäre es angebracht, dass Beispiel innerhalb des Buches zu diskutieren und dem Leser klar zu machen, warum dies ein schwacher PNRG ist.

Im Abschnitt 6.4.4 wird behauptet, dass HMAC SHA-1 verwendet. Dem ist nicht der Fall. Ein HMAC kann mit einer beliebigen Hashfunktion erzeugt werden.

SSL bzw. TLS wird im Abschnitt 6.4.8 vergleichsweise kurz behandelt. Das ist jedoch ein wesentlich wichtiges Verfahren im Rahmen des Buches. Daher hätte ich mir gewünscht, dass gerade dies in wesentlich größerem Umfang behandelt wird.

Das Listing 6.3 ist aus meiner Sicht völlig unnötig für das Verständnis und kann gekürzt/weggelassen werden.

Zum zweiten Teil

Als ich mir den zweiten Teil durchlas, fiel mir auf, dass der Autor versucht, den Begriff der Sicherheit sehr weitgehend zu beschreiben. Jedoch fehlt etwas zum ersten Teil des Buchtitels, dem Web. Unter Umständen ist es sinnvoll, auf die Funktionsweise des Internet und des Web einzugehen. Das heißt, man könnte in kurzer Form auf TCP/IP eingehen, HTTP erklären und eventuell Technologien wie AJAX beschreiben. Aus meiner Sicht würde das das Buch in seiner jetzigen Form deutlich aufwerten.

Was mir in diesem Teil besonders gefallen hat, sind die Checklisten am Ende eines jeden Kapitels. Diese bieten dem Leser eine kurze Zusammenfassung und ggf. kann er Details im Kapitel nachlesen.

In Kapitel 8 wird das Thema Injection sehr gut aufgearbeitet und dem Leser sollte nach der Lektüre sowohl die Problematik wie auch Lösungsansätze bewusst sein.

Auf der Seite 123 sind in der ersten Zeile zu große Abstände zwischen den Worten.

Im Listing 9.1 würde die Zeile User: <%=request.getParameter(“user”)%> als Illustration reichen. Die folgende Erklärung zu dem Beispiel fand ich dann sehr gut. Dem Leser sollte damit die Problematik klar werden.

Im Abschnitt Session-Management beschreibt der Autor verschiedene Attribute, die eventuell zu setzen sind. Aus der Beschreibung wird jedoch nicht klar, wo diese zu setzen sind bzw. wer die setzen muss. Ein bis zwei Sätze mehr zur Erläuterung dieser Attribute würde nicht schaden. Weiterhin gehören die Punkte 5 und 6 der Aufzählung zusammen. Daher sollte diese in einem beschrieben werden. Am Ende des Abschnitts weist der Autor darauf hin, möglichst alles im Zusammenhang mit Benutzeraktivitäten zu protokollieren. Dabei sollte beachtet werden, dass es sich dabei regelmäßig um persönliche Daten handelt, die entsprechend schützenswert sind. Grundsätzlich sollten diese Daten eben nicht protokolliert bzw. schnellstmöglich wieder sicher gelöscht werden.

Der folgende Abschnitt 11.5 diskutiert Zwei-Faktor-Authentifizierung und verweist auf 6.4.7. Beide sind jedoch sehr kurz. Dem Leser des Buches wird wahrscheinlich nicht klar, wie dies umzusetzen ist. Weiterführende Erläuterungen oder ein Verweis auf Literatur sollte unbedingt vorhanden sein.

Die Schilderung von Path-Traversal-Verwundbarkeiten auf der Seite 163 ist aus meiner Sicht unvollständig oder unschlüssig. Es wird darauf verwiesen, dass ein Angreifer die Datei /etc/passwd auslesen kann. Danach suggeriert der Autor, dass sich schwache Passwörter errechnen lassen. Auf den diversen GNU/Linux-basierten Systemen sollte dies in der Standardinstallation seit mehr als zehn Jahren nicht mehr möglich sein. Denn die Passwörter sind in der /etc/shadow abgelegt. Die Datei ist nur von root les- und schreibbar. Zugriff auf die Datei besteht, wenn der Webserver mit falschen Nutzerrechten betrieben wird oder eine „kreative“ Installation vorhanden ist. Im folgenden wird beschrieben, dass ein Angreifer sich Root-Rechte verschaffen kann oder, falls dies nicht möglich ist, mittels eines hochgeladenen Skripts Schwachstellen aufspüren kann. Der Beschreibung nach zu urteilen, ist es dem Angreifer möglich sich einzuloggen. Insofern ist unklar, warum er nun extra ein Skript hochlädt. Er könnte genauso also eingeloggter Nutzer das System erforschen. Andererseits benötigt er Schreibrechte auf das DocumentRoot des Webservers. Dies ist auch nicht immer gegeben. Ich würde mir eine klarere Beschreibung des Gesamtvorgangs wünschen. Der Autor sollte hier eventuell mehr verweilen und durchaus auf andere relevante Kapitel (Pufferüberläufe usw.) verweisen.

Die Beschreibung zu Beginn von Kapitel 14 ist zu allgemein gehalten. Dem Leser drängt sich der Eindruck auf, dass hinter Problemen mit einer fremden Webanwendung ein DoS-Angriff steckt. Ich würde mir hier eine differenzierte Betrachtungsweise oder ein anderes Beispiel wünschen.

Der Abschnitt 15.1 heißt „Gefährliche Standardeinstellungen“. Jedoch diskutiert dieser nur das Risiko von Standardpasswörtern. Im Sinne der Überschrift wäre es sinnvoller, weitere Beispiele für gefährliche Standardeinstellungen zu finden.

Die Liste auf Seite 188 hat eine Nennung mit „… oder … oder …“. Ich finde dies ungewöhnlich und besser wäre es, eines der oder wegzulassen.

Auf der Seite 189 empfiehlt der Autor, einen Webserver ausschließlich auf den Ports 80 und 443 Dienste anzubieten. Mir erschließt sich nicht, warum man einen Webserver nicht auf einem beliebigen anderen Port laufen lassen sollte. Für die Sicherheit ist es unerheblich, ob dieser seine Dienste auf Port 80, 8080 oder 31337 anbietet. Eventuell sollte der Autor seinen Gedankengang genauer schildern.

Die Konfigurationsdatei im ersten Absatz auf Seite 190 heißt httpd.conf.

Ich bin über die Wortwahl „Testsystemen zu testen“ auf Seite 192 gestolpert.

Auf der Seite 193 verwendet der Autor den Ausdruck „monolithische Betriebssysteme“. Meines Wissens eignet sich derzeit nur Minix halbwegs für den Produktiveinsatz. Die Standardsysteme sind hingegen allesamt monolithisch. Insofern kann diese Information entfernt werden. Denn wahrscheinlich irritiert diese den Nutzer bzw. im Kontext des Absatzes drängt sich der Eindruck auf, dass nur Microsoft Windows monolithisch wäre.

Zum dritten Teil

Der dritte Teil des Buches beschäftigt sich mit Tests und Absicherung von Webanwendungen. Ich habe diesen Teil nur noch überflogen. Daher kann ich lediglich einen Eindruck schildern.

Der zweite Absatz des 16. Kapitels endet mit einem Satz, der sich über fünf Zeilen erstreckt. Im Sinne der Lesbarkeit sollte der in kleinere Elemente geteilt werden.

Der Teil „glänzt“ wieder mit Codewüsten. Die Seiten 207–214, 225–234, 242–248 und 260–280 bestehen zu großen Teilen nur aus Quellcode. Das ist nahezu die Hälfte des Teils. Wie ich schon an anderer Stelle schrieb, ist weniger mehr. Sinnvoll wäre es, relevante Teile zu drucken und auf den mitgelieferten Code zu verweisen.

Weiterhin macht es den Eindruck, dass das Programm Nikto relevant ist. Es wird mehrfach darauf verwiesen und ein Screenshot des Programms gezeigt. Im Index fehlt ein Eintrag zu dem Programm und wenn es wirklich so relevant ist, sollte es auch genauer beschrieben werden. In der jetzigen Version entsteht der Eindruck, das hier eine Lücke verblieben ist.

Fehler

• Seite 71: Wiederspruch -> Widerspruch
• Seite 197: Djikstra -> Dijkstra (ebenfalls im Index)