22 Häufige Schwachstellen in Webanwendungen, die Sie kennen sollten
Veröffentlicht: 2021-10-14Unternehmen bewegen sich ständig nach links und nutzen die innovativen Kunden- und Mitarbeitererlebnisse, die von Cloud-gesteuerten Anwendungen bereitgestellt werden. Gleichzeitig passen auch böswillige Täter ihre Angriffsstrategien kontinuierlich an diesen Wandel an.
Um den Datenschutz und die Sicherheit zu wahren, ist es unerlässlich, dass Unternehmen Schutz vor diesen 22 häufigen Schwachstellen in Webanwendungen suchen .
Beschädigte Zugangskontrolle
Zugriffskontrollen sind dafür verantwortlich, wie Benutzer mit Ressourcen und Daten interagieren und was sie bearbeiten und/oder lesen können. Eine fehlerhafte Schwachstelle in der Zugriffskontrolle ist möglich, wenn der Benutzer in der Lage ist, die Daten auf eine wirklich unnötige Weise zu erfassen. Wenn der Benutzer beispielsweise Zahlungsdetails nur lesen, aber tatsächlich bearbeiten können soll, ist eine solche Situation ein Beispiel für eine gebrochene Zugriffskontrolle. Böswillige Angreifer nutzen diese Schwachstelle aus, um sich unbefugten Zugriff auf Software, Netzwerke und Systeme zu verschaffen. Sie können dann die Situation ausnutzen, der Benutzer-ID mehr Zugriff innerhalb der Infrastruktur gewähren, um die Datenverfügbarkeit, Vertraulichkeit oder Integrität zu gefährden.
Beschädigte Authentifizierung
Sicherheitslücken in Webanwendungen im Zusammenhang mit beschädigter oder unterbrochener Authentifizierung gehen ebenfalls auf den Benutzerzugriff zurück. In diesem Fall wirken sich böswillige Angreifer jedoch negativ auf die Daten aus, die die Identität eines Benutzers bestätigen, z. B. durch das Hijacking von Sitzungstoken, Schlüsseln oder Passwörtern. Der böswillige Angreifer verschafft sich unbefugten Zugriff auf die Software, Systeme und Netzwerke, weil die Organisation keine angemessenen Kontrollen für die Identitäts- und Zugriffsverwaltung festlegen konnte.
Carriage Return and Line Feed (CRLF) Injektion
Carriage Return fungiert als Befehl, der den Beginn einer Codezeile bezeichnet, typischerweise als /r angegeben. Zeilenvorschub hingegen ist ein Befehl, der das Ende einer Codezeile bezeichnet, typischerweise als /n angegeben. Wie viele andere Software verwendet jedes Betriebssystem unterschiedliche Kombinationen von Wagenrücklauf und Zeilenvorschub. Wenn böswillige Angreifer an CRLF-Injektionen beteiligt sind, ändert der eingegebene Code die Art und Weise, wie die Webanwendung auf Befehle reagiert. Dies kann verwendet werden, um entweder sensible Daten offenzulegen oder Code auszuführen.
Verschlüsselungstransformation unsicher
Chiffre, ein Standardbegriff für „Verschlüsselungsalgorithmus“, ist eigentlich die Mathematik hinter einem Verschlüsselungs- oder Entschlüsselungsprozess. Transformation bezieht sich auf die Umrisse von Operationen, die an der Eingabe ausgeführt werden, um die erwartete Ausgabe zu liefern. Somit bezieht sich eine Verschlüsselungstransformation auf die Anzahl von Operationen, die unlesbare verschlüsselte Daten zurück in lesbare, entschlüsselte Daten umwandeln. Eine unsichere Schwachstelle bei der Cipher Transformation beschreibt, dass der Verschlüsselungsalgorithmus leicht geknackt werden kann, was letztlich die Essenz der Verschlüsselung in erster Linie sabotiert.
Komponenten mit offensichtlichen Schwachstellen
Jede Webanwendung hängt von anderen Komponenten ab, um zu funktionieren. Wenn Sie beispielsweise eine Anwendung auf einem ungepatchten Web- oder Anwendungsserver betreiben, ist der Server der Teil mit offensichtlichen Schwachstellen. Die Liste Common Vulnerabilities and Exposures (CVE) umfasst alle bekannten Sicherheitslücken. Da böswillige Angreifer Kenntnis von der Liste haben, suchen sie häufig nach Komponenten ohne angemessene Sicherheitspatch-Updates. Sobald sie eine Komponente der Webanwendung infiltrieren können, können sie sich auch Zugriff auf die Daten der Anwendung verschaffen.
Cross-Origin Resource Sharing (CORS)-Richtlinie
Alle webbasierten Anwendungen verwenden eine URL als Medium, um den Browser des Benutzers mit seinem Server zu verbinden. Die Same Origin Policy ist ein gemeinsamer Schutz. Dementsprechend antwortet der Server nur auf eine URL mit demselben Protokoll, Pfadschema und Top-Level-Domänennamen. Das bedeutet, dass Sie auf http://organization.com/page1 und http://organization.com/page2 zugreifen können, da beide Folgendes gemeinsam haben:
- Protokoll: HTTP
- Domäne: Firma.com
- Pfadschema: /page#
Die Same Origin Policy ist zwar sicher, aber restriktiv im Umgang mit webbasierten Apps, die Zugriff auf Ressourcen erfordern, die eine Verbindung zu Drittanbietern oder Subdomains herstellen.
Eine CORS-Richtlinie erteilt dem Browser die Berechtigung, diese miteinander verbundenen Ressourcen anzuzeigen, indem eine Reihe von zulässigen HTTP-Headern festgelegt wird, die als „vertrauenswürdig“ gelten. Beispielsweise muss eine Anwendung möglicherweise Daten aus zwei Datenbanken auf separaten Webservern abrufen. Das Erstellen einer bestimmten „Erlaubt“-Liste wird zu einer übermäßigen Arbeit, wenn Sie zusätzliche Server einbeziehen. Da beide Server die Anwendung „teilen“, schreibt das Unternehmen eine CORS-Richtlinie, die es Browsern ermöglicht, sich mit beiden zu verbinden. Wenn eine CORS-Richtlinie jedoch nicht richtig definiert ist, kann die Richtlinie es den Servern ermöglichen, Zugriff zu gewähren, wenn dies von einem böswilligen Angreifer angefordert wird.
Anmeldeinformationen verwalten
Benutzeranmeldeinformationen bestehen aus einer Benutzer-ID und einem Hauptschlüssel. Der Benutzer muss beide Informationen auf der Anmeldeseite eingeben, bevor er Zugriff auf eine Anwendung erhält. Datenbanken neigen jedoch dazu, eine schwache Verschlüsselung zu verwenden oder Informationen im Klartext zu speichern. Eine schlechte Verwaltung von Anmeldeinformationen ermöglicht es Angreifern, Anmeldeinformationen leicht zu stehlen und sie auszunutzen, um Zugriff auf Webanwendungen zu erhalten.
Cross-Site Request Forgery (CSRF)
Ein CSRF-Angriff verwendet Social-Engineering-Methoden, um einen Benutzer dazu zu bringen, Informationen wie Passwörter oder Benutzernamen in einer Anwendung zu ändern. Im Gegensatz zu Cross-Site-Scripting (XXS)-Angriffen oder Malware erfordert ein CSRF, dass ein Benutzer bei der Anwendung angemeldet ist, die nur Sitzungscookies verwendet, um Benutzeranfragen zu validieren oder Sitzungen zu verfolgen. In dem Moment, in dem der Benutzer die erwartete Aktion ausführt, verwendet der böswillige Akteur den Browser, um den verbleibenden Teil des Angriffs auszuführen, z. B. das Verschieben von Geldern, ohne dass der Benutzer weiß, was passiert ist.
Cross-Site-Scripting (XXS)
Im Gegensatz zu einem CSRF, bei dem der Benutzer bei einer App angemeldet sein muss, um bestimmte Informationen zu ändern, erfordert ein XXS-Angriff, dass der böswillige Angreifer Code in eine Webseite eingibt, typischerweise in einige Komponenten der Seite, z. B. ein Bild. Sobald ein Benutzer die Webseite in seinem Browser startet, beginnt der schädliche Code, heruntergeladen und im Browser ausgeführt zu werden. Beispielsweise kann der bösartige Code den Benutzer von einer glaubwürdigen Website auf eine unzulässige umleiten.
Verzeichnisindizierung
Normalerweise fassen Webserver alle auf ihnen gespeicherten Dateien in einem einzigen Verzeichnis zusammen. Wenn ein Benutzer eine bestimmte Datei in einer Webanwendung finden möchte, fügt er normalerweise den Dateinamen in die Anfrage ein. Falls die Datei nicht verfügbar ist, präsentiert die Anwendung dem Benutzer eine Liste aller indizierten Dateien, sodass der Benutzer die Möglichkeit hat, etwas anderes auszuwählen.
Die Dateien werden jedoch automatisch von Webservern indiziert. Wenn die Anwendung eine Liste aller gespeicherten Dateien anzeigt, kann ein böswilliger Angreifer, der Schwachstellen im Verzeichnisindex ausnutzt, Zugriff auf Daten erhalten, die ihm weitere Informationen über das System liefern können. Sie können sich beispielsweise über persönliche Benutzerkonten oder Namenskonventionen informieren. Diese beiden Datenpunkte können ausgenutzt werden, um Angriffe zum Diebstahl von Anmeldeinformationen durchzuführen oder vertrauliche Informationen zu enträtseln.
Verzeichnisdurchlauf
Die auch als Backtracking-Angriff, Dot-Dot-Slash und Directory Climbing bekannte Schwachstelle beim Verzeichnisdurchlauf nutzt die Art und Weise aus, in der eine Anwendung Daten vom Webserver empfängt. Zugriffssteuerungslisten (ACLs) beschränken im Allgemeinen den Benutzerzugriff auf bestimmte Dateien in einem Stammverzeichnis. Böswillige Angreifer, die den Directory-Traversal-Schwachstellenmodus verwenden, ermitteln das URL-Format, das die Anwendung zum Anfordern von Dateien verwendet.
Verkapselung
Im Gegensatz zu einigen anderen häufigen Sicherheitslücken in Webanwendungen auf der Liste nutzt die Sicherheitslücke bei der Kapselung die Fehler in der Art und Weise aus, wie ein Entwickler die Anwendung codiert hat. Kapselung ist ein Programmierbegriff, der sich auf die Bündelung von Daten und Aktionen, die mit diesen Daten ausgeführt werden können, in nur einer Einheit bezieht. Die Kapselung sichert Daten, indem sie Informationen darüber verbirgt, wie der Code ausgeführt wird, was eine bessere Benutzeroberfläche liefert. Benutzer müssen nicht wissen, wie die Anwendung ihnen Daten liefert; alles, was sie brauchen, ist der Zugriff darauf.
Beispielsweise kann ein App-Entwickler Zugriffskontrollen wie Lese- oder Schreibberechtigungen in die Fähigkeit einer Anwendung zum Abrufen von Daten integrieren. Fordert der Nutzer Informationen in der App an, liefert diese nur die Daten, auf die er Zugriff hat.
Wenn es den Entwicklern jedoch nicht gelingt, klar definierte Grenzen zwischen den Daten und den Aktionen festzulegen, die über verschiedene Aspekte der Anwendung hinweg ausgeführt werden, leidet die Anwendung unter einer Sicherheitslücke bei der Kapselung. Angreifer nutzen dies aus, indem sie eine Anfrage an die Anwendung senden, da sie wissen, dass eine solche Aktion zu einer Fehlermeldung führen würde. Diese Fehlermeldung gibt dann Aufschluss über den Aufbau der Anwendung und unterstützt so weitere Angriffsstrategien wie einen DOS – Denial of Service.
Unsichere direkte Objektreferenzen (IDOR)
Webanwendungs-URLs sind in der Lage, das Muster oder Format offenzulegen, das verwendet wird, um Benutzer zu Back-End-Speicherorten zu leiten. Beispielsweise kann eine URL das Muster/Format für eine Datensatzkennung in einem Speichersystem wie einem Dateisystem oder einer Datenbank anzeigen.
Die IDOR allein könnte ein Problem mit geringem Risiko darstellen. Wenn jedoch ein IDOR mit einer fehlgeschlagenen Zugriffskontrollprüfung kombiniert wird, erhalten die Angreifer die Chance, erfolgreich zuzuschlagen.
Andere häufige Schwachstellen in Webanwendungen, die Sie kennen sollten, sind:
HTTP-Antwortaufteilung
Dies ist eine Art CRLF-Injektionsangriff. HTTP ist der Prozess, über den Browser Anfragen senden und die Server die Antworten zurücksenden. Bei dieser Schwachstelle in Webanwendungen verwenden die böswilligen Angreifer die CR- und LR-Notationen, um zu manipulieren, wie die Browser und Server miteinander kommunizieren, was eine Anfrage liefert, aber den Server anweist, die Antwort in verschiedene Teile zu „teilen“. Die Aufteilung der Antwort in zwei verschiedene Teile ermöglicht es dem böswilligen Akteur, die Kontrolle über die Informationen zu erlangen, die der Server als Antwort auf den anderen Teil der Anfrage liefert. Wenn es sich bei diesen angeforderten Daten um Benutzer-ID-Daten oder vertrauliche Informationen handelt, hat der böswillige Akteur den Angriff erfolgreich durchgeführt.
Einspritzfehler
Ein Injektionsfehler ermöglicht eine Fülle verschiedener Angriffstechniken. Jede Anwendung, die es Benutzern ermöglicht, Shell-Befehle, Betriebssystemaufrufe oder eine Datenbank zu aktualisieren, kann einen Injektionsfehler erleiden. Böswillige Angreifer nutzen Injektionsfehler, um die Befehle zu ändern, die sich zu neuen und unerwarteten Aktionen innerhalb der Anwendung entwickeln. Durch die Ausnutzung dieser Schwachstellen können böswillige Akteure Daten erstellen, aktualisieren, lesen oder sogar löschen.
Unsichere Message-Digest-Schwachstelle
Dies ist eine kryptografische Schwachstelle, die die Wirksamkeit der Verschlüsselung einschränkt. Ein Message Digest sollte die kryptografische Hash-Funktion umfassen. Im Gegensatz zur Verschlüsselung erfordern Hash-Funktionen nicht, dass der Absender und die Benutzer Schlüssel verwenden.
Böswillige Angreifer nutzen daher unsichere Digest-Schwachstellen aus, um „Hash-Kollisionsangriffe“ fortzusetzen. Ziel des Angriffs ist es herauszufinden, ob das Senden einer Eingabe zur Generierung eines doppelten Hashs führt. Wenn die böswillige Aktion zwangsweise einen freigegebenen Hash generiert, können sie diesen Hash verwenden, um eine bösartige Datei zum Herunterladen bereitzustellen. Dies lässt wiederum den Endbenutzer mit der Annahme zurück, dass die Datei echt ist.
Unzureichender Schutz der Transportschicht
Transport Layer Security (TLS) bezieht sich auf den Prozess, durch den Computeranwendungen im Internet sicher miteinander „kommunizieren“ können. Eine Reihe von Anwendungen verwenden TLS nur während des Authentifizierungsprozesses, wodurch Daten und ID-Sitzungsinformationen angreifbar bleiben, wenn eine Person die Anwendung verwendet.
Angreifer können diese Schwachstelle ausnutzen, um Daten bei der Übertragung über das Internet zwischen dem Gerät des Benutzers und dem Anwendungsserver umzuleiten.
Remote-Code-Ausführung (RCE)
Sicherheitslücken bei der Remotecodeausführung sind Codierungsfehler in Webanwendungen, die es böswilligen Angreifern ermöglichen, Code unabhängig von ihrem geografischen Standort einzufügen. RCEs fallen unter eine breitere Kategorie von Sicherheitslücken durch das Einschleusen von Webanwendungen, bei denen Angreifer ihren eigenen Code in eine Anwendung eingeben, die Benutzereingaben nicht bestätigt, sodass der Server sie als echten Anwendungscode betrachtet. Typischerweise nutzen böswillige Angreifer ungepatchte allgemein bekannte Schwachstellen aus und fügen ihren Code in die Anwendung ein.
Remote File Inclusion (RFI)
Um gemeinsame Verzeichnisse mit einer Anwendung zu verknüpfen, fügen Entwickler „include“-Anweisungen in ihren Code ein. Beispielsweise muss eine Anwendung möglicherweise Daten aus einer Datenbank abrufen. Anstatt es manuell zu codieren, um jede Datei zu erhalten, hilft die „include“-Anweisung, das gesamte Quellverzeichnis zu verknüpfen, sodass alles, was dort gespeichert ist, verwendet werden kann.
Wenn eine Webanwendung eine RFI-Schwachstelle aufweist, können die Angreifer die Anwendung manipulieren, um bösartigen Code oder Malware auf die Datenbank, den Server oder die Website hochzuladen.
Fehlkonfiguration der Sicherheit
Die Wahrscheinlichkeit einer Sicherheitsfehlkonfiguration ist heute in der Tat eine der häufigsten Sicherheitslücken in Webanwendungen . Diese Sicherheitsanfälligkeit tritt im Allgemeinen auf, wenn eine Organisation die Standardsicherheitseinstellungen nicht ändert. Häufige Sicherheitsfehlkonfigurationen sind:
- Verwendung von Standardpasswörtern oder -konten
- Ungepatchte Software
- Keine Verschlüsselung
- Unzureichende Firewall-Richtlinien
- Vernachlässigung ungenutzter Ressourcen, Funktionen und anderer Komponenten
SQL-Injektion
SQL, was Structured Query Language bedeutet, ist eine Programmiersprache für Datenbanken. Es ermöglicht das Abrufen und Bearbeiten von Daten für relationale Datenbanken. Eine SQL-Injection-Schwachstelle liegt unter einer größeren Gruppe von nicht überprüften Benutzereingaben. Wenn böswillige Akteure absichtlich falsche Anfragen senden, antwortet die Webanwendung mit einer Fehlermeldung, die ihnen Informationen über die Struktur und den Schutz der Datenbank liefert.
Nicht validierte automatische Bibliotheksaktivierung
Um beim Codieren Zeit zu sparen, verwenden Entwickler in der Regel Bibliotheken von Drittanbietern. In den meisten Fällen können sie so auf vorgetesteten Code zurückgreifen, der den Entwicklungsprozess der Anwendung beschleunigt. Die Verwendung von öffentlich verfügbarem Open-Source-Code erhöht jedoch die Sicherheitsrisiken, einschließlich:
- Das Fehlen eines dokumentierten Eigentums erhöht das Risiko, dass bösartiger Code hinzugefügt wird
- Vernachlässigte Projekte, die nicht mehr aktualisiert werden
Diese besondere Schwachstelle tritt immer häufiger auf, wenn man bedenkt, dass mehrere Anwendungen Bibliotheksabhängigkeiten von Drittanbietern nutzen.
Wir hoffen, dass der Inhalt dieses Blogbeitrags für Sie tatsächlich nützlich und aufschlussreich war. Stellen Sie sicher, dass Sie eine Lösung für die Schwachstelle Ihrer Webanwendung finden, die auf Ihren Fall zutrifft.