Wie schon bei scill.de berichtet, hat Alexios Fakos sein erstes Buch „Sichere Webanwendung” veröffentlicht.
Da mein Blog aufgrund privater und beruflicher Änderungen etwas brach lag, möchte ich mit einem lesenswerten Beitrag scill.de wieder aufleben lassen.
Ich sitze hier mit Alexios bei seinem Lieblingsgriechen im Norden Frankfurts und esse viel Fleisch mit noch mehr Pommes.
Scill.de: Hallo Alexios, das Ambiente ist sehr beeindruckend. Kommst Du deswegen her?
Alexios: Hallo Juergen, eher wegen des guten Essens… Sieht man mir doch an;-)
Scill.de: Ok. Du hast vor kurzem Dein erstes Buch veröffentlicht. Aus dem Titel lässt sich ableiten, dass es um Sicherheit in Webanwendungen geht. Warum soll ich das lesen?
Alexios: Genau, es geht rund um das Thema Webanwendungen oder Webapplikationen und deren Sicherheit. Wenn Du Dir ein solides Grundlagenwissen diesbezüglich aneignen willst, dann ist das ein Buch für Dich. Es ist praxisbezogen, wobei die Theorie nicht zu kurz kommt. Es werden die wesentlichen Schwachstellen und -arten vorgestellt, wie z.B. SQL Injection oder Cross-Site Scripting; was solche Schwachstellen anrichten können und wie man diese findet ist ein weiterer Bestandteil des Buches Sichere Webanwendungen . Ferner werden dann die Gegenmaßnahmen diskutiert, theoretisch und praktisch, beispielsweise in Form von Quellcode. Darüber hinaus werden auch einige Fallstricke vorgestellt, die man ebenfalls beachten sollte.
Wer jedoch ein Buch sucht, wo alle Schwachstellen bei Webanwendungen peux en peux untersucht und vorstellt werden, der sollte das Geld anderweitig investieren. Es werden nur die drei häufigsten Schwachstellen ausführlich vorgestellt und zwar jene, die im letzten Jahr bei der National Vulnerability Database aufgezeichnet worden sind.
Scill.de: Ich habe jahrelange Programmiererfahrung in PHP und blogge schon eine Weile. Als Blog-Software setze ich Wordpress 2.2 ein. Über FTP schiebe ich die meine ganzen Plugins hoch achte darauf stets die aktuellste Version von Wordpress hoch zuspielen. Ich pflege also meine Blog nicht nur inhaltlich sondern auch technisch. Auf was sollte ich den achten? Was kann ich alles falsch machen? Was kann denn passieren? Und was mache ich wenn was passiert. Polizei und Provider anrufen?
Alexios: Das zeitnahe Einspielen von Updates ist wichtig, auch wenn bei einer der letzten Wordpress Version ein Backdoor eingespielt worden ist. Hier nachzulesen.
Sofern es möglich ist, sollte man die Konfigurationseinstellungen des Webservers und von dem PHP-Interpreter „härten“, was Du bisher noch nicht gemacht hast;-) Beispielsweise solltest Du die PHP-Direktive display_errors auf Off setzen…
Auch wenn es die Entwickler nicht so gerne sehen, ich würde jeden Hinweis der auf deren Software hindeutet entfernen. Wordpress zum Beispiel, generiert einen Meta-Tag mit der Bezeichnung “generator”, in der die eingesetzte Wordpress Version sichtbar ist. Traut man dieser Information, weiß ein Dritter ob Du tatsächlich regelmäßig Updates einspielst;) Ansonsten gilt es noch weitere Tricks, um eine Wordpress-Installation festzustellen. Das gleiche gilt auch für die eingesetzten Plugins. Denn die Pfade dieser Anwendung sind fest vorgegeben, wie z.B. /wp-content/plugins bzw. /wp-content. Es gibt ein spezielles Wordpress „Härtungsskipt“ das dies verhindern soll. Der „security by obscurity“-Ansatz ist aber nicht immer empfehlenswert. Solche Dinge werden in dem Buch ebenfalls diskutiert.
Wenn man was „passiert“ …. In gewisser Weise hängt die Vorgehensweise ein wenig davon ab, welches Hosting-Paket Du nutzt. Den Hoster sollte man immer informieren. Der hilft Dir dann hoffentlich weiter, beispielsweise bei der Beweissicherung.
Scill.de: Suhosin und mod_security sind Möglichkeiten seine Web-Applikation noch sicher zu machen. Was machen den diese Module?
Alexios: Suhosin führt Änderungen direkt an dem PHP Quelltext durch, um den PHP-Interpreter zu härten. Des Weiteren stellt Suhosin weitere Erweiterungen zur Verfügung, wie ein Protokollwesen oder mehrere Filterfunktionen.
mod_security ist hingegen eine Web Application Firewall. Ein definiertes Regelwerk überprüft die eingehenden HTTP-Anfragen und leitet diese ggf. an die Webanwendung weiter. Andernfalls werden die HTTP-Anfragen verworfen und dieses Ereignis wird entsprechend protokolliert.
Scill.de: Hast Du irgendwelche statistische Zahlen, die die Unsicherheit im Web wieder geben?
Alexios: Aus der letzten Bedrohungsanalyse von Symantec geht hervor, dass im ersten Halbjahr 2006 insgesamt 69 Prozent der veröffentlichten Schwachstellen Webanwendungen zuzuordnen waren. Eine prozentuale Zuordnung der Schwachstellen ist in dem Statistikprojekt des Web Application Security Consortiums (WASC) zu finden.
Ferner möchte ich darauf hinweisen, dass die Verbreitung von Malware über Webanwendungen in den letzten zwei Jahren massiv zugenommen hat. Das prominenteste Beispiel war im Februar diesen Jahres: der Dolphins Stadium Angriff.
WASC dokumentiert weitere Vorfälle, in der sog. Web Hacking Incidents Database.
Scill.de: Warum gilt den der Einsatz von AJAX als unsicher? Ich setzte die AJAX-Lib prototype.js und die Yahoo-Lib ein sowie Lightbox für Image-Angebereien. Ist das unklug?
Alexios: Webanwendungen sind auch „unsicher“, so ist es nicht;) Im Ernst, mit AJAX kann man genauso viel falsch machen, wie bei der Entwicklung einer Webanwendung. Die Schwachstellen sind die gleichen sowie die einzelnen Problemfelder. Ok, der einzige Unterschied ist die Programmiersprache JavaScript. Dennoch, am Ende des Tages sollte man sich lediglich an zwei Grundregeln halten:
1. Jeder Input ist verdorben, daher überprüfe und verarbeite ihn entsprechend.
2. Jeder Output kann unter Umständen ausgeführt werden, daher kodiere ihn entsprechend.
Aber das ist meistens leichter gesagt als getan.
Der erste dokumentierte Webwurm JS.Spacehero worm verwendete den XHR, um sich als Samy bei den MySpace Benutzern als Freund hinzuzufügen.
Letztes Jahr war Google Mail ebenfalls in den Schlagzeilen, als ein Dritter die Möglichkeit hatte, die komplette Kontaktliste eines Google Mail Benutzers auszulesen.
Letztendlich handelt es sich bei beiden Angriffen, um einen Cross-Site Request Forgery. AJAX / XHR ist daher ein nützliches Hilfsmittel um Privilegien zu eskalieren.
Das schlimme dabei ist, dass der betroffene Benutzer nichts von dem Angriff mitbekommt. Der Angriff läuft förmlich im Hintergrund ab. Und wie Du weißt, kann man XHR im asynchronen Modus verwenden …
Scill.de: Genug über scill.de und Blog. Viel kritischer ist die Einstellung zu Sicherheit von Betreiber von Online-Plattformen. Zum Beispiel zu meinen Zeiten bei Jobs.de haben wir die Anhänge der
Bewerber außerhalb von document root abgelegt, passwortgeschützt gezippt und nicht mit dem ursprünglichen Namen abgelegt. Jetzt sind 7 Jahren vergangen und da erwarte ich von kommerzielle Stellenbörsen oder Stellenbörsen von Unternehmensseiten einen noch höheres Sicherheitsniveau. Ist das so? Sind Bewerberdaten sicher? Oder macht es kein Sinn darüber nachzudenken, weil die Bewerber ihre Daten sowieso gerne preisgeben möchten?
Alexios:
Bzgl. des Sicherheitsniveaus muss Du die betroffenen Stellenbörsenbetreibern oder Unternehmen befragen… In dem E-Recruitment-Umfeld gibt es relativ viele kleine Unternehmen. Ich denke da z.B. an spezialisierte Stellenmärkte, die bestimmte Branchen oder Berufsgruppen als Zielgruppe haben.
Aus Erfahrung weiß ich, dass der Funktionsumfang einer Webanwendung in der Regel viel wichtiger ist als deren Sicherheit. Letztendlich differenziert man sich gegenüber seinen Konkurrenten mit „außergewöhnlichen Features“, die Anzahl der ausgeschriebenen Stellen und evtl. der Popularität der Stellenbörse. Nur mit diesen und anderen kritischen Erfolgsfaktoren verdient man am Ende des Tages sein Geld. Mit Sicherheit nicht; im Gegenteil. Man muss in der Regel viel Zeit und Geld investieren. Sei es durch Mitarbeiterschulungen, Security Audits oder weiteren Maßnahmen. Das entsprechende Budget fehlt allerdings. Wenn es jedoch zu dem Gau kommt, dann ist das Geschrei groß, aber auch zu spät. Das zu tragende Risiko bzw. die Eintrittswahrscheinlichkeit eines Vorfalls kennen letztendlich nur die Betreiber/Unternehmen, falls sie diese Kennzahl kennen.
Nun, sind die Bewerberdaten sicher? Nichts ist sicher, Herr Schiller;) Ich möchte das anhand des Dolphins Stadium Angriffs belegen.
Durch eine SQL Injection auf der Stellenbörse konnten Unbekannte den title-Tag manipulieren und so Ihre Malware platzieren. (die Analyse des Einbruchs ist hier nachzulesen)
Betroffen waren auch weitere Webseiten. Wenn Du nach der Malware suchst, z.B. nach cn/[1-9].js bei Google wirst Du feststellen, dass immer noch einige Seiten das Malware-Skript enthalten.
Zurück zur Ausgangsfrage. Wenn man in der Lage ist Inhalte zu verändern, dann kann man in der Regel auch die Inhalte auslesen und so personenbezogene Daten stehlen und ggf. später auf den virtuellen Schwarzmarkt verkaufen.
Die Webanwendung als Vehikel für seine Malware zu verwenden ist nicht zu unterschätzen, zumal die Dophin Stadium vor dem SuperBowl Endspiel bis zu 1.000.000 Page Impression pro Monat hatte…
Erst einen Monat später wurde der Einbruch festgestellt. Und wer weiß ob nicht einer der infizierten Rechner bei der jüngsten DDoS-Attacke auf Estland unbewusst beteiligt gewesen war.
Scill.de: Vielen Dank, Alexios, für das aufschlussreiche Gespräch.
RSS