Wenn ein Unternehmen eine Webanwendung bereitstellt (beispielsweise auf einem Tomcat-Webserver, der über JDBC mit einem SQL-Datenbankserver kommuniziert), lädt es alle dazu ein, HTTP/HTTPS-Anfragen zu senden. In diesen Anfragen verborgene Angriffe können herkömmliche Sicherheitsmaßnahmen wie Firewalls, Filter, Intrusion-Prevention-Systeme (IPS), Antivirensoftware usw. umgehen. Der Code jeder Webanwendung wird Teil des Sicherheitsperimeters. Daher erhöhen Anzahl, Größe und Komplexität von Webanwendungen die Angriffsfläche des Sicherheitsperimeters eines Unternehmens. Websites können Inhalte aus verschiedenen Quellen einbetten, wie z. B. Frames, Skripte, CSS, Objekte (Flash) usw. Der Begriff Web 2.0, der um 2004 aufkam, wird mit Webanwendungen in Verbindung gebracht, die interaktiven Informationsaustausch, Interoperabilität, nutzerzentriertes Design und Web-Kollaboration ermöglichen. Web-2.0-Websites werden zunehmend interaktiver und ermöglichen Nutzern eine größere Anzahl von Aktionen in immer kollaborativerer Weise. Mashups beispielsweise ermöglichen es Webnutzern, Dienste von Drittanbietern einfach in ihre Websites zu integrieren. Eines der Elemente von Web 2.0 ist die Programmiertechnik AJAX (Asynchronous JavaScript and XML). Google Maps nutzt AJAX beispielsweise in seinen Kartenanwendungen. AJAX trägt zwar zu attraktiveren Websites und Webseiten bei, bietet Angreifern aber auch neue Möglichkeiten, Webserver anzugreifen und immer mehr Websites auszunutzen. AJAX-basierte Websites bieten eine größere Angriffsfläche, da sie häufiger mit dem Browser interagieren und JavaScript clientseitig (PC, PDA, iPad, Mobiltelefon, iPhone/Android usw.) ausführen können. AJAX erhöht das Risiko von Cross-Site-Scripting (XSS), das auftritt, wenn Website-Entwickler die Seiten nicht korrekt codieren. Angreifer können diese Schwachstellen ausnutzen, um Benutzerkonten zu stehlen, Phishing-Angriffe durchzuführen und Schadcode auf die Computer der Benutzer herunterzuladen.
Aktuell steigt das Risiko von Anwendungsangriffen. Laut NIST befinden sich 95 % aller Sicherheitslücken in der Software. Gartner zufolge erfolgen 75 % der Angriffe auf Anwendungsebene. White Hat Security zufolge weisen sieben von zehn Websites schwerwiegende Sicherheitslücken auf. Forrester zufolge waren 62 % der Unternehmen in den letzten zwölf Monaten von einem Sicherheitsvorfall betroffen. Laut Cenzic, basierend auf Daten von NIST (mit dessen NVD, der NIST National Vulnerability Database), MITRE, SANS, US-CERT und OSVDB, ist ein steigender Trend bei Schwachstellen in Webanwendungen zu verzeichnen: 73 % im zweiten Quartal 2008, 80 % im dritten Quartal 2008 und 82 % im dritten und vierten Quartal 2009. IBM zufolge stieg die Anzahl der Schwachstellen in Webanwendungen von insgesamt 2.000 im Jahr 2004 auf rund 15.000 im Jahr 2008. Gartner zufolge konnten 2010 bereits 60 % der IT-Organisationen die Schwachstellenerkennung als integralen Bestandteil ihrer Softwareentwicklungsprozesse (SDLC) integrieren. Laut Tom Brennans „Website Security Statistics Report“ von 2010 verteilten sich die Anteile der Websites mit mindestens einer Sicherheitslücke wie folgt: ASP (74 %), ASPX (73 %), ColdFusion (86 %), Struts (77 %), JSP (80 %), PHP (80 %) und Perl (88 %). Ebenso verteilten sich die Anteile der Websites mit mindestens einer Sicherheitslücke wie folgt: ASP (57 %), ASPX (58 %), ColdFusion (54 %), Struts (56 %), JSP (59 %), PHP (63 %) und Perl (75 %).
Laut dem CISO von Texas im Februar 2010 waren die Angriffstrends für 2010 folgende: (i) Malware, Würmer und Trojaner. Verbreitung über E-Mail, Instant Messaging und infizierte oder schädliche Websites. (ii) Botnetze und Zombie-Bots. Diese verbessern ihre Verschlüsselungs- und Tarnfähigkeiten und sind daher schwerer zu erkennen. (iii) Scareware. Dabei handelt es sich um gefälschte kostenlose Sicherheitssoftware, die mit Malware infiziert ist. (iv) Clientseitige Softwareangriffe. Diese zielen auf Browser (Safari, Mozilla Firefox, Google Chrome, Opera, Netscape, Internet Explorer, Webkit usw.), Mediaplayer, PDF-Reader usw. ab. (v) Ransomware-Angriffe. Diese umfassen DDoS-Angriffe, Malware, die Lösegeld fordert und bei Verweigerung die Festplatte verschlüsselt und unbrauchbar macht. (vi) Angriffe über soziale Medien. Das Vertrauen der Nutzer in ihre Online-Freunde macht diese Netzwerke zu einem Hauptziel für Angreifer, sowohl privat als auch beruflich. (vii) Cloud Computing. Dessen zunehmende Nutzung macht es zu einem weiteren wichtigen Ziel für Angreifer. (viii) Webanwendungen. Es ist bekannt, dass sie mit unzureichenden Sicherheitsvorkehrungen entwickelt werden. (ix) Budgetkürzungen. Dies stellt ein großes Problem für Sicherheitspersonal dar und ist ein Segen für Cyberkriminelle.
Komponententypen und Webstruktur.
Die wichtigsten strukturellen Komponenten des Webs sind: (i) Clients/Browser. (ii) Server. Diese laufen auf leistungsstarker Hardware mit Mehrkernprozessoren. (iii) Caches. Diese ermöglichen interessante Implementierungen und reduzieren Wartezeiten. (iv) Das Internet. Dies ist die globale Netzwerkinfrastruktur, die den Datentransfer über den TCP/IP-Protokollstapel ermöglicht. Die wichtigsten semantischen Komponenten des Webs sind: (a) Das HTTP (Hypertext Transfer Protocol). HTTP ist ein einfaches, zustandsloses Anfrage-/Antwortprotokoll, das Daten nicht verschlüsselt. Es ist ein Anwendungsprotokoll im TCP/IP-Protokollstapel zwischen einem Browser und einem Server und bildet in Kombination mit SSL/TLS die Verbindung HTTPS. Einige HTTP-Anfragenachrichten sind: GET: Der Client fordert ein Dokument vom Server über eine URL an; PUT: Der Server sendet ein Dokument an den Client; HEAD: Der Client ruft Informationen über das durch die URL angegebene Dokument ab, nicht das Dokument selbst; OPTIONS: Der Client ruft Informationen über verfügbare Optionen ab; POST: Der Client sendet Informationen an den Server, z. B. Annotationen. DELETE löscht ein Dokument, das durch eine URL angegeben wird; TRACE gibt die eingehende Anfrage zurück; CONNECT wird von Caches verwendet. Die erste Art von HTTP-Nachricht ist die Anfrage. Der Client-Browser erstellt und sendet Nachrichten wie beispielsweise: Eine typische HTTP-Anfrage ist: GET http://www.labrs.com/index.html HTTP/1.0. Die zweite Art von Nachricht ist die Antwort. Webserver erstellen und senden Antwortnachrichten. Eine typische HTTP-Antwort ist: HTTP/1.0 301 Moved Permanently Location http://www.rs.com/lab/index.html. Der Webbrowser auf Clientseite kommuniziert mit einem oder mehreren Servern. Der Browser sendet eine Anfrage, und der Server antwortet mit einer Antwort. Um den Status zwischen Anfragen zu erhalten, generiert der Server ein Sitzungstoken. Diese Kennung wird mit jeder Anfrage/Antwort zwischen Browser und Server ausgetauscht. Ein Cookie ist ein Datenelement, das mit der Anfrage/Antwort übermittelt werden kann, beispielsweise als Tracking-Cookie, um die Präferenzen jedes Benutzers zu erfassen.
Die HTTP-Versionen sind: (i) HTTP 1.0 (RFC 1945). Es handelt sich um ein Stop-and-Wait-Protokoll. Für jede Datei wird eine separate TCP-Verbindung aufgebaut und wieder getrennt. Charakteristisch ist die ineffiziente Paketnutzung. Der Server muss während der Wartezeit viele Verbindungen aufrechterhalten. Clients senden Anfragen an Port 80 von Webservern und verwenden DNS, um den Servernamen in eine IP-Adresse aufzulösen. Clients bauen für jede URL eine separate TCP-Verbindung auf. Einige Browser öffnen mehrere TCP-Verbindungen (Netscape verwendet standardmäßig vier). Der Server liefert die HTML-Seite. Es gibt viele Servertypen mit unterschiedlichen Implementierungen. Der Apache-Server ist der am weitesten verbreitete und frei verfügbare. Der Browser interpretiert die Seite und fordert eingebettete Objekte an. (ii) HTTP 1.1 (RFC 2068). Es bietet eine verbesserte Leistung, verwendet persistente Verbindungen, Pipelining, Caching-Optionen und unterstützt Komprimierung. Persistente Verbindungen verwenden dieselbe TCP-Verbindung für die Übertragung mehrerer Dateien. Dies reduziert den Paketverkehr erheblich und kann die Leistung aus Client-Sicht verbessern, muss es aber nicht, wenn die Serverlast steigt. Pipelining bezeichnet das Bündeln möglichst vieler Daten in einem einzigen Paket. Es erfordert ein oder mehrere Längenfelder im HTTP-Header. Ob dadurch der Paketverkehr reduziert oder die Leistung gesteigert wird, ist ungewiss. In diesem Fall ist die Seitenstruktur entscheidend. (b) Sprachen wie HTML (Hypertext Markup Language) und XML (Extensible Markup Language). HTML ist eine Teilmenge von SGML (Standardized General Markup Language) und ermöglicht die Einbettung von Links zu anderen Dokumenten und Anwendungen. HTML-Dokumente verwenden Elemente, um Textabschnitte mit unterschiedlichen Zwecken zu kennzeichnen oder Formatierungen wie Fettdruck darzustellen. Markup-Elemente sind für den Benutzer beim Betrachten der Seite nicht sichtbar. Dokumente werden von Browsern dargestellt. Nicht alle Webdokumente sind HTML-Dokumente; Entwickler verwenden WYSIWYG-Editoren, um HTML zu generieren. (c) Namensmechanismen mit URIs (Uniform Resource Identifiers).
Webressourcen benötigen Namen/Kennungen, sogenannte URIs. Die Ressource kann sich an beliebiger Stelle im Internet befinden. URIs sind ein abstraktes Konzept: ein Verweis auf eine Ressource, auf den Anfragemethoden angewendet werden können, um potenziell unterschiedliche Antworten zu generieren. Die URI verweist auf generische Anwendungen (http, ftp, telnet usw.). Eine Anfragemethode ist beispielsweise das Suchen oder Ändern des Objekts. Das URL-Beispiel: http://www.abc.com/index.html enthält das Protokoll (http://, ftp://, telnet://, mailto://)
STRIDE/DREAD-Bedrohungsmodellierungssystem für Webanwendungen.
Das STRIDE/DREAD-Bedrohungsmodellierungssystem basiert auf: (1) STRIDE, das die folgenden Bedrohungskategorien identifiziert: (i) Identitätsdiebstahl. Identitätsdiebstahl stellt ein zentrales Risiko für Anwendungen mit vielen Benutzern dar, die jedoch einen einzigen Ausführungskontext auf Anwendungs- und Datenbankebene verwenden. Benutzer sollten nicht in der Lage sein, sich als andere Benutzer auszugeben oder deren Identität anzunehmen. (ii) Datenmanipulation. Benutzer können alle ihnen übermittelten Daten verändern und somit clientseitige Validierungen, GET- und POST-Daten, Cookies, HTTP-Header usw. manipulieren. Die Anwendung sollte keine Daten an den Benutzer senden, wie z. B. Zinssätze oder Laufzeiten, die innerhalb der Anwendung selbst abrufbar sind.
Die Anwendung muss alle vom Benutzer empfangenen Daten sorgfältig prüfen, um deren Richtigkeit und Anwendbarkeit festzustellen. (iii) Anfechtung. Benutzer können Transaktionen anfechten, wenn die Nachverfolgung und Protokollierung der Benutzeraktivitäten unzureichend ist. Wenn ein Benutzer beispielsweise angibt: „Ich überweise kein Geld auf dieses externe Konto“, und seine Aktivitäten nicht vom Beginn bis zum Ende der Anwendung nachvollziehbar sind, muss die Transaktion höchstwahrscheinlich rückgängig gemacht werden. Anwendungen sollten über angemessene Anfechtungsmechanismen verfügen, wie z. B. Webzugriffsprotokolle, Audit-Protokolle auf allen Ebenen und eine umfassende Benutzerkontextanalyse. Idealerweise sollte die Anwendung mit den Benutzerrechten ausgeführt werden, was jedoch bei vielen Frameworks nicht möglich ist. (iv) Offenlegung von Informationen. Benutzer zögern, private Daten an ein System weiterzugeben. Wenn ein Angreifer Benutzerdaten anonym oder als autorisierter Benutzer offenlegen kann, geht die Anfechtbarkeit verloren. Anwendungen müssen daher strenge Kontrollmechanismen enthalten, um die Manipulation der Benutzeridentität zu verhindern, insbesondere wenn die gesamte Anwendung über ein einziges Benutzerkonto ausgeführt wird. Auch der Browser des Benutzers kann Informationen preisgeben. Nicht alle Browser implementieren die von HTTP-Headern geforderten Richtlinien zur Vermeidung von Caching korrekt. Jede Anwendung ist verpflichtet, die vom Browser gespeicherte Datenmenge zu minimieren, um zu verhindern, dass Informationen durchgesickert und von Angreifern genutzt werden, um mehr über den Benutzer zu erfahren oder sich gar als dieser auszugeben. (v) Denial-of-Service-Angriffe (DoS). Anwendungen sollten sich bewusst sein, dass sie Ziel von DoS-Angriffen werden können. Bei authentifizierten Anwendungen sollten ressourcenintensive Anwendungen wie große Dateien, komplexe Berechnungen, umfangreiche Suchvorgänge oder lange Abfragen autorisierten Benutzern vorbehalten bleiben, nicht anonymen Benutzern. Anwendungen, die diese Möglichkeit nicht haben, sollten in jeder Hinsicht so implementiert werden, dass sie möglichst wenig Arbeit verrichten, schnelle Datenbankabfragen nutzen (oder darauf verzichten) und die Offenlegung großer Dateien oder die Bereitstellung individueller Links pro Benutzer vermeiden, um einfache DoS-Angriffe zu verhindern. (vi) Rechteausweitung. Wenn eine Anwendung Benutzer- und Administratorrollen bereitstellt, ist es unerlässlich sicherzustellen, dass sich Benutzer nicht selbst in höhere Rechtepositionen begeben können. Insbesondere das Fehlen von Benutzerlinks reicht nicht aus; Alle Aktionen müssen durch eine Autorisierungsmatrix kontrolliert werden, um sicherzustellen, dass nur die berechtigten Rollen Zugriff auf privilegierte Funktionen haben. (2) DREAD. Dieser Wert dient zur Berechnung des Risikowerts, der sich aus dem arithmetischen Mittel von fünf Elementen ergibt: Risiko (DREAD) = (Schaden + Reproduzierbarkeit + Ausnutzbarkeit + Betroffene Benutzer + Auffindbarkeit) / 5. Er setzt sich zusammen aus: (i) Schadenspotenzial. Dieses Maß gibt an, wie viel Schaden entsteht, wenn eine Bedrohung ausgeführt wird. Ein Wert von null bedeutet keinen Schaden, ein Wert von fünf bedeutet, dass die Daten eines einzelnen Benutzers betroffen oder kompromittiert wurden, und ein Wert von zehn bedeutet, dass die Daten des gesamten Systems betroffen sind. (ii) Reproduzierbarkeit. Dieses Maß gibt an, wie leicht diese Bedrohung reproduziert werden kann. Ein Wert von null bedeutet sehr schwierig oder unmöglich, selbst für Anwendungsadministratoren. Ein Wert von fünf bedeutet, dass für ein oder zwei Schritte möglicherweise ein autorisierter Benutzer erforderlich ist. Ein Wert von zehn bedeutet, dass lediglich die Browser-Adressleiste ohne Anmeldung zugänglich ist. (iii) Ausnutzbarkeit. Dieses Maß gibt an, was zur Ausnutzung dieser Bedrohung erforderlich ist. Ein Wert von Null bedeutet, dass fortgeschrittene, individuell entwickelte Angriffswerkzeuge, Netzwerkkenntnisse und fortgeschrittene Programmierkenntnisse erforderlich sind; ein Wert von Fünf bedeutet, dass Schadsoftware vorhanden ist oder mit Standardangriffswerkzeugen ausgeführt wird; und ein Wert von Zehn bedeutet, dass lediglich ein Browser vorhanden ist. (iv) Betroffene Benutzer. Messen Sie, wie viele Benutzer von dieser Bedrohung betroffen sein werden. Ein Wert von Null bedeutet keine; ein Wert von Fünf bedeutet einige, aber nicht alle Benutzer; und ein Wert von Zehn bedeutet alle Benutzer. (v) Auffindbarkeit. Messen Sie, wie leicht diese Bedrohung entdeckt werden kann. Ein Wert von Null bedeutet sehr schwierig oder unmöglich; es ist Zugriff auf das System oder den Quellcode erforderlich; ein Wert von Fünf bedeutet, dass sie durch die Untersuchung von Netzwerkspuren erkannt werden kann; ein Wert von Neun bedeutet, dass Details zu solchen Schwachstellen öffentlich verfügbar sind und mit leistungsstarken Suchmaschinen wie Google, Yahoo usw. gefunden werden können; und ein Wert von Zehn bedeutet, dass sie in der Adressleiste oder in einem Formular vorhanden ist.
Häufige Web-Schwachstellen. Proaktive Sicherheitsmaßnahmen.
Verschiedene Quellen ermöglichen die Identifizierung von Web-Schwachstellen, Bedrohungen und Sicherheitsrisiken: (i) OWASP (Open Web Application Security Project) veröffentlicht jährlich das Dokument „Top 10 Mitigable Threats/Risks“ auf Basis von Rohdaten der MITRE CVE. (ii) SANS veröffentlicht jährlich das Dokument „SANS Top 20 Internet Security Attack Targets“. (iii) eEye Digital Security. (iv) Zero-Day Tracker. (v) US-CERT aktualisiert seine Informationen wöchentlich. Eine Schwachstelle von Webbrowsern wie IE, Safari usw. ist deren Fähigkeit, automatisch Maßnahmen zu ergreifen, um die Auswirkungen von Inkonsistenzen auf Webseiten zu begrenzen. Fehlt beispielsweise das schließende `</body>`-Tag einer Webseite, kann der Browser die Seite korrekt anzeigen oder JavaScript ausführen, selbst wenn das Wort innerhalb eines `<script>`-Tags auf zwei Zeilen verteilt ist, wobei eine Zeile `java` und die andere `script` angibt. Angreifer nutzen diese Schwachstelle aus, um die Funktionsfähigkeit einer Webseite zu beeinträchtigen. Es gibt weit verbreitete Missverständnisse bezüglich der Sicherheit von Webanwendungen, beispielsweise die Annahme, dass SSL/TLS eine Website schützt, herkömmliche Firewalls Webanwendungen schützen oder IDS/IPS Web- und Datenbankserver schützen. Die Sicherheit von Webanwendungen lässt sich nicht allein durch Antivirensoftware, Schwachstellenscanner, Firewalls/DMZs, IDS/IPS, Patch- und Compliance-Management sowie Serversicherheit gewährleisten. Sie erfordert zusätzliche Schutzmaßnahmen wie statische Analyse (beispielsweise Veracode, Fortify, Coverity, KlocWork und OunceLabs) und dynamische Analyse (beispielsweise IBM mit RationalAppscan, HP mit WebInspect, Ntoobjectives mit NTOSpider, Cenzic mit Hailstorm und Whitehat Security), Webanwendungs-/XML-Firewalls, Code-Reviews und -Analysen, umfassenden Schutz des Softwareentwicklungszyklus (SDLC) und Entwicklerschulungen.
Reaktive Ansätze bei Sicherheitsvorfällen sind unzureichend und führen zu einem Teufelskreis aus Krisen, der oft in einer totalen Katastrophe mündet. Daher sind proaktive Schutzmaßnahmen unerlässlich, wie beispielsweise: (i) Integrierte Sicherheitstests während des gesamten Softwareentwicklungszyklus (SDLC). (ii) Erneute Tests und Rezertifizierungen bei wesentlichen Änderungen an der System- oder Webanwendungsumgebung. (iii) Überprüfung der Architektur und Analyse potenzieller Schwachstellen (Lücken). (iv) Implementierung integrierter Sicherheits- und mehrschichtiger Sicherheitskonzepte. (v) Einsatz von XML-Firewalls für Webdienste, die Bedrohungen wie SQL-Injection, Angriffe externer Entitäten, rekursive Payloads, Schema-Poisoning, Denial-of-Service-Angriffe, Buffer-Overflows usw. mithilfe von WSDL-Verifizierung, XML-Schema-Validierung, XML-Content-Based-Routing usw. abwehren können.
Schlussbetrachtungen
Unsere Forschungsgruppe beschäftigt sich seit über zwanzig Jahren mit der Sicherheitssynthese und -analyse im Kontext von Webanwendungen.
Dieser Artikel ist Teil der Aktivitäten im Rahmen des Projekts LEFIS-APTICE (gefördert von der Europäischen Kommission im Rahmen des Socrates-Programms).
Autor: Prof. Dr. Javier Areitio Bertolín – E-Mail:
Literaturverzeichnis
– Areitio, J. „Information Security: Networks, Computing and Information Systems“. Cengage Learning-Paraninfo. 2010.
– Areitio, J. „New approaches in the analysis of systems for detection-prevention and management of attacks-intrusions“. Conectrónica Magazine. Nr. 123. Januar 2009.
– Fry, C. und Nystrom, M. „Security Monitoring. Proven Methods for Incident Detection on Enterprise 200“.
