Siebzig bis achtzig Prozent der Webshops, E-Business-Portale oder Homepages von Unternehmen sind löchrig, schätzen Experten. Mit einer lose organisierten Sicherheitsfortbildung für die Entwickler ist das Problem jedoch keineswegs gelöst. Das Thema gehört von Beginn an in die Projektplanung.
Webanwendungen sind meist löchrig wie ein Schweizer Käse. Relativ bekannte und simple Attacken wie Cross-Site-Scripting[1] oder SQL-Injection[2] bringen so manchen Shop oder manches Portal in Bedrängnis. Kein Wunder also, dass sich bei rund 80 Prozent der getesteten Internetseiten binnen 30 Minuten mindestens ein Schlupfloch finden lässt.
Die wachsende Anzahl an Cracking-Tools mit automatisierten Angriffsmöglichkeiten bietet sogar für unerfahrene Script-Kiddies die Möglichkeit, kleine Schwächen in Webanwendungen auszunutzen.
Als gängige Angriffsmuster gelten etwa URL-Manipulationen, Command- beziehungsweise SQL-Injection sowie Cross-Site-Scripting. Herkömmliche Firewall-Technologien bieten gegen die Datenausspähung und -manipulation, Identitätsdiebstahl oder Denial-of-Service-Attacken keinen ausreichenden Schutz. Problematisch ist vor allem, dass es reicht, wenn der Brand an einer einzigen Schwachstelle ausbricht.
Ungültige Eingaben gelten als eine der größten Schwachstellen. Trotzdem bauen die meisten Firmen zunächst eine Anwendung und fragen oft erst hinterher nach der Sicherheit. Entwickler sollten beim Programmieren zwar auf korrekte Ein- und Ausgabeprüfung achten sowie die Zugriffsberechtigungen spezifizieren oder einschränken, doch lassen sich hochgesteckte Vorgaben in der Praxis selten durchgängig realisieren. Regelmäßige Prüfung der Programmiertechnik sowie Designchecks sind bisher nur selten Usus.
Auch mangelt es an bedarfsgerechten, vom Hersteller unabhängigen sowie umfassenden Security-Schulungen zum Thema Web-Applikationssicherheit, die zudem Theorie und Praxis sinnvoll verzahnen. Nur wenige Anbieter wenden sich bisher mit gezielten Angeboten an die Entwickler. Das Terrain gilt als ausgesprochen sensibel. Oft führen kurzfristig beauftragte Teams aufgrund kritischer Vorgänge quasi "posthum" und ad hoc Penetrationstests auf Webapplikationen im Beisein des Kunden durch, die in der Regel das eine oder andere "Aha-Erlebnis" für die Verantwortlichen nach sich ziehen.Im Dschungel der Weiterbildungen zur Web-Application-Security ist zudem der Grat zwischen hoch spezialisiertem Expertentum und unnützem Halbwissen schmal. Deshalb raten Experten, das Thema von der grundsätzlichen Seite anzugehen: Wichtig ist, dass die Entwickler die Basistechnologien richtig begreifen, etwa die Funktionsweise relationaler Oracle-Datenbanken.
 |
