Das Open Web Application Security Project pflegt eine regelmäßig aktualisierte Liste der wichtigsten Sicherheitsbedenken bei Webanwendungen.
Nach Lektüre dieses Artikels können Sie Folgendes:
Ähnliche Inhalte
Sicherheit von Webanwendungen?
Brute-Force-Angriff
Datenschutzverletzung
On-Path-Angriff
Pufferüberlaufangriff
Abonnieren Sie theNET, Cloudflares monatliche Zusammenfassung der beliebtesten Einblicke in das Internet!
Link zum Artikel kopieren
Das Open Web Application Security Project oder OWASP ist eine internationale Non-Profit-Organisation, die sich der Sicherheit von Webanwendungen widmet. Eines der Grundprinzipien von OWASP ist, dass alle Materialien frei verfügbar und auf ihrer Website leicht zugänglich sind, so dass jeder die Sicherheit seiner eigenen Webanwendungen verbessern kann. Sie bieten Materialien wie Dokumentationen, Tools, Videos und Foren an. Ihr wohl bekanntestes Projekt sind die OWASP Top 10.
Die OWASP Top 10 sind ein regelmäßig aktualisierter Bericht, der Sicherheitsbedenken für Webanwendungen beschreibt und sich dabei auf die 10 kritischsten Risiken konzentriert. Der Bericht wird von einem Team aus Sicherheitsexperten aus aller Welt zusammengestellt. OWASP bezeichnet die Top 10 als „Sensibilisierungsdokument“ und empfiehlt allen Unternehmen, den Bericht in ihre Prozesse einzubeziehen, um Sicherheitsrisiken zu minimieren und/oder abzuwehren
Es folgen die OWASP Top 10 Sicherheitsrisiken des Berichts von 2017:
Injection-Angriffe erfolgen, wenn nicht vertrauenswürdige Daten über eine Formulareingabe oder eine andere Datenübermittlung an eine Webanwendung an einen Code-Interpreter gesendet werden. Angreifer könnten beispielsweise SQL-Datenbankcode in ein Formular eingeben, das einen Benutzernamen in Klartext erwartet. Wenn diese Formulareingabe nicht entsprechend gesichert ist, wird der SQL-Code ausgeführt. Das ist als SQL-Injection-Angriff bekannt.
Injection-Angriffe können verhindert werden, indem vom Benutzer übermittelte Daten validiert und/oder bereinigt werden. (Validierung bedeutet, verdächtig aussehende Daten abzulehnen und die verdächtig aussehenden Teile der Daten zu bereinigen.) Darüber hinaus kann ein Datenbankadministrator Kontrollen einbauen, um die Menge an Informationen zu minimieren, die ein Injection-Angriff ausspähen kann.
Erfahren Sie mehr darüber , wie Sie SQL-Injection verhindern können.
Sicherheitslücken in Authentifizierungssystemen (Anmeldung) können Angreifern Zugriff auf Benutzerkonten und sogar die Möglichkeit geben, mithilfe eines Administratorkontos ein ganzes System zu kompromittieren. Zum Beispiel kann ein Angreifer eine Liste mit Tausenden bekannten Kombinationen aus Benutzernamen und Passwörtern nehmen, die er im Zuge einer Datenschutzverletzung erhalten hat, und ein Skript verwenden, das alle diese Kombinationen in einem Anmeldesystem ausprobiert, um zu sehen, welche davon funktionieren.
Einige Strategien zur Minimierung von Sicherheitslücken bei der Authentifizierung verlangen eine Zwei-Faktor-Authentifizierung (2FA) und begrenzen oder verzögern wiederholte Anmeldeversuche mit Durchsatzbegrenzung.
Wenn Webanwendungen sensible Daten wie Finanzinformationen und Passwörter nicht schützen, können Angreifer auf diese Daten zugreifen und sie für schädliche Zwecke verkaufen oder einsetzen. Eine beliebte Methode zum Stehlen sensibler Informationen ist der On-Path-Angriff.
Das Risiko des Verlusts der Vertraulichkeit von Daten kann minimiert werden, indem alle sensiblen Daten verschlüsselt und das Caching* aller sensiblen Informationen deaktiviert werden. Darüber hinaus sollten Webanwendungsentwickler darauf achten, dass sensible Daten nicht unnötig gespeichert werden.
*Beim Caching werden Daten zur Wiederverwendung temporär gespeichert. Beispielsweise cachen Webbrowser häufig Webseiten, so dass sie die Seiten nicht erneut aus dem Web abrufen müssen, wenn Benutzer diese Seiten innerhalb eines festgelegten Zeitraums erneut besuchen.
Das ist ein Angriff auf eine Webanwendung, die XML*-Eingaben analysiert. Diese Eingabe kann auf eine externe Entität verweisen, die versucht, eine Sicherheitslücke im Parser auszunutzen. In diesem Zusammenhang bezieht sich die „externe Entität“ auf eine Speichereinheit wie z. B. eine Festplatte. Ein XML-Parser kann dazu verleitet werden, Daten an eine nicht autorisierte externe Entität zu senden, die die sensiblen Daten direkt an einen Angreifer weitergeben kann.
Die beste Möglichkeit, XEE-Angriffe zu verhindern, besteht darin, dass Webanwendungen einen weniger komplexen Datentyp wie JSON** akzeptieren oder zumindest XML-Parser patchen und die Verwendung externer Entitäten in einer XML-Anwendung deaktivieren.
*XML oder Extensible Markup Language ist eine Markup-Sprache, die sowohl für Menschen als auch für Maschinen lesbar sein soll. Aufgrund ihrer Komplexität und der Sicherheitslücken wird die Nutzung in vielen Webanwendungen allmählich abgebaut.
**JavaScript Object Notation (JSON) ist eine einfache, für Menschen lesbare Notation, die häufig zur Übertragung von Daten über das Internet verwendet wird. Obwohl JSON ursprünglich für JavaScript erstellt wurde, ist sie sprachunabhängig und kann von vielen verschiedenen Programmiersprachen interpretiert werden.
Die Zugriffskontrolle ist ein System, das den Zugriff auf Informationen oder Funktionen steuert. Eine fehlerhafte Zugriffskontrolle gestattet es Angreifern, die Autorisierung zu umgehen und Aufgaben auszuführen, als wären sie berechtigte Benutzer wie Administratoren. Beispielsweise kann eine Webanwendung es Benutzern ermöglichen, das Konto, in dem sie angemeldet sind, einfach zu ändern, indem sie einen Teil einer URL ohne weitere Überprüfung bearbeiten.
Zugriffskontrollen können geschützt werden, indem sichergestellt wird, dass eine Webanwendung Autorisierungstoken* verwendet und strenge Kontrollen für sie festlegt.
*Viele Dienste stellen Autorisierungstoken aus, wenn sich Benutzer anmelden. Bei jeder berechtigten Anfrage von Benutzern muss das Autorisierungstoken vorhanden sein. Das ist eine sichere Methode, um zu gewährleisten, dass die Benutzer diejenigen sind, für die sie sich ausgeben, ohne ständig die Anmeldeinformationen eingeben zu müssen.
Sicherheitsrelevante Fehlkonfigurationen sind die häufigste Schwachstelle in der Liste und oft das Ergebnis der Nutzung von Standardkonfigurationen oder übermäßig ausführlicher Fehleranzeigen. Beispielsweise kann eine Anwendung Benutzern Fehler übermäßig detailliert beschreiben, die Schwachstellen in der Anwendung aufdecken können. Das kann abgemildert werden, indem nicht genutzte Features aus dem Code entfernt werden und für allgemeinere Fehlermeldungen gesorgt wird.
Cross-Site-Scripting-Sicherheitslücken treten auf, wenn Benutzer mithilfe von Webanwendungen benutzerdefinierten Code in einen URL-Pfad oder auf eine Website einfügen dürfen, den andere Benutzer sehen können. Diese Sicherheitslücke kann ausgenutzt werden, um böswilligen JavaScript-Code im Browser eines Opfers auszuführen. Angreifer könnten beispielsweise eine E-Mail an ein Opfer senden, die anscheinend von einer vertrauenswürdigen Bank stammt und einen Link zur Website dieser Bank enthält. Dieser Link könnte am Ende der URL schädlichen JavaScript-Code enthalten. Wenn die Website der Bank nicht ausreichend gegen Cross-Site-Scripting geschützt ist, wird dieser Schadcode im Webbrowser des Opfers ausgeführt, sobald es auf den Link klickt.
Strategien zur Schadensbegrenzung bei Cross-Site Scripting umfassen das Verhindern nicht vertrauenswürdiger HTTP-Anfragen sowie das Überprüfen und/oder Bereinigen von benutzergenerierten Inhalten. Die Verwendung moderner Webentwicklungs-Frameworks wie ReactJS und Ruby on Rails bietet ebenfalls einen integrierten Schutz gegen Cross-Site Scripting.
Diese Bedrohung zielt auf die vielen Webanwendungen ab, die häufig Daten serialisieren und deserialisieren. Serialisierung bedeutet, Objekte aus dem Anwendungscode zu entnehmen und in ein Format zu konvertieren, das für einen anderen Zweck genutzt werden kann, z. B. zum Speichern der Daten auf der Festplatte oder zum Streamen. Deserialisierung ist das Gegenteil: das Konvertieren von serialisierten Daten zurück in Objekte, die die Anwendung nutzen kann. Serialisierung ist so etwas wie das Verpacken von Möbeln in Kisten vor einem Umzug. Deserialisierung ist wie das Auspacken der Kisten und das Zusammenbauen der Möbel nach dem Umzug. Ein Angriff auf unsichere Deserialisierung ist so, als würde die Spedition vor dem Auspacken den Inhalt der Kisten manipulieren.
Ein Exploit gegen unsichere Deserialisierung ist das Ergebnis der Deserialisierung von Daten aus nicht vertrauenswürdigen Quellen und kann schwerwiegende Folgen wie DDoS-Angriffe und Remote Code Execution haben. Zwar können Schritte unternommen werden, um Angreifer zu fassen, z. B. durch Überwachung der Deserialisierung und Implementierung von Typprüfungen, dennoch besteht der einzig sichere Weg zum Schutz vor Angriffen auf unsichere Deserialisierung darin, die Deserialisierung von Daten aus nicht vertrauenswürdigen Quellen zu verbieten.
Viele moderne Webentwickler setzen in ihren Webanwendungen Komponenten wie Bibliotheken und Frameworks ein. Diese Komponenten sind Software, mit denen Entwickler redundante Arbeiten vermeiden und die erforderliche Funktionalität bereitstellen können. Gern genutzte Beispiele sind Frontend-Frameworks wie React und kleinere Bibliotheken, die Teilen-Icons oder A/B-Tests hinzufügen. Einige Angreifer suchen nach Schwachstellen in diesen Komponenten, mit denen sie Angriffe orchestrieren können. Einige der beliebtesten Komponenten werden auf Hunderttausenden von Websites verwendet. Angreifer, die eine Sicherheitslücke in einer dieser Komponenten finden, können Hunderttausende Websites für Exploits verwundbar machen.
Komponentenentwickler bieten häufig Sicherheitspatches und -updates an, um bekannte Sicherheitslücken zu schließen. Webanwendungsentwickler verfügen jedoch nicht immer über die gepatchten oder neuesten Versionen der Komponenten, die in ihren Anwendungen ausgeführt werden. Um das Risiko des Ausführens von Komponenten mit bekannten Sicherheitslücken zu minimieren, sollten Entwickler nicht verwendete Komponenten aus ihren Projekten entfernen sowie sicherstellen, dass sie die Komponenten aus einer vertrauenswürdigen Quelle beziehen und diese auf dem neuesten Stand sind.
Viele Webanwendungen ergreifen nicht genügend Maßnahmen, um Datenschutzverletzungen zu erkennen. Die durchschnittliche Zeit, bis ein Verstoß erkannt wird, beträgt ca. 200 Tage nach seinem Auftreten. Das gibt Angreifern viel Zeit, um Schaden anzurichten, bevor eine Reaktion erfolgt. OWASP empfiehlt Webentwicklern, die Protokollierung und Überwachung sowie Pläne für die Reaktion auf Vorfälle zu implementieren, um sicherzustellen, dass sie auf Angriffe auf ihre Anwendungen aufmerksam gemacht werden.
Einen technischeren und detaillierteren Blick auf die OWASP Top 10 finden Sie im offiziellen Bericht.