Über unsMediaKontaktImpressum
Nina Wagner 04. Februar 2025

IT-Security: Das kleine Einmaleins der Web-Schwachstellen

Kontrollübernahme über Systeme, Umgehen von Freigabeprozessen und wirtschaftlicher Schaden durch Umsatzverlust – das sind mögliche Auswirkungen von erfolgreich ausgenutzten Web-Schwachstellen. Die Einsatzgebiete von Webanwendungen – "alles, was im Browser läuft" – sind vielfältig, man denke an simple Firmenpräsenzen, Webshops, Kundenportale, Online-Banking, CRMs und soziale Netzwerke. Trotz sehr verschiedener Daseinszwecke und Erscheinungsformen bauen all diese Anwendungen auf derselben zugrunde liegenden Technologie auf. Und damit haben sie unmittelbar etwas gemeinsam: Sie können von denselben Arten von Schwachstellen betroffen sein.

Aber was ist eigentlich eine Schwachstelle? Eine Schwachstelle ermöglicht eine unbeabsichtigte Interaktion mit einer Komponente, wie einem System oder einer Anwendung, die potenziell zu schädlichen Zwecken genutzt werden kann. Eine Schwachstelle selbst muss zuerst von jemandem ausgenutzt werden, bevor Schaden entstehen kann – aber nicht muss. Mehr dazu gleich.

Die geschäftsrelevanten und nicht-technischen Konsequenzen, die nach einer erfolgreichen Ausnutzung eintreten können, bleiben hinter vielen technischen Begriffen oft wenig greifbar. In diesem Artikel geht es um die Klärung folgender Fragen:

  • Wer oder was ist eigentlich von Web-Schwachstellen betroffen?
  • Wann stellen Web-Schwachstellen ein Risiko dar?
  • Was sind typische Web-Schwachstellen?
  • Warum gibt es Web-Schwachstellen?
  • Wie geht’s besser?

Wer oder was ist eigentlich von Web-Schwachstellen betroffen?

In erster Instanz ist eine verwundbare Webanwendung selbst von einer Web-Schwachstelle betroffen. Doch jede Anwendung hat ihren Daseinszweck. Und damit verbunden können oft noch weitere Komponenten oder sogar Personen von den Auswirkungen einer Schwachstelle betroffen sein.

Über eine Schwachstelle können Angreifer beispielsweise unbefugt an Daten gelangen oder Daten manipulieren. Je nachdem, welche Daten das sind, betrifft das unmittelbar sensible Informationen, wie personenbezogene Daten, Kundendaten, Projektdaten, Geschäftsgeheimnisse oder Finanzdaten.

Benutzer der Anwendung können also unmittelbar die Leidtragenden sein, wenn ihre Daten aus einer Anwendung in die falschen Hände fallen. Zudem kann es Angreifern beispielsweise gelingen, über die Anwendung schädlichen Code im Browser von anderen (legitimen) Benutzern auszuführen. Darüber können Angreifer potenziell beliebige Aktionen in der Anwendung im Namen anderer Benutzer ausführen und versuchen, über Schwachstellen im Browser sogar Zugriff auf das Endgerät des Benutzers zu erlangen – letzteres ist aber eher unwahrscheinlich, sofern das neuste Browser-Update installiert ist.

Eine Schwachstelle kann die Verfügbarkeit einer Anwendung gefährden – und das nicht nur durch klassische Denial-of-Service-Angriffe, bei denen ein System durch eine Flut von Anfragen überlastet wird. Bereits das gezielte Ausnutzen einzelner Schwachstellen kann ausreichen, um eine Anwendung komplett lahmzulegen. Besonders kritisch wird es, wenn die Erreichbarkeit der Anwendung essenziell ist, wie beispielsweise bei einem Webshop, der zur umsatzstärksten Zeit unerwartet ausfällt. Solche Vorfälle können erhebliche wirtschaftliche Schäden nach sich ziehen.