| Weil Webanwendungen für jeden Internetnutzer erreichbar sind, gibt es eine große Menge an potentiellen Angreifern. |
|
Ein geschickter Eindringling schlüpft in die Rolle des Programmierers und nutzt nicht erwartete Eingaben zur Manipulation von Daten oder zum Einschleusen von gefährlichem Code. Beispielsweise wird in das Eingabefeld einer Maske ein Javascript eingegeben, das dann oft tatsächlich ausgeführt wird und so eine Hintertür in die Applikation öffnet. Diese Anwendungen stellen häufig aber nicht nur die jeweilige Webpräsenz des Unternehmens dar, sondern sind untrennbar mit Backend- und Datenbanksystemen verbunden.Die Suche nach Schwachstellen webbasierter Applikationen beginnt schon mit der banalen Tatsache, dass diese Programme für alle Nutzer jederzeit erreichbar sind. Daher gibt es eine große Menge an potentiellen Angreifern, die nicht durch Firewalls aufgehalten werden können. Die Applikationen sollen ja erreichbar sein. Aus demselben Grund hilft auch keine End-zu-End Verschlüsselung, etwa SSL-basiert. Die Daten werden zwar verschlüsselt über das Netzwerk gesendet, aber das spielt für die Webanwendung, die diese Daten verarbeitet, keine Rolle.
|
| Der Grat zwischen hochspezialisiertem Expertentum und unnützem Halbwissen ist schmal. |
|
Auch die "innere Sicherheit" ist ein permanenter Unruheherd. Webanwendungen und Webserver werden oftmals als Eingangstür in das interne Netzwerk missbraucht. Eine Firewall blockiert typischerweise Verbindungen von außen zu den meisten Rechnern im internen Netzwerk. Wenn der Angreifer jedoch Kontrolle über den Rechner erlangen kann, wo die Webanwendungen laufen, kann er diesen Rechner dazu verwenden, weitere Maschinen im internen Netz anzugreifen, die dadurch nicht mehr durch die Firewall geschützt sind, da der Webserver hinter der Firewall liegt.Per Rundumschlag lässt sich also die komplexe Routine kaum bewältigen. Das Wichtigste ist es, zu erkennen, dass keine einzelne Maßnahme ausreicht, die Sicherheit zu garantieren. Das heißt, es gibt keine "Silver Bullet". Experten empfehlen, eine Verteidigungslösung aufzubauen, die aus mehreren Schichten besteht. Das schließt die Ausbildung der Mitarbeiter genauso ein wie das Absichern der Maschine, auf der die Webapplikationen laufen.
|
| Entwicklern fehlt oft die notwendige Erfahrung, wie ein Angreifer zu denken und zu handeln. |
|
Daneben gilt es, den richtigen Hebel zwischen Technik, Mensch und Organisation zu finden. Im Fokus steht insbesondere die Zunft der Programmierer. Sie müssen schließlich Anwendungen entwickeln, die möglichst wenige Fehler haben. Dazu kann ein Unternehmen sowohl technisch als auch organisatorisch beitragen. Auf der einen Seite können spezielle Entwicklungswerkzeuge bereitgestellt, auf der anderen Seite die Mitarbeiter mit zusätzlichen Schulungen ausgebildet werden. Ganz wichtig ist es aber auch, ein Klima zu schaffen, in dem Mitarbeiter nicht nur für die "Funktionalität" belohnt werden, sondern auch der sichere Code einen Teil der Lohn- und Leistungsvereinbarung darstellt.
Im Idealfall trägt das Unternehmen für eine gute Ausbildung der Programmierer Sorge. Hier sind auch die Universitäten gefordert, die bisher noch immer zu wenig Gewicht auf das Erstellen korrekter und getesteter Programme legen, und meist auch kaum Security-Inhalte in die Lehrpläne integriert haben. Zusätzliche Workshops versuchen, die Sensibilität der Mitarbeiter für klassische Sicherheitsprobleme und Programmierfehler generell zu schärfen.Schließlich gilt es, passende Produktanbieter auszuwählen. Dazu muss der Hintergrund des Anbieters ausgelotet werden. Handelt es sich um ein unbekanntes Unternehmen, sind die Spezialisten bereits seit längerem auf dem Gebiet aktiv, verfügen sie über Zertifikate? Es gibt nicht wenige Anbieter, welche die Angst der Kunden ausnutzen und nur ein trügerisches Sicherheitsniveau verkaufen. Einen wichtigen Beitrag bei technischen Lösungen könnten künftig Web-Applikations-Firewalls spielen, weil es noch viel zu viele schwache Applikationen im Netz gibt. Firewalls für Anwendungen werden bisher nur zögerlich von Unternehmen eingesetzt.
Es muss nicht unbedingt ein schlechtes Zeichen sein, wenn eine Firma ehemalige "Hacker" zur Expertise heranzieht, sofern deren Motivation durch Neugier und nicht durch kriminelle Motive gespeist wird. Grundsätzlich verfügen Hacker neben dem Know-how oft über die richtige Einstellung und den richtigen Blickwinkel, um durch eine unkonventionelle Herangehensweise auch verborgene Probleme und Schwachstellen aufzuspüren. Bei Beratern und Consultants ist darauf zu achten, dass das ausführende Team über Erfahrung und Fachwissen verfügt.
Daneben sollten natürlich auch Tools zum Einsatz kommen, die helfen können, Programmierfehler zu finden. Dies kann durch automatische Analyse von Source Code erfolgen - oder durch das Testen der Programm-Interfaces mit inkorrektem Input. Des Weiteren ist es sinnvoll, den Rechner mit dem Webserver und den Webapplikationen vom internen Netzwerk zu trennen, in einer "demilitarisierten Zone".
Außerdem sollten die Applikationen nur mit jenen Privilegien laufen, die sie tatsächlich für die Aufgabe benötigen. Abschließend gilt es, den Wissensstand der Mitarbeiter permanent zu verbessern und die Anwendungen global zu sichern. Das Internet ist rund um die Uhr aktiv. Deshalb sollte man bedenken, dass viele Mitarbeiter im Bereich der Web-Software-Entwicklung immer noch wenig Erfahrung mit aktuellen Bedrohungsbildern haben.1. Keinen Eingabedaten vertrauen: Alle Webeingaben müssen serverseitig überprüft werden, etwa Typ, Länge und Format. Gefährliche Daten werden zurückgewiesen, ignoriert, gelöscht oder ersetzt.
2. Fehlermeldungen möglichst wenig aussagekräftig: Fehlermeldungen moderner Entwicklungsbibliotheken sind hilfreich in der Projektphase, aber auch für Angreifer eine beliebte Informationsquelle.
3. Den Fehlerfall einplanen: Komplexe Software enthält immer Fehler. Gute Fehlerbehandlung belässt die Anwendung in einem definierten Zustand und gestattet keine unvorhergesehenen Aktionen.
4. Sicherheitsrelevante Aktionen protokollieren, etwa Login, Zugriff auf sensible Daten, fehlgeschlagene Zugriffsversuche.
5. Zentralen Zugang zur Applikation schaffen, etwa über eine zentrale Authentifizierungsklasse. Alle anderen Eingänge schließen.
6. Sicherheitsrelevante Daten schützen und nicht auf Client-Seite speichern; wo unumgänglich, verschlüsselt und signiert.
7. Sichere Authentifizierung: Starke Passwörter fordern, Authentifizierung nur über SSL-Verbindungen, keine Übertragung und Speicherung von Passworten.
8. Minimale Privilegien: Alle nicht benötigten Admin-Konten entfernen, auf Ressourcen nur mit ausreichenden, aber nicht höheren Privilegien zugreifen. Vorsicht bei der Benutzerauthentifizierung.
9. Mehrere Verteidigungslinien einsetzen, nicht auf einen Schutzmechanismus verlassen.
10. Kryptoverfahren zur Verschlüsselung von Daten und Verbindungen nutzen: Keine eigenen Verschlüsselungsalgorithmen schreiben, immer die größtmögliche Schlüsselstärke nutzen, keine Schlüssel oder sonstigen Geheimnisse im Programmcode speichern.
Quelle: OWASP[5]/LL
Weitere Informationen:
Das Open Web Application Security Project[5] (OWASP) bietet zahlreiche Tipps und News zu sicheren Webapplikationen.
Bundesamt für Sicherheit in der Informationstechnik:
Sicherheit von Webanwendungen[6]: Maßnahmenkatalog und Best Practices (PDF)
Für Entwickler, mit zahlreichen praktischen Tipps, etwa zur Absicherung von "Sessions".
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/