Auf Verbraucherseite haben zahlreiche Fälle von Datenverlusten wie etwa der Supergau bei dem amerikanischen Handelskonzern TJX, bei dem insgesamt rund 45,7 Millionen Kreditnummern gestohlen wurden, das Bewusstsein für das Thema Web-Sicherheit geschärft. Anders sieht es offenbar bei den Entwicklern von Web-Anwendungen aus: Sicherheitsexperten werfen ihnen vor, sich ihrer Verantwortung nicht genügend bewusst zu sein.
Statt Sicherheitsaspekte schon in der Designphase zu berücksichtigen, würden sie meist erst dann thematisiert, wenn eine Web-Seite bereits steht, bemängelt Forrester-Analyst Khalid Kark. Aufgrund dieser Nachlässigkeit hält der Experte das Gros der Sites anfällig für Hacker-Attacken. "Das Problem ist, dass IT-Sicherheit zum Zeitpunkt der Entstehung einer Applikation schlicht nicht berücksichtigt wird." Auch IT-Berater Joel Snyder kritisiert die Zunft der Programmierer, die das Thema Web Application Security seiner Beobachtung nach völlig ignoriert. Als größtes Manko erachtet er, dass Designer auf applikationsinterne Schutzwälle verzichteten, die es ermöglichen würden, zwischen den einzelnen Programmteilen hin- und herwandernde Daten zu isolieren und zu bewerten.
Um die Lösung dieses Problems bemüht sich auch das "Open Web Application Security Project" (Owasp). Ziel der Nonprofit-Community ist es, Web-Entwicklern mit ihrer jährlich aktualisierten Liste "The Ten Most Critical Web Application Security Vulnerabilites" die jeweils größten Sicherheitsrisiken nahe zu bringen. Laut Jeff Williams, Owasp-Chairman und CEO von Aspect Security, hat sich die Lage seit der Erstveröffentlichung der Schwachstellenliste im Jahr 2004 kaum verbessert. Vielmehr hätten neue Techniken wie Ajax und Rich Internet Applications, die das Äußere der Sites verschönern, zusätzliche Angriffsflächen geschaffen. Unternehmen von den Sicherheitsdefiziten ihrer Web-Seiten zu überzeugen, sei jedoch kein leichtes Unterfangen. "Es ist frustrierend, weil die Fehler so offensichtlich sind – wie bei einem Haus, dem eine Wand fehlt", schildert Williams seine Erfahrungen. Die Kollegen der CW-Schwesterpublikation "Network World" haben die jüngste Ausgabe des Owasp-Reports zusammengefasst und um aktuelle Beispiele ergänzt:
1. Cross Site Scripting (XSS)
Das Problem: XSS-Lücken gehören zu den gängigsten und gefährlichsten Schwachstellen in Web-Anwendungen. Sie entstehen, wenn eine Applikation von Nutzern stammende Daten an einen Web-Browser schickt, ohne die Inhalte zuvor zu überprüfen oder zu verschlüsseln. XXS ermöglicht Hackern, bösartige Skripte im Browser des Opfers auszuführen und darüber Nutzer-Sessions zu kapern, Schadcode zu injizieren und Phishing- beziehungsweise Malware-Attacken zu fahren. Die Angriffe werden in der Regel mittels JavaScript ausgeführt, im Prinzip ist aber jede vom Browser unterstützte Script-Sprache anfällig für diese Art von Attacke, so der Report.
Beispiel: Im vergangenen Jahr geriet der Bezahldienst PayPal ins Fadenkreuz von Hackern. Im Zuge der Attacke wurden PayPal-Besucher unter dem Vorwand, ihre Accounts seien gehackt worden, auf eine Phishing-Seite umgeleitet und dort zur Eingabe ihrer Login-Daten, Sozialversicherungsnummern sowie Kreditkartendetails aufgefordert. Nach Angaben der Firma wurde die Sicherheitslücke im Juni 2006 geschlossen.
Basis-Schutz: Laut Owasp empfiehlt es sich, sämtliche eingehenden Daten mit Hilfe einer Whitelist zu überprüfen. Anders als beim Black-Listing, das lediglich nachweislich "schlechten" Input blockiert, lehnt das Whitelist-Verfahren alles ab, was in der Liste nicht explizit als "gutartig" aufgeführt ist. Der gesamte Daten-Output wiederum sollte verschlüsselt sein. Mittels Validierung lassen sich Attacken aufspüren und vereiteln, während Verschlüsselung verhindert, dass erfolgreich injizierter Schadcode im Browser laufen kann.
2. Injection-Fehler (etwa SQL-Injection)
Das Problem: Werden von Nutzern stammende Daten als Teil eines Befehls oder einer Anfrage an einen Interpreter gesendet, können ihn Hacker mit Hilfe manipulierter Daten dazu bringen, unerwünschte Befehle auszuführen oder Daten zu modifizieren. Injection-Fehler ermöglichen es Angreifern, beliebige, für die Applikation verfügbare Daten zu erstellen, zu lesen, zu aktualisieren oder auch zu löschen. Im schlimmsten Fall kann ein Angreifer die komplette Anwendung sowie die darunter liegenden Systeme kompromittieren und dabei sogar Firewall-Umgebungen umgehen.
Beispiel: Russische Hacker machten sich im Januar 2006 an einer Web-Seite der Regierung des US-Bundesstaats Rhode Island zu schaffen, um Kreditkarteninformationen zu stehlen. Die Übeltäter behaupteten, im Zuge der SQL-Injection-Attacke 53.000 Kreditkartennummern entwendet zu haben, auf Seiten des Hosting-Dienstleisters war allerdings nur von 4.113 die Rede.
Basis-Schutz: Laut Report ist die Nutzung von Interpretern zu vermeiden. Ist der Aufruf eines Interpreters unumgänglich, sollten ausschließlich sichere APIs (Application Programming Interfaces) verwendet werden – dazu zählen die Experten streng typisierte parametrisierte Queries und ORM-Libraries (Object Relational Mapping).
3. Die Ausführung bösartiger Dateien
Das Problem: Hacker können aus der Ferne Schadcode zur Ausführung bringen, Rootkits installieren oder ein komplettes System kompromittieren. Für die so genannte Remote File Inclusion (RFI) ist im Prinzip jede Web-Applikation oder jedes Framework anfällig, das Dateien oder Dateinamen von Nutzern akzeptiert. Besonders häufig tritt die Bedrohung im Zusammenspiel mit der weit verbreiteten Skriptsprache PHP auf.
Beispiel: Ein jugendlicher Programmierer hatte im Jahr 2002 eine Sicherheitslücke bei der Mode-Site Guess.com entdeckt, die den Diebstahl von rund 200.000 Kundendaten wie Namen und Kreditkartennummern aus der Guess-Datenbank ermöglichte. Nach einer Untersuchung durch die Federal Trade Commission erklärte sich das Unternehmen bereit, sein Sicherheitsbollwerk entsprechend aufzurüsten.
Basis-Schutz: Nach Empfehlung der Owasp sollte Nutzer-Input für die Konstruktion von Dateinamen für Server-basierende Ressourcen im Skript vermieden werden. Auch sind Firewall-Regeln so zu setzen, dass sie neue Verbindungen zu externen Web-Sites oder internen Systemen verhindern.
4. Unsichere Direct-Object-Referenz
Das Problem: Angreifer manipulieren Direct Object References, um unautorisiert auf andere Objekte zugreifen zu können. Möglich ist dies, wenn URLs oder Formparameter Hinweise auf interne Objekte wie Dateien, Verzeichnisse, Datenbankeinträge oder Schlüssel enthalten. So wird auf Banken-Sites häufig die Kontonummer als primärer Datenbank-Index verwendet oder auch direkt im Web-Interface genutzt. "Hinweise auf Datenbankschlüssel liegen häufig offen", so der Report. Demnach kann ein Hacker durch intelligentes Raten oder einfaches Suchen weitere Schlüssel finden und so an fremde Daten gelangen.
Beispiel: Die Web-Seite einer australischen Steuerbehörde wurde im Jahr 2000 auf diese Weise von einem legitimen, aber feindlich gesinnten Nutzer gehackt. Er veränderte eine in der URL befindliche Steuer-ID und verschaffte sich so Zugriff auf detaillierte Informationen zu 17.000 Unternehmen. Peinlich: Der "Hacker" informierte die betroffenen Organisationen per E-Mail über die behördliche Sicherheitspanne.
Basis-Schutz: Um die Offenlegung von Direct Object References zu vermeiden, empfiehlt die Owasp, einen Index, eine indirekte Referenzierung oder eine andere indirekte, leicht zu validierende Methode zu verwenden. Sind direkte Referenzen dennoch erforderlich, müssen für deren Nutzung sichernde Autorisierungsmechanismen eingeführt werden.
5. Cross Site Request Forgery (CSRF)
Das Problem: CSRF-Attacken, unter anderem auch "Session Riding" oder "One Klick Attacks" genannt, sind nicht neu, aber einfach - und potenziell verheerend. Bei dieser Angriffsart übernimmt der Hacker die Kontrolle über den Browser seines Opfers, sobald sich dieser bei einer Web-Seite eingeloggt hat, und sendet in dessen Namen bösartige Anfragen an die Web-Applikation. Web-Seiten sind diesbezüglich extrem verwundbar, weil sie Requests in der Regel auf Basis von Session-Cookies oder über die "Remember-me"-Funktion autorisieren. "99 Prozent der Applikationen im Internet sind anfällig für Cross Site Request Forgery", warnt Owasp-Chef Williams.
Beispiel: Ein als "Samy" bekannter Hacker verschaffte sich auf diese Weise Ende 2005 über eine Million "Freunde" auf MySpace.com. Als Hilfsmittel diente ein Wurm, der den Text "Samy is my hero" automatisch in Tausende von MySpace-Seiten einfügte. Der Vorfall mag zwar keinen großen Schaden angerichtet haben, demonstrierte aber das Gefahrenpotenzial, dass die Kombination aus Cross Site Scripting und Cross Site Request Forgery birgt.
Basis-Schutz: Laut Owasp gilt es zu gewährleisten, dass sich Applikationen nicht auf automatisch vom Browser übermittelte Daten oder Tokens verlassen. Die einzige Lösung aus Sicht der Experten: Die Verwendung nutzerspezifischer Tokens, die der Browser nicht speichert.
6. Informationslecks und 'indiskrete' Fehlerbehandlung durch die Web-Anwendung
Das Problem: Von Applikationen erzeugte Fehlermeldungen, die sensible Daten oder Informationen etwa über ihre Konfiguration preisgeben, sind für Hacker ein gefundenes Fressen. Laut Owasp-Report liefern viele Anwendungen mit detaillierten Error- beziehungsweise Debug-Meldungen unbeabsichtigt aufschlussreiche Anhaltspunkte zu ihren Interna - etwa über die zur Verarbeitung bestimmter Operationen benötigte Zeit oder ihre Reaktionen auf verschiedenen Input. Übeltäter können diese Informationen dazu missbrauchen, schwerwiegende Angriffe zu lancieren oder sogar zu automatisieren.
Beispiel: Nicht nur das unsachgemäße Fehler-Handling kann zum unerwünschten Abfluss von Daten führen. Data Leakage tritt auch auf, wenn vertrauliche Informationen ungeschützt und damit einsehbar sind. So geschehen beispielsweise Anfang 2005, als die Datensätze von 163.000 ChoicePoint-Kunden kompromittiert wurden. Dazu hatten sich Kriminelle als legitime Kunden des amerikanischen Schufa-Pendants ausgegeben und dessen Kundendatenbank nach Details zu den dort gelisteten Personen durchforstet.
Basis-Schutz: Die Experten empfehlen den Einsatz eines Test-Tools wie dem Owasp-eigenen "WebScarab Project", um zu eruieren, welche Fehlermeldungen die Applikation erzeugt. Zudem sollte das detaillierte Error-Handling deaktiviert oder zumindest eingeschränkt werden und Debug-Informationen für Nutzer nicht sichtbar sein.
7. Fehler bei Authentisierung und Session-Management
Das Problem: Wenn Applikationen Zugangsdaten und Session-Tokens nicht angemessen, sprich: über den gesamten Lebenszyklus hinweg schützen, können Angreifer Kontrollen hinsichtlich Autorisierung und Verantwortlichkeiten unterwandern und Nutzerkonten sowie administrative Accounts kapern. "Fehler in den tragenden Authentisierungsmechanismen sind nicht selten. Häufiger entstehen die Schwachstellen jedoch durch zusätzliche Authensierungsfunktionen wie Logout, Passwort-Management, Timeout, "remember me", geheime Fragen sowie Account-Updates."
Beispiel: Microsoft musste im Jahr 2002 eine Schwachstelle in Hotmail beheben, die es Hackern ermöglichte, Nutzerpasswörter zu stehlen. Die Sicherheitslücke ließ sich via E-Mail mit einem darin befindlichen Trojaner ausnutzen. Dieser modifizierte das Hotmail-User-Interface so, dass die Nutzer gezwungen waren, ihre Passwörter wiederholt einzugeben, und damit unwissentlich an die Kriminellen sandten.
Basis-Schutz: Kommunikations- und Zugangsdaten müssen sicher gespeichert werden. Das Verschlüsselungsprotokoll SSL sollte für Anwendungskomponenten, die eine Authentisierung erfordern, die einzige Option sein. Die Zugangsdaten gilt es, als Hash-Wert oder verschlüsselt zu speichern. Ferner rät OWASP, kundenspezifische Cookies für die Authentisierung oder das Session-Management abzuschaffen.
8. Unzureichend verschlüsselte Datenablage
Das Problem: Verschlüsselung zum Schutz vertraulicher Daten ist mittlerweile ein Kernbestandteil der meisten Web-Anwendungen. Dennoch werden diese Informationen häufig uncodiert abgelegt. Wo Verschlüsselung vorhanden ist, weist sie oft erhebliche Designschwächen auf. Probleme bereitet es laut Owasp unter anderem, wenn eigenentwickelte Algorithmen eingesetzt, starke Algorithmen unfachgemäß oder bekanntermaßen schwache Algorithmen wie MD5, SHA-1 und RC3/4 weiterhin verwendet werden. "Diese Fehler können die Offenlegung sensibler Daten sowie Verstöße gegen Compliance-Vorschriften zur Folge haben", so der Report.
Beispiel: Für Schlagzeilen sorgte in diesem Kontext der besagter Datenverlust bei TJX. Für den Datenabfluss verantwortlich war nach einer Untersuchung der kanadischen Regierung das Versäumnis des Unternehmens, seine Datenverschlüsselungslösung auf den neuesten Stand zu bringen, und damit seit Juli 2005 ein Ziel für elektronische Lauschangriffe zu bieten.
Basis-Schutz: Laut Owasp ist vom Einsatz selbst gebastelter beziehungsweise schwacher Verschlüsselungsalgorithmen dringend abzuraten. Ferner sollten Schlüssel generell offline erzeugt und private Keys nur über abgesicherte Kanäle übermittelt werden.
9. Unsichere Kommunikation
Das Problem: Häufig verschlüsseln Web-Applikationen den Netzverkehr nicht, so dass vertrauliche Kommunikation ungeschützt ist. Angreifer können sich so Zugriff auf die Konversationsinhalte sowie übermittelte Zugangsdaten und sensible Informationen verschaffen.
Beispiel: Wieder TJX: Den Ermittlern zufolge sollen Hacker eine Parabol-Antenne und ein Notebook verwendet haben, um an die Daten zu gelangen, die drahtlos zwischen tragbaren Price-Checking-Geräten, Kassen- und Rechnersystemen ausgetauscht wurden. "Das 17,4-Milliarden-Dollar-Funknetz des Retailers verfügte über weniger Sicherheitsvorkehrungen als die Netze vieler Heimanwender", schrieb das Wall Street Journal. TJX hatte das Verschlüsselungsprotokoll WEP (Wired Equivalent Privacy) anstelle des robusteren WPA (Wi-Fi Protected Access) verwendet.
Basis-Schutz: Owasp empfiehlt, SSL bei jeder Übermittlung sensibler Daten zu verwenden. Auch sollten Online-Zugriffe durch Kunden, Partner, Mitarbeiter oder Administratoren mittels SSL oder einem vergleichbaren Verschlüsselungsprotokoll geschützt sein. Wichtig sei zudem, die Kommunikation zwischen Infrastrukturelementen wie Web-Servern und Datenbanken mittels Transport Layer Security oder Verschlüsselung auf Protokollebene zu schützen.
10. Uneingeschränkter Zugriff auf URLs
Das Problem: Manche Web-Seiten sollen lediglich für eine kleine Gruppe privilegierter Nutzer - etwa Administratoren – zugänglich sein. Doch häufig verfügen diese Sites über keine echte Zugangskontrolle, so dass versierte Hacker die URLs ausfindig machen können. Die primäre Angriffsmethode, die diese Art von Schwäche ausnutzt, nennt sich "Forced Browsing" und beinhaltet das Erraten von Links sowie Brute-Force-Techniken zum Aufspüren ungeschützter Seiten, so der Report.
Beispiel: Über eine solche Schwachstelle auf der Web-Seite der diesjährigen Macworld Conference & Expo haben sich Nutzer kostenlos "Platinum"-Tickets im Wert von 1.700 Dollar sowie speziellen Zugriff auf eine Keynote von Steve Jobs verschafft. Der Fehler lag im Code, der Privilegien auf dem Client, nicht aber auf dem Server überprüfte.
Basis-Schutz: Laut Owasp sollten Unternehmen nicht davon ausgehen, dass Nutzer verborgene URLs oder APIs nicht bemerken. Sämtliche URLs und Business-Funktionen müssten demnach durch einen effektiven Zugangskontrollmechanismus geschützt sein, der Rollen und Privilegien der Nutzer verifiziert. (kf)