Das System, auf dem die Webanwendung betrieben wird, kann ein interessantes Angriffsziel sein. Server-Ressourcen können auch für eigene Zwecke genutzt werden, wie etwa Crypto Mining. Gelangen Angreifer lokal auf einen Server, so erhalten sie von dort aus neue Zugriffsmöglichkeiten und erreichen aus dieser neuen Perspektive möglicherweise andere interessante Systeme in der "Nachbarschaft". Je nachdem, wie gut oder schlecht die nun erreichbaren Systeme abgesichert sind, kann es für Angreifer ein leichtes Spiel sein, sich über diese Systeme weiter auszubreiten. Und das ist gar nicht so selten, denn häufig werden Sicherheitsmaßnahmen für Systeme, an die vermeintlich "sowieso niemand kommt", vernachlässigt.

Eine Schwachstelle in einer Anwendung kann also weitreichende Auswirkungen haben und neue Optionen für Angreifer eröffnen, die viel mehr als nur die verwundbare Anwendung selbst betreffen.

Wann stellen Web-Schwachstellen ein Risiko dar?

Egal, um welche Art von Schwachstelle es geht, gilt: Damit eine Schwachstelle ein Risiko darstellt, muss aus ihrer Ausnutzung ein Schaden hervorgehen können und es muss jemanden – eine "Gefahr" – geben, der die Schwachstelle ausnutzen kann. In die Risikobewertung einer Schwachstelle fließt ein, wie schlimm die Folgen einer erfolgreichen Ausnutzung wären ("Schaden") und unter welchen Voraussetzungen und wie einfach eine Schwachstelle ausgenutzt werden kann ("Wahrscheinlichkeit"). Meist, wenngleich nicht immer, geht mit einer Schwachstelle auch ein Risiko einher.

Beim möglichen Schaden, der durch die Ausnutzung einer Schwachstelle entstehen kann, stehen meist Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Systemen im Vordergrund und welche weiterführenden Aktionen aus einer möglicherweise neu erreichten Perspektive möglich sind. Die Schwere des Schadens wird dann abhängig von der (geschäftlichen) Relevanz der betroffenen Daten und Systeme bewertet.

Um abzuwägen, wie "wahrscheinlich" die Ausnutzung einer Schwachstelle ist, sind beispielsweise folgende Punkte zu betrachten:

  • In welcher Ausgangssituation muss sich ein Angreifer befinden? (Position im Netzwerk, erfolgreiche Authentisierung, spezielle Berechtigungen, …)
  • Wie leicht lässt sich die Schwachstelle ausnutzen? Gibt es öffentlich verfügbare Exploit-Code/Anleitungen? Wie tiefgehende Kenntnisse/Fähigkeiten sind notwendig?
  • Bestehen für eine erfolgreiche Ausnutzung Abhängigkeiten von Dritten, beispielsweise Interaktion von Mitarbeitenden/Benutzern?
  • Gibt es aktuelle Fälle zur erfolgreichen Ausnutzung der Schwachstelle? (Betrifft primär den Fall, dass es sich um öffentlich bekannte Schwachstellen in Software handelt.)
  • Welche anderweitigen Maßnahmen sind eventuell in Verwendung, die einer Ausnutzung vorbeugen? (Antivirus, Intrusion Prevention System, Web Application Firewall, …)

Zum letzten Punkt sei erwähnt, dass Maßnahmen, wie der Einsatz der aufgeführten Schutzsysteme, zwar die Ausnutzung einer Schwachstelle erschweren können (wenngleich nicht müssen), sie aber keinesfalls als Behebungsmaßnahme eingestuft werden sollten.
 
Schauen wir uns als Beispiel einen Fall einer SQL-Injection-Schwachstelle an, über die jeder über das Internet sämtliche Daten aus einer Datenbank auslesen kann. Dieses Szenario mag in vielen Fällen ein Albtraum sein, wenn in der Datenbank sensible Daten gespeichert werden. Enthält die Datenbank allerdings keine sensiblen Informationen oder sind die verfügbaren Informationen allesamt bereits öffentlich zugänglich, so entsteht durch die Ausnutzung der Schwachstelle kein ernsthafter Schaden – sofern sich neben dem Auslesen der Daten nicht noch weitere Möglichkeiten bieten. Die Priorisierung zur Behebung wird dann also eine andere Dringlichkeit haben, als wenn es um Zugriff auf Geschäftsgeheimnisse ginge.

