OWASP-Konferenz: Browsersicherheit und sichere Entwicklungsprozesse im Fokus

Das Open Web Application Security Project hat auf seiner europäischen Hauskonferenz – der OWASP AppSec EU Research – Trends zur Webapplikationssicherheit vorgestellt. Über 250 Besucher der Stockholmer Konferenz konnten sich an drei Tagen über die Kernthemen Browsersicherheit und sicherer Software Development Process informieren.

Googles Ian Fette und Chris Evans, Letzterer bekannt als Autor von vsftpd (Very Secure FTP Daemon), haben mit ihrer die Konferenz einleitenden Keynote "Zukunft der Browsersicherheit" aus dem Nähkästchen geplaudert, was Google versucht, in puncto Malware-Entdeckung und Browsersicherheit zu verbessern. Nach dem Versuch, mit Chromium OS ein Betriebssystem um ihren Browser zu bauen, überraschte der Ausspruch "the computer is the Web browser" zwar nicht. Aus Sicherheitssicht gerade im Hinblick einer nicht enden wollenden Folge von Exploits für alle Browser und vor allen Dingen Plug-ins (PDF, Flash und Java) bekomme das, so Evans, eine neue Bedeutung.

Pünktlich zur Keynote ist die Version 3.6.4 (mittlerweile liegt schon Version 3.6.6 vor) des Firefox Browsers erschienen, die erstmals Plug-ins in einen separaten Prozess auslagert und damit einen Stabilitätsgewinn verspricht. Safari wird mit Webkit2 eine ähnliche Verbesserung erfahren. Bei Firefox ist zukünftig geplant, nicht nur ein Update der Erweiterungen anzumahnen, sondern besonders der Plug-ins, um die risikobehaftete Zeitspanne für den unbedarften Benutzer zu minimieren. Googles Chrome wird bald PDF-Viewer in eine Sandbox verbannen. Für Java ist Ähnliches geplant, doch ist die Realisierung technisch schwierig, zum Beispiel wenn mit dem Java-Plug-in der Benutzer zum Herunterladen eines Exploits bewegt wird.

Malware-Sites werden von Google automatisch detektiert: Dafür vorgesehene virtuelle Maschinen "klicken" auf die Links, die bei Google Mail als Spam landen. Änderungen in der Registry oder im System32-Ordner von Windows lassen dann Schlussfolgerungen zu. Mit der deutsch getönten Datenschutzbrille sieht man selbst die maschinenbezogene Auswertung von Links in privaten E-Mails als heikel an, aber der Fall ist ähnlich gelagert wie die inhaltsbezogene Werbung bei Googles Mail-Technik.

Google erstellt so jedenfalls eine Blacklist von Websites und warnt in den Suchergebnissen zumindest davor. Aus technischer Sicht wäre es laut Fette schön, die Liste auch den Benutzer-PCs zur Verfügung zu stellen, denn nur wenige kommen über die Suchmaschine auf die Links, dafür aber über Phishing-E-Mails. Das würde jedoch bedeuten, über 500.000 URLs alle 30 Minuten auf Abermillionen von PCs zu verteilen.

Selbst die Erfolgsrate davon wäre geringer, als man glauben mag: Laut Fette würden bei Chrome, der mit deutlich rotem Hintergrund vor Phishing-Links warnt, mehr als die Hälfte auf "Weiter" klicken.

Mit Sicherheit entwickeln

Das zweite große Thema der Veranstaltung galt einem sicheren Softwareentwicklungsprozess für Webapplikationen. Nach dem OWASP-Vorsitzenden Jeff Williams im begleitenden Konferenzmaterial hat der Softwareentwicklungsprozess versagt, wenn ein Audit in der fertiggestellten Applikation Lücken findet.

Mit diesem Kernthema beschäftigte sich der Keynote-Vortrag von Steve Lipner, bei Microsoft verantwortlich für die Sicherheitsstrategie. Er skizzierte Microsofts Weg zum Security Development Lifecycle (SDL), dessen Anfänge zurückreichen in die Post-Nimda- und -Code-Red-Zeit, als Bill Gates im Januar 2002 ein Memo über "Trustworthy Computing" verfasst hatte. Seine Firma fing daraufhin an, in der finalen Entwicklungsphase von Windows Server 2003 Prozesse und Kontrollmechanismen zu etablieren. Ein Vorhaben, das sich über Jahre hinzog, aber 2004 zur ersten Veröffentlichung führte. Neu ist seit letztem Jahr "SDL for Agile", der agile Entwicklungsmethoden in einen sicheren Software-Lebenszyklus integrieren soll. Microsoft hat hierfür eine Prozess-Schablone für Visual Studio herausgegeben.

Dass agile Softwareentwicklung und Sicherheit nicht auf einfache Weise miteinander zu vereinbaren sind, zeigte Nick Coblentz von AT&T. Das läge an den kurzen iterativen Entwicklungszyklen (maximal vier Wochen bei Scrum), die zwar funktional schneller Ergebnisse liefern, aber eben nicht unbedingt eine langfristige Planung unterstützen, was sich als kontraproduktiv für die Softwaresicherheit erweise. Seiner Erfahrung nach müssen die Entwickler unbedingt Wissen um sichere Entwicklung mitbringen. Auch verweist er auf Initiativen über die gesamte Projektlaufzeit hinweg im Microsoft-Standardwerk. Den Autor konnte er damit nicht überzeugen, zumal sicherheitsrelevante Kontrollen in den Zyklen zu fehlen scheinen, und Coblentz der Meinung war, dass man den Kunden in den Zyklen abwägen lassen sollte, was in einem Zyklus wichtig ist: Funktionen oder Sicherheit.

OWASP hat seit 2008 mit OpenSAMM ein eigenes Werk, das mit einem erprobten Reifemodell sichere Softwareentwicklung propagiert. Pravir Chandra von Fortify berichtete vor Ort als OpenSAMM-Initiator und -Kopf über Stolpersteine bei Umsetzungsprojekten. Das grundsätzliche Problem sei auch bei Softwaresicherheit das mangelnde Verkaufsargument: Man muss in Prozesse, Kontrollen, Schulung von Mitarbeitern, Audits und mehr investieren, ohne dass ein zählbarer Gewinn dabei herausspringt.

BSIMM2 ist ein konkurrierender Standard zu OpenSAMM, der durch Befragung von 30 großen Softwareschmieden entstanden ist. Überraschenderweise sind nach Pravir nur drei von ungefähr 200 Aktionen in BSIMM2 anders als OpenSAMM. Offen blieb leider die Frage, inwieweit abgespeckte Versionen durch kleinere Softwareschmieden zu nutzen wären. Mit einem Reifemodell müsste das einfacher sein.

Die nächste OWASP AppSec EU findet 2011 im Trinity College in Dublin (Irland) statt.

Dr. Dirk Wetter
ist Berater und Sicherheitsauditor im Webapplikationsumfeld. (ane)