Webapplikationen bergen neue Risiken

Sicherheitslücken in Webapplikationen – automatische Scanner reichen nicht. Sicherheitslücken in Webapplikationen können nicht zuverlässig mit automatisierten Werkzeugen gefunden werden, so dass es weiterhin unverzichtbar ist, derartige Anwendungen von Menschen testen zu lassen. Das ist das Fazit einer Untersuchung, die Markus Schumacher auf der Konferenz Datenschutz und Datensicherheit in Berlin vorgestellt hat. Rupert Vogel, Honorarprofessor für Informationstechnologierecht an der Universität Mannheim, stellte vor, wie das Recht helfen kann, die Sicherheit von Software zu verbessern.

14. März 2007 um 09:51 Uhr / Jens Ihlenfeld

"Ohne über Prozesse nachzudenken, haben sie keine Chance, Webapplikationen sicher zu machen", so das Fazit von Schuhmacher, Geschäftsführer der Virtual Forge GmbH aus Mannheim. Immer mehr Unternehmensprozesse werden mit webbasierten Anwendungen kontrolliert, so Schumacher. Doch Unternehmen wiegen sich in falscher Sicherheit, wenn sie glauben, dass Firewalls oder Verschlüsselungstechnologien helfen, darin enthaltene Fehler aufzuspüren oder zu beseitigen. Denn viele Fehler entstünden auf logischer Ebene in der Architektur der Anwendungen, im Design oder Umsetzung.

Automatisierte Testwerkzeuge helfen nur begrenzt, so das Ergebnis des Tests mit sieben Sicherheits-Scannern, die im August 2006 auf dem aktuellen Stand der Technik waren. Diese Scanner wurden auf eine mit 85 Sicherheitslücken präparierte Webapplikation angesetzt, die auf einem so genannten "gehärteten" Webserver liefen, so dass die Tester davon ausgehen, dass sie keine Fehler des Webservers anzeigen. Dann wurde für jede Lücke protokolliert, ob der Angriffscode, den der Scanner sendet, die Lücke erfolgreich ausnutzt oder nicht.

Das Ergebnis war ernüchternd. Zwar können Scanner schnell arbeiten und auch automatisiert außerhalb der Bürozeiten eingesetzt werden, was sehr hilfreich sein kann, wenn oft umfangreiche Tests geachtet werden müssen. Viele der einfachen Testfälle seien von den Scannern gut erkannt worden. Außerdem eignen sie sich gut, um zu überprüfen, ob die von den Scannern in einem ersten Schritt gefundenen Fehler ausgebessert worden sind. Sehr schlechte Ergebnisse zeigten manche Scanner dann aber schon dabei, überhaupt Seiten zu finden, die getestet werden müssen. Das erreichen sie durch Spidering, also indem sie Links auf den Seiten zu anderen Seiten folgen. Einer der Scanner konnte keinen einzigen der Spidering-Fälle lösen. Auch die übrigen Scanner konnten maximal die Hälfte der Fälle aufdecken. Insgesamt lag die Erkennungsrate korrekt identifizierter Schwachstellen im Test im Schnitt bei 8 von 85 Fehlern, der beste Scanner fand 14, der schlechteste 4 Fehler.

Noch schwieriger wird es bei so genannten logischen Fehlern; die können von Scannern gar nicht erkannt werden. Beispiel: Vertrauliche Daten eines Nutzers werden per Identifier abgerufen, kommt kein Scanner auf die Idee, diesen Identifier zu verändern und zu prüfen, ob dadurch die Daten eines anderen Nutzers angezeigt werden. Entsprechend hat kein Scanner im Test eine solche Schwachstelle gefunden. Fazit der Tester: "Für komplexe Geschäftsanwendungen (wie z.B. Applikationen, die aus SAP Netweaver oder IBM WebSphere aufsetzen) sind Scanner daher aus unserer Sicht nicht geeignet."

Scanner eignen sich daher gut, um die so genannten "Low Hanging Fruits" zu identifizieren und zu überprüfen, ob entsprechende Lücken geschlossen wurden. Der Aufwand dafür ist aber sehr hoch, da nur sehr gut konfigurierte Scanner brauchbare Ergebnisse liefern. Denn auch die Berichtfunktion mancher Scanner ist wenig hilfreich: Zwei der Scanner im Test dokumentierten die wenigen Schwachstellen, die sie gefunden hatten, auf 946 und 742 Seiten. Die müssen erst einmal durchgearbeitet werden.

Die Schlussfolgerung von Schumacher und seinem Kollegen Andreas Wiegenstein: "Um ein wirklich hohes Sicherheitsniveau zu erreichen, ist die Kreativität und das Know-how eines menschlichen Sicherheitstests unverzichtbar – nur so können logische Schwachstellen gefunden und die generellen Defizite eines Scanners ausgeglichen werden."

Was aber kann man tun, um sich gegenüber Risiken abzusichern, wenn man Software entwickeln lässt? Rupert Vogel von der Kanzlei Bartsch und Partner und Honorarprofessor für Informationstechnologierecht an der Universität Mannheim, rät zu einer möglichst genauen Leistungsbeschreibung. Das mag trivial klingen, ist in der Praxis aber alles andere als einfach zu erfüllen. Häufig sind Softwareprojekte so komplex, dass eine konkrete Beschreibung nicht von vornherein möglich ist. Darum sollte auf abstrakte Regeln verwiesen werden, etwa dass die Software dem "Stand der Technik" entsprechen sollte, der definiert ist als die Summe des gesicherten technischen Wissens, das den Fachleuten aktuell zur Verfügung steht, oder auf technische Normen von Standardisierungsgremien, etwa des DIN oder der ISO.

Bereits hier müsse man die Begriffe genau kennen, so Vogel. Der "Stand der Wissenschaft und Technik" etwa geht in den Anforderungen über den Stand der Technik hinaus, so dass in Vertragsverhandlungen der Käufer den Stand von Wissenschaft und Technik als Maßstab für das abgelieferte Produkt festlegen sollte, das Softwarehaus aber gemeinhin lediglich den Stand der Technik vereinbaren wolle.

Wenn Standardsoftware gekauft wird, hat der Käufer in der Regel ohnehin nicht viel Spielraum bei Vertragsverhandlungen. Wenn es aber um Softwareprojekte geht, könnten und sollten Organisationsregeln beachtet und vertraglich vereinbart werden, wie Zeitplan und Meilensteine, Teilprojekte, die im Projektteam zuständigen Personen, Projektbesprechungen und -dokumentation, Abnahme und Klassifizierung und Meldungen von Fehlern.

Ist das Kind dennoch in den Brunnen gefallen und es kommt zum Streit zwischen Auftraggeber und Entwickler, rät Vogel dazu, ein Schlichtungsverfahren, etwa das der Deutschen Gesellschaft für Recht und Informatik, zu nutzen, statt sich auf ein langwieriges Gerichtsverfahren einzulassen. "In etwa 95 von 100 Fällen, in denen die streitenden Parteien die Schlichter anrufen, kommen sie am Ende zu einer Einigung", so Vogel.

Aber rechtliche Sanktionen könnten dazu dienen, Softwareentwickler zur Sorgfalt anzuhalten, wenn sie in den Vertragsverhandlungen dem Geschäftspartner deutlich vor Augen geführt würden. Nur sollte man das nicht so weit treiben, dass das Vertrauensverhältnis gestört werde, denn "trotz aller rechtlichen Absicherung ist Vertrauen neben Fachkompetenz das wichtigste Kapital auch in technischen Projekten." [von Matthias Spielkamp]