Abschließend sei erwähnt, dass selbst Schwachstellen der gleichen Art, wie SQL-Injection-Schwachstellen, sehr verschieden ausgeprägt sein können. In einigen Fällen mag es nur möglich sein, ganz bestimmte Daten auszulesen – vielleicht auch nur die eigenen. In anderen Fällen kann allerdings der Zugriff auf alle in der Datenbank gespeicherten Daten, vielleicht auch ändernd oder löschend, oder sogar der Zugriff auf den zugrunde liegenden Server möglich sein. Hier gilt es also stets, den einzelnen Fall genau zu betrachten, um Schaden und Risiko zu bewerten und Maßnahmen zu priorisieren. 

Auf technischer Ebene werden Schwachstellen meistens mit CVSS bewertet. Das Common Vulnerability Scoring System (CVSS) ist ein Framework zur Charakterisierung und Berechnung des Schweregrades von Schwachstellen. Ins Leben gerufen hat das Projekt die Non-Profit-Organisation FIRST.Org, Inc. Aktuell ist Version 4.0, während Version 3.1 derzeit die am meisten eingesetzte ist.

Die Charakterisierung einer Schwachstelle auf Basis des CVSS v3.1 ergibt einen CVSS-Vektor, der die Eigenschaften zu möglichem Schaden und Voraussetzungen zur Ausnutzung der Schwachstelle kodiert, sowie eine Dezimalzahl zwischen 0,0 und 10,0, den sogenannten CVSS-Score. Dabei stellt 10,0 den höchsten Schweregrad dar. Durch die Berechnung des CVSS-Scores, basierend auf einer mathematischen Formel, erfolgt also eine Quantifizierung der Schwachstellen, sodass diese "sortierbar" werden. Den Werten auf der Bewertungsskala zwischen 0,0 und 10,0 sind die Bezeichnungen None (0,0), Low (0,1-3,9), Medium (4,0-6,9), High (7,0-8,9) und Critical (9,0-10,0) zugeordnet.

Im Fall der SQL-Injection-Schwachstelle aus dem Beispiel würde der CVSS-Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N lauten und die Bewertung wäre 7,5 High.

Im Vektor sind zusammengefasst Kriterien kodiert, die beschreiben, unter welchen Voraussetzungen die Schwachstelle ausnutzbar ist (vergleichbar zur Wahrscheinlichkeit in der Risiko-Betrachtung oben) und welcher Schaden entstehen kann.

Im Beispiel, das auch in der Grafik dargestellt ist, geht aus dem Vektor beispielsweise hervor, dass eine Ausnutzung über das Netzwerk erfolgen kann (Attack Vector = Network) und dafür keine speziellen Berechtigungen notwendig sind (Privileges Required = None). Über die Einstufung zur Vertraulichkeit (Confidentiality = High) wird der Schaden bewertet. Mittels "Confidentiality Requirement = Low" ließe sich noch spezifizieren, dass es für die betroffenen Daten nur niedrige Anforderungen an die Vertraulichkeit gibt.

Über einen Online-Rechner lassen sich verschiedene Bewertungskonstellationen durchspielen und es gibt detaillierte Informationen zu den einzelnen Bewertungskriterien [1].

Was sind typische Web-Schwachstellen?

Die wohl bekannteste Übersicht zu typischen Web-Schwachstellen sind die "OWASP Top Ten" [2]. OWASP (Open Web Application Security Project) ist eine Organisation, die diverse Projekte im Bereich Web-Sicherheit vorantreibt, mit den OWASP Top Ten für Webanwendungen als wohl prominentestes Beispiel. Für 2025 ist eine Aktualisierung der Top Ten angekündigt. Auf Platz 1 der aktuellen Top Ten aus 2021 steht "Broken Access Control" (fehlende Zugriffskontrollen), gefolgt von "Cryptographic Failures" (kryptografische Fehler) und "Injection" – mehr dazu gleich.

