Skip to content

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

Da die Rezension etwas länger wurde, gibt es in der Artikelübersicht eine Zusammenfassung und in der erweiterten Ansicht alle Details.

Ich wurde kürzlich auf das Buch „Web-Sicherheit – Wie Sie Ihre Webanwendungen sicher vor Angriffen schützen“ von Sebastian Kübeck aufmerksam. Das Thema Web-Sicherheit spielt im Rahmen meiner Vorlesung zu IT-Sicherheit eine Rolle und daher war ich sehr daran interessiert, das Buch kennen zu lernen.

Der Aufbau des Buches gefiel mir sehr gut. Der Leser kann sich zuerst theoretisches Wissen erarbeiten, steigt dann in praktische Aspekte ein und lernt schließlich, wie er die Probleme umgeht.

Beim Lesen fiel mir dann auf, dass einige Teile meinen Erwartungen nicht gerecht werden. So wäre es bei einem Buch über Webanwendungen wünschenswert, dass es zumindest stichpunktartig auf die Techniken des Internet und des Web eingeht. Dieser Teil fehlt hier fast vollständig. Auch werden relevante Aspekte wie beispielsweise SSL zu kurz behandelt. Demgegenüber halte ich die Erwähnung des BTX-Hacks und anderer im Rahmen des Buches vernachlässigenswert.

Im ersten und zweiten Teil des Buches findet sich ein ausführliches Literaturverzeichnis. Das sollte dem Leser helfen, tiefer in die Thematik einzusteigen. Es wäre besser, dass die Zitierschlüssel geändert werden und mehr auf Fachliteratur statt auf Zeitschriftenartikel verwiesen wird.

Ich kann mich schlecht mit Java als Sprache für das Buch anfreunden. Aus verschiedenen Aspekten halte ich diese für weniger gut geeignet und Sprachen wie PHP, Python oder Ruby wären für mich eine bessere Wahl gewesen.

Im Buch selbst ist nach meiner Meinung zu viel Quellcode zu finden. Mindestens ein Fünftel besteht aus abgedrucktem Quellcode. Dabei ist zu viel Irrelevantes mit gedruckt. Für die Beispiele im Buch reichen oft wenige Zeilen. Code über viele Seiten finde ich zu unübersichtlich. Insbesondere auf Grund der Tatsache, dass sich der Autor auch die Arbeit gemacht hat und eine Demoanwendung mitliefert. Hier wäre es empfehlenswert, einfach die zur Erklärung des Beispiels relevanten Zeilen zu drucken und dann auf die betreffende Datei in der Demoanwendung zu verweisen.

Insgesamt bietet das Buch Licht und Schatten. Es hat viele gute Ansätze, die aber noch ausgearbeitet werden sollten. Wenn der Autor dies in einer nächsten Auflage schafft, so ist das Buch dann zu empfehlen. Derzeit bin ich unsicher, ob das Buch dem Publikum wirklich den erhofften Mehrwert bringt.

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)

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Sebastian Kübeck on :

Als Autor des Buches Web-Sicherheit möchte ich feststellen, dass ich für jede Art von Feedback zu meinem Buch dankbar bin. Fairerweise muss ich allerdings hinzufügen, dass sich Ihre Meinung über das Buch nicht mit der überwiegenden Anzahl von zufriedenen Lesern und Rezensenten deckt.Das Feedback, dass ich bisher erhalten habe war erfreulicherweise äußerst positiv, was meine jahrelange Recherchearbeit und die Erstellung der Beispielapplikation rechtfertigt.

Ich kann zwar nicht auf alle Kritikpunkte eingehen möchte jedoch zu einigen Stellung nehmen:

- Die grundlegende Kenntnis der Funktionsweise des Internets darf im Jahr 2011 bei Web-Programmierern und anderen halbwegs technisch versierten Lesern glaube ich vorausgesetzt werden. Im übrigen gibt es zu diesem Thema zahlreiche gute Bücher, die besser geeignet sind, dem Leser die Grundlagen des Internets beizubringen als ein Buch, dass dem Thema Websicherheit gewidmet ist.

- Zum Quellcode: Die überwiegende Anzahl an Schwachstellen befindet sich bei Webanwendungen nun einmal im Quellcode. Ich kann mir beim besten willen nicht vorstellen, wie jemand Webanwendungen absichern will, der Quellcode nicht lesen kann oder will.
Hätte ich den Quellcode nicht abgedruckt sondern nur auf Online-Referenzen verwiesen würden mir das alle Leser übel nehmen, die kein Tablet oder Notebook in der Nähe haben, wenn sie Bücher lesen.

- Zum Bundesinnenministerium. Im Buch steht:
“Wenn ein System Ihrer Organisation kompromittiert und in irgendeine illegale Aktivität verwickelt wird, werden die Behörden, beispielsweise das Bundesinnenministerium, mit Ihnen Kontakt aufnehmen und sich versichern, dass das betroffene System von Ihnen betrieben wird.”
Das Bundesinnenministerium steht hier ausdrücklich als Beispiel (und ich beziehe mich hier auf eine reale Begebenheit). Ich glaube nicht, dass sich ein Leser nach dem Lesen des zitierten Absatzes falsch informiert fühlt, wenn er vom LKA oder von einer anderen Behörde als dem Bundesinnenministerium über einen Sicherheitsvorfall informiert wird.

- Zur Auswahl der Programmiersprache Java: Java ist nun einmal die Programmiersprache, mit der der überwiegende Teil der Programmierer weltweit vertraut ist, wie sich aus zahlreichen Online-Statistiken ermitteln lässt. Die Quellcodebeispiel sind im Vergleich zu tatsächlichen Webanwendungen so einfach, dass sie auch von Programmierern verstanden werden sollten, die überwiegend in PHP, C#, VB.NET, Python, Ruby etc. programmieren.

Wie bereits erwähnt danke ich Ihnen für die ausführliche Rezension. Sollte es eine zweite Auflage geben werde ich die gefundenen Rechtschreibfehler korrigieren und mich bemühen, die eine oder andere Passage noch verständlicher zu formulieren.

Jens Kubieziel on :

Vielen Dank für den Kommentar. Hier noch einige Worte zur Klärung.

Die erwähnte Erklärung zu den technischen Grundlagen kann durchaus kurz ausfallen und mit einem Verweis auf ein gutes Buch abgerundet werden. Aus meiner Sicht wäre das ein guter Start in das Kapitel. Diejenigen, die sich damit auskennen, überspringen halt die Seiten.

Beim Quellcode wäre es mir nur wichtig, wenn die jeweils relevanten Stellen im Buch abgedruckt sind. Codewüsten über mehrere Seiten finde ich insgesamt zum Verständnis eher hinderlich. Wenn der leser mehr Kontext will, kann er in die mitgelieferte Anwendung schauen. Dazu braucht er nicht einmal eine Internetverbindung, wobei im Jahre 2011 …

Bzgl. der Sprachen finde ich Python optimal. Ich habe diverse Kurse zu Sprachen gehalten und aus der Erfahrung heraus, halte ich Java für keine gute Lehrsprache. Aber letztlich muss man halt das wählen, was einem am besten liegt.

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
BBCode format allowed
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.
Form options
cronjob