Im Vergleich zu den vorherigen Top Ten von 2017 zeigt der Trend 2021 eine Bündelung verschiedener Schwachstellentypen in übergeordnete Kategorien. Waren 2017 beispielsweise die Schwachstellenarten "Injection" und "Cross Site Scripting (XSS)" separat auf Platz 1 und 7 gelistet, fließen sie in die Top Ten von 2021 gemeinsam auf Platz 3 in die Kategorie "Injection" ein. Warum also diese Bündelung? Während SQL Injection das Einschleusen von schädlichen Eingaben in eine Datenbank beschreibt, werden bei Cross Site Scripting schädliche Eingaben in den HTML-  bzw. JavaScript-Code einer Anwendung eingeschleust ("injiziert") und im Browser anderer Benutzer ausgeführt. Auch wenn beide Schwachstellenarten verschiedene Technologien betreffen und verschiedene Konsequenzen haben, so ist ihre Ursache gleich: Eingaben, die von außen stammen, werden unsicher verarbeitet.

Dadurch, dass die Vielfalt der Schwachstellen wächst und stetig neue Arten dazukommen (und sich Klassiker aber weiterhin wacker halten), ist also ein "Blick von oben" für den Einstieg zielführender, als jede einzelne Schwachstellen-Bezeichnung zu betrachten. Deshalb legen wir in diesem Artikel den Fokus auf die oft gemeinsamen Ursachen – und nicht die Benennung einzelner Schwachstellen.

Warum gibt es Web-Schwachstellen?

Der Trend bei den OWASP Top 10 scheint also in Richtung "Vogelperspektive" zu gehen, in der verschiedene Schwachstellen mit ähnlichen Ursachen gebündelt werden. Eine noch höhere Vogelperspektive mit Fokus auf der Ursache von Schwachstellen zeigt Abb. 2. Die Schwachstellen sind farblich folgenden Ursachen zugeordnet:

  • Unsichere Verarbeitung von Eingaben: Die prominentesten Vertreter, SQL Injection und Cross Site Scripting, haben wir bereits diskutiert. Die wichtigste Erkenntnis bei Schwachstellen mit dieser Ursache ist: Eingaben, die eine Webanwendung zur Verarbeitung empfängt, müssen nicht zwingend über einen Browser eingetippt worden sein.
    Mögliche Einschränkungen im Browser, wie beispielsweise fünf Ziffern bei Postleitzahlen, Auswahl gewisser Werte in Drop-down-Menüs oder erlaubte Zeichen in Kommentarfeldern, können stets umgangen werden. Selbst Parameter, die sich über den Browser gar nicht editieren lassen, können mit unerwarteten Werten an die Webanwendung gesendet werden. Das heißt, Eingaben von außen müssen stets auf dem Webserver geprüft und sicher verarbeitet werden – sonst sind Schwachstellen sehr nah. Im Browser sind solche Restriktionen vielmehr als Unterstützung zum korrekten Ausfüllen für (legitime) Benutzer einer Anwendung gedacht.
  • Konzeptionell: Den konzeptionellen Ursachen sind Schwachstellen zugeordnet, die durch Lücken in (anwendungsweiten) Konzepten oder in Logiken entstehen. Dazu zählen etwa Schwachstellen in fachlichen Prozessen (z. B. Freigabe-/Genehmigungsprozesse), in technischen Abläufen (z. B. Login) und fehlende oder lückenhafte Berechtigungsprüfungen.
  • Konfiguration: Diese Schwachstellen entstehen durch Konfigurationen in verwendeten Software-Komponenten, wie beispielsweise im Webserver, und lassen sich durch Anpassung der Konfiguration lösen.
  • Fehlende Schutzmaßnahmen: Zuletzt gibt es Schwachstellen, die darauf zurückzuführen sind, wie das Web funktioniert. Gegen solche Schwachstellen muss sich also jede Webanwendung selbst wappnen, unabhängig davon, welche Funktionen sie bereitstellt.

Web-Schwchstellen vermeiden: Wie geht’s besser?

Was lässt sich also tun, um Anwendungen sicher zu entwickeln, zu betreiben und sich damit bestmöglich gegen die Vielfalt an Schwachstellen zu wappnen?

Es ist wünschenswert, mögliche Gefahren und Sicherheitsanforderungen von Beginn an und durch den gesamten Lebenszyklus einer Anwendung hinweg mitzudenken. Diesen Ansatz beschreibt der Ausdruck "Security by Design". Klar ist: Die Vielfalt, an die man beim Thema Sicherheit denken kann, ist groß. Und es ist sinnvoll und notwendig, mit verschiedenen Methoden zu arbeiten, die sich gegenseitig ergänzen und teils auch Redundanzen darstellen. Um Entwicklerinnen und Entwickler zu befähigen, sicheren Code zu schreiben, sind Schulungen zur sicheren Entwicklung unerlässlich. Dazu gehören dann Themen, wie

  • Vertraue keinen Eingaben von außen: Validiere alle externen Eingabewerte & Escape-Benutzereingaben bei der Weiterverarbeitung angemessen!
  • Verwende bewährte Lösungen: Erfinde das Rad nicht neu und nutze bereits "abgesicherte Funktionen" und Frameworks!
  • Lass nicht jeden rein und reduziere Zugriffe so weit wie möglich: Achte auf eine sichere Authentisierung (Passwörter, 2FA, SSO, …) und ein restriktives Berechtigungskonzept!
  • Nutze moderne kryptografische Verfahren angemessen: z. B. beim Speichern von Passwörtern (bzw. deren Hashes), für Integritäts- und Authentizitätsprüfungen und Verschlüsselung!
  • Gib nicht mehr preis als nötig: Reduziere preisgegebene Informationen auf ein funktionell notwendiges Minimum, insbesondere bei Fehlermeldungen!

Doch auch im gesamten Entwicklungsprozess muss Sicherheit bedacht werden, um etwa das unbemerkte Einschleusen von Schadcode zu unterbinden und mögliche Schwachstellen so früh wie möglich zu erkennen. Hierzu gehören Maßnahmen, wie:

  • Decke leicht erkennbare Schwächen sofort auf: Scanne Code und Anwendung regelmäßig und automatisiert!
  • Kenne Abhängigkeiten zu Dritten: Hab einen aktuellen Überblick über verwendete Komponenten, reagiere zeitnah auf Meldungen zu Schwachstellen und aktualisiere Software-Abhängigkeiten regelmäßig!
  • Stelle lückenfreien Ablauf von Code Editor bis zu laufenden Anwendungen sicher: sichere Gestaltung der gesamten Entwicklungsstrecke, z. B. gegen Einschleusen von Schadcode
  • Prüft euch gegenseitig: interne Peer Reviews für neuen/geänderten Quellcode
  • Lass Schwachstellen durch Dritte aufdecken: neutraler Blick von außen durch Pentests und externe Quellcode-Audits
  • Auch beim Betrieb und der Administration einer Anwendung mit eventuell allen verbundenen Komponenten muss Sicherheit mitgedacht werden, wie etwas durch:
  • Standard-Hausaufgaben erledigen: regelmäßige Updates, sichere Konfiguration, minimieren der Angriffsoberfläche, …
  • Lass niemanden mitlesen: Übertrage und speichere Daten mit einer zeitgemäßen Verschlüsselung!
  • Beuge technischen Missverständnissen vor: Stelle sicher, dass alle involvierten Komponenten miteinander "harmonieren" und Übergabepunkte klar abgestimmt sind!
  • Erkenne Angriffe und reagiere: Logging, Monitoring, Web Application Firewall, …!
  • Setze zusätzliche Schutzmaßnahmen um: Nutze HTTP-Header wie Strict Transport Security und Content Security Policy, Cookie-Schutzattribute, …!

Die Vielfalt, um an das Thema Sicherheit heranzugehen, ist also groß. Wichtig beim Priorisieren in der eigenen Situation ist zu überlegen, welche Maßnahmen den größten Benefit bieten. Dazu gilt es zu bedenken, was bereits umgesetzt ist und wo noch die größten Risiken lauern. Um den größten Risiken entgegenzuwirken, sollten dann zunächst die Maßnahmen gewählt werden, die das beste Verhältnis zwischen Aufwand in der Umsetzung und Nutzen in puncto Sicherheit mit sich bringen.

Sicherheit ist bekanntermaßen ein permanenter Prozess und beinhaltet, sich der Risiken bewusst zu sein und sie regelmäßig neu zu bewerten sowie adäquate Maßnahmen festzulegen, zu priorisieren und umzusetzen.

Security auf den diesjährigen IT-Tagen

Spannende Vorträge und Workshops zum Thema Security erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.

Autorin
Das könnte Sie auch interessieren

Neuen Kommentar schreiben

Kommentare (0)